Teams – Leadershipness

How to Avoid the Race to the Bottom

Recently my wife and I were struggling with the kids, which I hear is a common sentiment a year into the pandemic. Trying to teach and maintain healthy habits, we limit their screen time to an hour a day and 2.5 hours a day on the weekend, ask them to do chores around the apartment, and we try to limit their sugar intake. This has been, to put it mildly, a challenge.

They don’t want to do any of it, and will bend, break, or skirt the rules whenever they think they can get away with it. We’re trying to team them habits that are good for them now, and will be valuable skills later, but with the stress of eternal social distancing and a soft-lockdown, they’re waging a constant, low-grade rebellion… and winning. My daughter’s room is a hazardous waste site, our son needs constant supervision to turn in any school assignments on-time, and neither of them want to have anything to do with doing the dishes or taking out the trash.

This has led to a destructive cycle where we take away more and more screen time and privileges for misbehavior, and they then have fewer and fewer things that we can threaten them with, giving them little incentive to behave. This has led to a household where the kids are miserable and bored, the parents feel taken advantage of and frustrated, and the chores are still not getting done! We had reached the bottom.

It’s not a good system when literally no one is winning, so the other day I sat down to think about what we were doing wrong and I was reminded about another broken system that I inherited in the first few days of my current job.

Cherry-picking

Taking over the SaaS Support organization a year ago, one of my teams offered L1 support. It was a small team, that executed simple requests made by coworkers through a Service Desk portal. Ideally, the work was supposed to be frictionless, with requests getting done in under a day, no required clarification or follow-up from the requestor, and a first time delivery with quality.

It wasn’t working. The queue constantly had tickets in it that had failed SLA (our 24-hour delivery commitment), languishing for most of a week, and tickets were being rejected by the requestors at an unacceptable rate. Not much was working.

After talking to the members of the team individually they seemed intelligent, motivated, and competent. Mistakes were being made due to carelessness, not inability, and the tickets that were failing SLA were long-running tasks that took a lot longer than other tasks to execute. The problem didn’t appear to lie with the people, so the manager and I took a look at the system. Why wasn’t it working?

The team was graded by how many tickets they delivered within the 24-hour SLA that were accepted the first time. Sounds like a good definition of success, right? This is what we wanted, however it wasn’t achieving our goals. Digging deeper into the numbers we found a few causes of the problem:

the team was rushing through execution, and not taking care to validate the result before delivering it to the customer in a quest for numbers.
no one wanted to pick up the long-running tasks, because they could do fewer of them, and if they failed SLA they wouldn’t get any credit anyway.

The behaviors we were encouraging with our grading system was not aligned with the outcome we wanted. Aligning goals and incentives is easy to say, but very difficult to do. It has been poorly done by business and governments, large and small, everywhere, throughout all of time, and classically illustrated by the cobra effect.

Tasty Carrots and Sharp Sticks

First, we decided that allowing a team who is supposed to get tickets out as quickly as possible shouldn’t be spending time deciding what ticket they wanted to work on. It creates an incentive to cheat, one of the classic causes of goal misalignment. We created restrictions on the queue, where the tickets were prioritized by age, and an agent completing a task automatically had the next ticket in the queue assigned. No one could cheat, and no one had to worry that their co-workers were taking advantage of the system.

Secondly, we decided that prioritizing quality and productivity was incompatible. We changed the grading so the agents got credit for tickets that went past the SLA (only fair since they could no longer choose their tickets), in the hope that a focus on quality would lead to an increase in overall system productivity as Lean Six Sigma predicts.

It worked! Within two weeks, the team that consistently failed SLA on ~20% of requests, and had rejections on another 10%, got the backlog of tickets to under 10 during the working day and kept it there. Rejections also fell to less than 1% of requests. This was all done with no additional resources or automations. It has been over a year, and tickets that fail SLA are now very rare despite this no longer being a grading criteria.

Treating My Kids Like Employees

Now, how could I apply this approach to my kids? First, we had to decide what my wife and I wanted, keeping it simple and focused:

good effort at school (grades are like SLA, not the measure we want to track)
household chores done

What did the kids want?

time on electronics
desserts

With these goals and incentives in mind, we came up with a system that awarded them points for positive reports from school, and completion of chores that we thought the kids could handle on their own. Points could be lost for poor reports from school. These points could be converted to 30 minutes of electronics (up to the 1 hour per weekday and 2.5 hours per weekend day previously established), or five points for a dessert.

The next morning my daughter unloaded the dishwasher and my son made his bed, both without being asked, for the first time ever. A screaming success. It turns out that our arbitrary rewarding and punishing behaviors was demotivating to the kids. They were reluctant to perform a chore with an uncertain payout, and were less hesitant to do something wrong when the punishment was unknown. Now that they knew the score (literally!) they enthusiastically looked for ways to get more points, and now that my son knows that not doing an assignment could cost him his full hour of Fortnite that evening he is far more likely to get it done.

We’re all self-interested, and even the most disciplined of us is going to spend more time on things with a greater payoff and avoid things with a higher downside. One of the magical aspects of leadership is truly understanding your employees and the system in which they operate. Without that knowledge and empathy, you have no hope of designing a system so that it encourages the behaviors that provide the greatest payoff to the organization. But if you can do so, you can create an environment where employees love to come to work, and you never have to beg or threaten to get the results that you want.

How to Set Goals

Everyone sets goals for themselves, and every leader has goals for their team. These goals may be informal, aspirational, explicit, or any number of other things, but, in the end, goals are just what you hope to accomplish, both for yourself and for your team.

But what makes a good goal? What goals, and how many should a leader set for themselves and their team? Is it good to set easy goals so the team can have a sense of accomplishment, or should one make very challenging goals to inspire the team meet the challenge? The answer to many of these questions is: “it depends”, however there are a few criteria that all goals should adhere to, and several mistakes around goal setting that should be avoided.

It’s critical that goals are not only SMART, but well thought out, intentional, few in number, focused, and aligned with the company’s incentives. It may sound funny, but it is far more common in my experience for a company to want one thing, but structure incentives that encourage something totally different.

Aligning Goals and Incentives

For example, have you ever worked at a company that paid its sales team a commission on signed contracts? Once the ink is dry, the salesperson gets a cut of the agreed on sales price, and the company gets a new project. Great deal, right? Well, what does this scenario really encourage? Does it incentivize the salesperson to make reasonable promises and set appropriate expectations? Does it encourage the salesperson to collaborate with the implementation team to ensure that the project can be completed on time, on budget, and to the customer’s satisfaction? Or, instead, does it encourage the salesperson to say whatever they need to, make whatever promise is necessary, to get the contract signed so they can move on to the next one?

In most cases, the company doesn’t want a signature on a contract. That’s a nice and necessary first step, but what the company really wants is a successful implementation, a happy and reference-able customer, and repeat business. That first contract should just be the first of many if the company delivers on their promises, but if those promises aren’t made with respect to reality, then the company is going to get that signature on a piece of paper, and likely none of the things that they really want.

You can’t blame the salesperson for this scenario; they’re just doing what they have been encouraged to do. You can’t expect to set incentives that encourage behavior that doesn’t contribute to your ultimate goals, and hope to achieve them.

Aligning Goals Vertically

Another common mistake when it comes to goals is the creation of independent goals at every level of the company hierarchy. Imagine that the company leadership is looking to grow new sales by 20% year-over-year, the engineering team has decided to work on issues for existing customers to increase the Net Promoter Score, and the sales team is working on customer education to get existing customers to adopt more modules of the product.

These are all fine goals, but they do not contribute to each other at all. Neither the engineering team or the sales team is contributing to each other’s goals, and neither of them is contributing to the overall company goal. Imagine three teams of people all pulling a section of an enormous rope in different directions. Nobody’s going to get very far without the support of the other people pulling the rope.

Now, imagine instead that the leadership team has announced that the company’s goal is to grow new sales by 20% year-over-year, and then works with the engineering team to decide to build new features that prospective customers have been asking for, and with the sales team to reach out to contacts made at conferences to increase their awareness that the features they were interested in are in the pipeline. This is an organization all pulling the rope in the same direction, and it’s amazing how much can get done if the goals set by every team align with each other and contribute to the goals of the greater organization.

When you’re deciding on goals for your team, make sure to understand what goals your boss has set for their team, make sure that the goals you set for your team align with them, and also be sure that your incentives encourage behavior that will accomplish them.

Less Is More

Yet another mistake when setting goals is a loss of focus. Sometimes a team will have so many things to do, so many issues to resolve, and so many stakeholders to please that it’s tempting to set dozens of tiny goals to try to make everyone happy. In my experience, this only results in
the team not understanding what the real priorities are, no stakeholder really getting what they want, and results in the sense that little was accomplished.

Your goals set your priorities, and having a few, clear goals that everyone on the team understands and can work toward is far more valuable than many smaller goals that seem unrelated. It is a very powerful thing to tell a team that in the next three sprints we are going to accomplish two things, and everything everyone does is going to contribute, in some way, to the accomplishing of these things. It sets the vision, it enlists their support, and gives clarity to why they are working on whatever tasks are assigned to them.

It is fine to have smaller sub-goals, but they must all align and contribute to the greater, stated goals, otherwise the message gets confusing. If everyone on the team is working on tasks that clearly align with each other and contribute to a greater communal goal, it creates a sense of team, partnership, and purpose that cannot be replicated otherwise.

What your goals are and how challenging is less important than their focus, and alignment with incentives and greater company goals. Being thoughtful and communicative about your team’s goals is a great way to develop a high performing team with a track record of accomplishments.

All Hands on Deck

You are thoughtful in your interviewing process and selective in your hiring. You’ve assembled a team that gets along, executes well, and has been delivering. It seems like you’ve put together a great team, but how will they perform during an emergency?

It’s an inevitability that no amount of planning can completely prevent, and anyone who’s spent any time in the professional ranks has experienced. Maybe your team made a mistake that caused the crisis, maybe someone else at the company did, or maybe the emergency just happened to you and there’s no one to blame. It doesn’t really matter, because now the emergency’s yours and it’s up to your team to deal with it.

While no one wants to be in this situation, it does provide an opportunity to find out what your team is really made of. It’s easy to deliver when times are good, but existential challenges are when a team’s true character shows. Don’t let this opportunity pass you by. While you’re running around with your hair on fire in a near panic, take note of your team. Who’s hiding? Who’s asking questions? Who’s arguing? Who’s shifting blame and pointing fingers? Who’s jumping into action, doing whatever is necessary to solve a part of the problem?

The day before Labor Day weekend

Yesterday morning (the day before the start of the Labor Day weekend), before most of my team had arrived, an executive came into the room where I sit with the entire product team and announced that a bug that we had known about for a while had to be fixed before the end of the holiday. We had been executing a plan to solve the issue and expected to have it out in the next release, but were told in very certain terms that that timeline no longer worked.

My concerns about this change in plan revolved around one major issue: two members of my very small team were in their second week on the job, and few of the rest of the team had any experience at all with the part of the application where the error was. I had to instruct people to pull down code they’d never seen, and fix it under extreme pressure. I wondered just how much of our holiday weekend was going to be spent in that office getting to know each other better under pretty terrible circumstances.

As I started giving out assignments, heads went down. Our normally boisterous room where we sit elbow-to-elbow got pin-drop quiet. People moved from their seats where they sit every day to sit next to the people they needed for their new assignment. Not one word of complaint, not one hint of hesitation. No one in that room was responsible for the issue, but that didn’t matter. You could read it in the body language, we may not have caused the emergency, but it was ours now to solve and that was it.

The senior engineers helped the junior engineers get started on their work, and then immediately flew into their own. I hadn’t given some members of the team an explicit assignment, having only enough of a plan at that point to give out a few tasks. Even so, everyone without something to do, found a way to help. It was inspiring.

We came up with a plan, presented it to leadership, and spent the rest of the day executing on it. I can’t say it was fun, it was far too stressful to be described that way. I will say that it was as pleasant as that type of experience can be, and by the end of the day we had made enough progress that everyone was able to leave at a reasonable time, and only a few simple tasks were required over the holiday. Problem addressed, crisis averted.

Proof

When your team is faced with an emergency, who among them will panic, who will hide, and who will pull up their sleeves and get to work? Will you be able to get everyone pulling in the same direction when it counts the most? There may come a time when the future of the company depends on it.

I knew we had a good team before this episode. They had gelled extremely fast, seemed to genuinely like each other, and were producing code at a crazy pace, but I didn’t really know what they were made of until yesterday. How do you find people like this? If you have any ideas or advice on how to spot candidates who will rise to the occasion and deliver when the pressure’s on, please leave a comment below.

No Room for Individual Contributors

I’ve used a variety of approaches and questions during interviews over the years to identify future leaders. Nothing feels better than watching someone you took a chance on outgrow their role and start sharing their knowledge and developing others on the team. But how do you find these people? How do you know that someone is not only going to deliver, but help mentor less-experienced teammates and raise the level of the whole team and organization? It can be fairly easy to find people who can do the job that you hire them for well, but how do you know if that’s all they’re ever going to contribute or if they’ll develop into a superstar?

In IT there’s a mythos about the superstar individual contributor. The guy (unfortunately, it’s almost always a guy in the world of IT) who can deliver amazing results if you just leave them alone and don’t give them any responsibilities besides producing code. Leaders learn to lean on these people to get the challenging done in timelines that appear impossible. The individual contributor takes little time to manage because they are so excellent at what they do, and can make the leader look really good in the process.

This dependence is understandable and produces stunning results in the short-term, but a strategic leader doesn’t plan in the short-term. They should know that this over-reliance on a superstar is a mistake, and will lead to massive failures of the team in the long-term.

Questions addressed

What’s wrong with individual contributors?
If you have an individual contributor, what do you do about it?
How do you find and develop mentors?

Everyone should be learning

First, everyone in an organization needs to be learning and developing. Do you have a team member who is a fantastic performer, but has poor people skills and/or doesn’t want to be bothered with mentoring? Great! You found their opportunity for improvement. This person has as much potential for learning and growth as a mediocre performer who is still learning their job.

Just like every other skill that is critical to the performance of a team, mentoring should be practiced by every member. Everyone knows something that someone else doesn’t, and a good leader needs to create an environment where sharing that knowledge is an expected practice until it becomes a habit. Someone who doesn’t participate or doesn’t do it well, should be coached just like someone who doesn’t perform any other task well.

Coaching and mentoring need to be expectations for every member of the team, not a specialized skill that only a few perform. Anyone who is unwilling to develop this skillset should be treated like anyone else who is unwilling to learn a critical component of their job. If you won’t mentor, you can’t do this job to our satisfaction and it might be necessary to consider that this isn’t the right fit.

The monopoly of knowledge

Why is it so important that everyone mentor? What does it matter if the superstar is delivering, and the team’s output reflects it?

The problem is that the superstar individual contributor is holding your team hostage with their knowledge. If they get hit by that metaphorical bus and are no longer with your team, is there anyone left who can pick up where they left off? Probably not. Is the documentation that they left good enough for someone to ramp up in their absence? Maybe, but who really knows what the superstar has been up to over there in the corner with their headphones on all day, every day.

Mentoring and collaboration ensures that no one is the sole proprietor of any critical knowledge for your team. Someone who has to repeatedly coach new team members on how something works will be highly motivated to write good documentation, and when, inevitably, the owner of any process or application in your system moves on to other things, the team will be able to continue on with a minimum of disruption.

Finding mentors

How do you make sure that someone you’re interviewing is not only willing to mentor, but is excited about it? After all, in all of my years of interviewing and asking how the candidate how they felt about mentoring, no one has ever been anything but positive about the idea. Who wants to tell a prospective employer that they’re not a team player, and don’t really care to develop team mates? No one, that’s who.

My first test is the candidate’s résumé. Someone with more than five years of experience and exclusively technical accomplishments is a big red flag. I look for mentions of team leading, collaboration, and they get bonus points for informal coaching such as leading lunch n’ learns or being part of a standards group.

The second test is the enthusiasm of their response. If you ask them about how they feel about coaching and have to interrupt them five minutes later because they won’t stop talking about it, that’s a much better sign than a monosyllabic response. Pay attention to the context clues. Do they have experiences and stories they can readily share, and do they convey these stories with excitement? That’s a person who’s going to contribute a culture of mentorship to your organization.

Actively seek out mentors and give them the space and environment to share their knowledge, and your teams productivity will explode. A team of coaches and collaborators will always outproduce a team of gifted individual contributors in the long run, no matter their level of expertise. Like a soccer team of gifted players who never pass, you may get a few moments of brilliance that will win a few games, but over the course of the season teams that work well together are going to win out.

How to Leverage Uncertainty

In my experience, people generally fall into one of two categories:

High-uncertainty (HU)
Low-uncertainty (LU)

HU people are comfortable working without a complete understanding of the problem space, confident that they will discover and overcome the gaps in their knowledge and overcome them as they proceed.

LU people are uncomfortable without a reasonable understanding of the problem space, not wanting to waste time and effort building something that they might have to go back and make significant changes to once gaps in their knowledge are discovered.

Neither of these people are better or worse, like most other characteristics of a person in the workplace it’s just how they are, and both have strengths and weaknesses that can be leveraged.

High-uncertainty

HU people are great in situations where there just isn’t a lot of understanding of the problem in your organization. They will dig right in with their can-do attitude and infectious enthusiasm, find the issues, and deal with them. They’ll give you something workable really quickly, but you might have to wait a little while for the solution to be “enterprise ready”.

These people can be less effective in scenarios where the problem space is extremely complicated. In their rush to get started, they generally spend less time reading the documentation and might end up duplicating the mistakes that other’s have made in the past. Situations where documentation doesn’t exist or is very poor are a much better fit for this person. They’ll jump right in and develop an understanding of the problem right away, and are your best bet for building that knowledge quickly.

They also might not be the ideal candidate to solve a problem that isn’t urgent. Long timelines defeat one of their main strengths: speed. While they will deliver a solution fast, it’ll often take them considerably longer to come up with something that can be rolled out to customers or the organization, because of the amount of rework their solution will require. These people thrive under pressure and tight schedules, delivering a solution faster than was thought possible.

If the problem is mission-critical or customer-facing, and the solution has to work the first time, then you might want to consider someone else. The HU’s testing is often not as thorough as it could be, and there’s a good chance that new problems will be introduced by their solution, sometimes as bad or worse than the original problem the solution was meant to fix. Internal tools or processes that have a friendly audience are a good place for this person’s work product. Another great opportunity are proofs of concept. Want to figure out if an approach will work, but don’t want to spend a lot of time or resources to find out? Get yourself an HU, give them an idea of what you’re looking for, and stand back. The lack of strict requirements will allow them to try things and experiment, and possibly produce something wholly unexpected and valuable.

Low-uncertainty

LU people are great in situations where the problem is complex, but documentation is thorough. They are generally more cautious, will see all of the potential issues with any approach, and won’t lead you down any blind alleys. You just have to be willing to give them the time to deliver and resources to answer their questions.

These people won’t start working a problem until they’re satisfied that they understand the problem and its context. They will take the time to consume any and all documentation, interview stakeholders, and question the requirements. If the documentation doesn’t exist or there aren’t any knowledgeable stakeholders, then they can really struggle to get started at all. They often get caught up in the details, miss the big picture, and may sometimes overlook simple solutions.

Need to fix something right away, and you don’t care how it gets done. The LU is not your person. They won’t even get started until they understand what’s wrong and are absolutely certain that they can fix it without any unintended consequences. While admirable, sometimes this approach just takes too long and the caution isn’t merited. Give this person a long-term, strategic project, and they’ll blow you away with their thoroughness, thoughtfulness, and planning. They’ll make sure that every angle is covered, every issue is planned for, and that all of their work will be well tested and documented.

The LU is also not the right person for low-risk high-impact problems. Something that could be done quickly, won’t. Issues that require a quick investigation, and not a thorough deep-dive will take quite a bit longer than expected or necessary. Give the LU big, complex problems that will have a huge impact on the project such as security, inter-team collaboration, or changes to any complex, well-understood subsystem. You can get the best out of them by giving the LU granular requirements, long-timelines, and tasks that require lots of cross-team interactions and high-quality deliverables. After answering their many, many questions, you won’t ever have to worry about them or their project meeting your expectations.

Gameplan

Like all characteristics that make team members different and unique, understanding these differences allows the strategic manager to place these people in places where they can succeed, and avoiding setting them up for failure. You should always be cognizant of the strengths and weakness of team members, and sometimes applying broad generalizations like High/Low-uncertainty can give you a guide for how to think of resource allocation to produce the best results.

Teams combining a healthy balance of both of these types of people, can achieve the best of all worlds. Projects that have been well thought through, guided by proofs of concept that have been quickly implemented to demonstrate the feasibility of different approaches, well documented and tested, an quickly implemented. The strategic leader should be able to combine these different personality types to their organizations best advantage while balancing their needs and strengths and covering for their weaknesses.

The next time you have an assignment, give some thought to how well matched the different members of your team are for it beyond their skillet. You might find that matching the uncertainty of the project to the right team member leads to greater success and job satisfaction.