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.

Headphones and Leadership

Just a quick pet peeve of mine today:

Do you want to listen to music while you work, or do you want to be a leader? Headphones are the work equivalent of a Do Not Disturb sign. If you want to be a leader, you have to be accessible and approachable. When no one feels that they can ask you questions or seek advice, who exactly are you leading?

Save the headphones for the few times that you’re on a deadline and have to be heads down. Otherwise, leave the headphones in the bag to foster team communication and collaboration.

How to Leverage Uncertainty

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

  1. High-uncertainty (HU)
  2. 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.