Communicate the Plan

We all know the importance of developing a plan, and the even greater importance of executing it. Execution of a sound plan is a large part of what separates successful, productive teams from others.

A crucial part of this simple-to-articulate but difficult-to-achieve process is the communication of the plan. I’m not referring to communication with the direct participants of the plan. That falls under execution. What I’m talking about is communication of the plan to the wider team, those who don’t have a task or a deliverable in the plan.

Muster all your resources

This is yet another thing that I’ve struggled with over my career. (Yes, I’m aware that the majority of my source material is my list of greatest screw-ups, but what better topics to discuss than those that you wish someone taught you about earlier?) My natural inclination is towards simplicity in all things. The simplest plan, the simplest changes, the simplest team necessary will lead to the lowest likelihood of introducing new issues that have to be fixed later. The least effort for the most impact is the very definition of efficiency, and in a world of finite time and resources, efficiency has always been one of my main decision drivers.

Where this breaks down is that simplicity in communication dictates that only the members of the team that need to know should be told. The more people you bring into an email chain, the slower and less efficient the execution might become. We also live in a world where our inboxes are constantly flooded with notifications that we don’t really need, and don’t pay much attention to. Why would I spam a co-worker’s email with information irrelevant to them and to our plan?

The reason is that, and you’ll see me revisit this theme over and over, people are not robots. Robots should know only what they need to in order to do their job, and more than that is a waste of time and effort. People, on the other hand, sometimes have information that members of your team don’t. They may be able to point out a better way to execute on your plan, or let you know why it won’t work in the first place.

Finding out why your plan is stupid and taking the time to devise a better solution before wasting any time on it is WAY more efficient than executing a stupid plan very well. Be honest, how many times have you been nearing completion of a long, difficult project when someone from a different team hears what you’ve been working on for the first time and comments “we implemented something like that last year, would you like to know how we did it?” or “we tried that before, how did you overcome [some obscure issue that you hadn’t even thought of yet]?” How much effort would a little communication have saved?

Send it up the chain

Just as important as taking advantage of the knowledge and experience of people outside your team, can be the confidence of leadership. Sometimes, simplicity of communication leads us to tell management “we are addressing problem X, and it will take Y amount of time.” This is exactly what they need to know, and no more. The problem is this leads to Hopeful Leadership (something I hope to address further in a future post), where they trust that there is a plan and that it is being executed, but they really don’t know.

Management may accept that it will take Y amount of time to fix X, but without the details of the plan, and regular status updates, are they going to be confident in your plan or your ability to deliver? Management’s confidence in the plan and its execution is critical to the plan’s success. If management doesn’t know the plan, how can they support you? Are they going to sit back and wait until the delivery date, or are they going to ping you for status updates, and try to “help”? It is in your best interest to not only make management aware of the plan, but keep them apprised of progress towards completing the plan.

In short, simplicity is a worthy goal, but not necessarily with regards to communication. Let people know what you’re team is working on, the obstacles you’re facing, and deliver continual updates to management. When everyone knows the plan, confidence and support go way up. If you want your plan to succeed, talk about it!

The Power of REALLY Listening

I’ll be the first to admit that I am not a natural listener. I’m much more of a talker by default, but over time I’ve learned that if you want people to listen to you more, you should ask them to do it less. It’s been a journey.

The Emergency

The other day, one of my senior engineers was tasked with solving an issue that effected a customer who needed the fix by the next day. Being a high-ability, over-achiever she took on the assignment and jumped into action. It was a part of the application that she was unfamiliar with, so she reached out to the methodical, detail-oriented lead of our offshore engineering team.

I was on a conference call at the time, so I wasn’t really paying attention to their conversation, confident that the problem was in some of the most capable hands at our disposal. The next thing I know, I’m distracted from my meeting by the frustrated shouting of my senior engineer “to just do what I’m telling you!”.

I quickly excused myself from my meeting, walked over to the engineer, and invited her to take the call in our meeting room. I hoped to both remove the unexpecfed conflict from the middle of the engineering team, and to buy a little time to figure out what the hell had happened.

When Reasonable People Scream At Each Other

I was shocked! I’ve experienced tension with co-workers and worked with some difficult personalities over the course of my career, but I had never had anything like that experience with either of these two. They had always been consummate professionals dedicated to working hard and getting the job done.

The gist of the disagreement it turned out was that my senior engineer was trying to get the offshore lead to do a screen share so they could inspect the code together to try to find the problem, and the offshore lead was adamantly against it.

The offshore lead objected that walking the code had a low-probability of success and was a waste of time, to which my senior engineer would exclaim that she didn’t care. Both of them were furious and frustrated, so it took a minute to get everyone calm enough to have any type of discussion.

The REAL Problem

Having worked with both of them for quite some time, it was pretty clear what had happened. My Alpha-type senior engineer has a tendency to take charge when stressed, and the methodical offshore lead tends to become defensive. With this important task and tight timeline, the senior had started by giving orders to the lead, which introduced stress into the situation and made the lead become more defensive (more stress), which made the senior even more insistent (even more stress), and on and on until the intervention.

The harder she pushed, the further he pulled back, until they weren’t even hearing each other. They both had valid points, and if they had taken the time to figure out where the other was coming from, considered their concerns, and shaped their communication accordingly there never would have been an issue. Instead, each was speaking their own language, worried only about their needs, and completely ignoring the other’s concerns.

Talking With Each Other

I took a moment to let the offshore lead know that I understood that the code inspection was a low-probability approach, but that it was the best one we had. If he had any better suggestions we would happily do that instead, but in lieu of a better idea could we please do the screen-share?

The senior got the solution she wanted, and the lead had his concerns heard and was given an opportunity to suggest alternatives. All together, from shouting to cooperation was under ten minutes, and we had a solution by the end of the day.

It was a great reminder that even experienced professionals are people with needs, insecurities, and desires. We may do our best to leave our peculiarities at home when we walk out the door and head to the office, but that’s completely unrealistic. If you want to truly influence someone or encourage a behavior, explaining what you need is never going to be as effective as understanding what they need.

It’s All In Your Mind

The phrase “you create your own reality’ may seem trite and overused, but it has a real practical side when it comes to leadership. Your mindset and how you frame problems dictates your approach to solving them.

Consider the following scenario:

The Newbie

Your team has been cruising for a while, and producing at a very high level, but some of your senior members have been a little overloaded and could use some help. After some interviewing, you hire a young, inexperienced person right out of college, and welcome them to the team.

Immediately the new person starts interrupting your day, breaking up your productivity with questions about everything from the team’s processes, to the simplest things about their job function, and even where to park and suggestions for where to go for lunch.

You find your productivity collapsing, and become more and more frustrated as they ask more and more questions. Can’t they see that you have work to do? Can’t they just figure it out on their own? Just as your frustration reaches a crescendo, they seem to become more self-sufficient, and leave you alone, and you are able to contribute more independently.

Who wouldn’t be frustrated by that scenario? It sounds awful. Let’s try, however, looking at the exact same situation from another angle.

Flipping the Mindset

Your team has been cruising for a while, and producing at a very high level, but some of your senior members have been a little overloaded and could use some help. After some interviewing, you hire a young, enthusiastic person right out of college, and welcome them to the team.

Immediately the new person starts digging into the problems, trying to learn whatever they can by asking questions about everything from the team’s processes, to the most important things about their job function, and even where to park and suggestions for where to go for lunch.

You find their productivity increasing, and become more and more excited as they learn more and more. Can they see how much they are contributing to the team? Can they just figure it out on their own? Just as their excitement reaches a crescendo, they seem to become more self-sufficient, and they are able to contribute more independently.

Now, doesn’t that seem like a far more pleasant and exciting situation to be involved in? All I did was change a few words here and there, mostly by switching the focus from you to the person you’re supposed to be leading, but it makes all the difference in the world.

Everything Is An Opportunity

In the first scenario, everyone has a miserable experience, the newbie probably receives perfunctory answers to their questions, and eventually stops coming with questions not because they didn’t have any more, but because those questions were so clearly unwelcome. This person is now having second thoughts about accepting the job, and will be more likely to act independently rather than ask for guidance in the future.

By focusing on the positives in the second scenario, you’ve made it fun and enriching for both you and the newbie. You have taken the mindset that they aren’t keeping you from doing your job, making the a contributing member of the team IS YOUR JOB! Every question isn’t a distraction, it’s more knowledge that they have, it’s another problem they will be able to solve in the future on their own, it’s an opportunity to positively influence a fledgling career, and a more enjoyable experience for both of you.

A conscious effort to keep a positive mindset not only leads to better productivity, better personnel growth, and a better team dynamic, but also better job satisfaction for you. If you ever find yourself doing something at work that you don’t want to do, see if you can reframe it in a way that accentuates its value, its challenges, or any other aspect that makes it less of an annoyance, and more of an opportunity.

Mindset dictates behaviors. If you want to display the right behaviors, make sure you start with the right mindset.

It’s All Your Fault

What is the single most important quality that defines a leader? Leadership has been a source of debate for centuries, from the “Great Man” theory, to Management theory, to Relationship theory. Where does leadership come from? Can it be taught? What defines it? Most people think of leadership in the words of Supreme Court Justice Potter Stewart, “I know it when I see it.”

What it’s not

No matter how Hollywood portrays it, or politicians pretend it is, leadership is not power and power is not leadership. The CEO may run around pointing fingers, making excuses, and being indecisive when the project is on fire while the intern is calmly asking the right questions and creating a plan of action.

A director may sit in an executive meeting taking credit for their team’s long hours, hard work, and brilliant insights while blaming them for any shortcomings while the project manager next to him heaps praise on the team and takes responsibility for the delays.

Powerful people display a distinct lack of leadership every day, and their subordinates often rise to fill the vacuum that is left behind. Leadership can come from anywhere. At its core, I believe it only requires a single thing…

Responsibility

Responsibility means ownership. Ownership of problems and ownership of mistakes. It means a lot of other things as well, but these are the two I want to focus on today.

Owning a problem doesn’t mean working on a piece of it, handing it off to someone else, and then considering your part done. Ownership means asking the questions to understand the whole problem, putting together a plan to resolve it, and making sure that every part of that plan is being executed. It means tracking what tasks are still in process, and continuously following up to make sure that the tasks aren’t being blocked, and if they are help remove the blockers. Owning a problem doesn’t mean fixing everything yourself, it means coordinating all of the fixes and tracking them until completion.

Owning mistakes doesn’t just mean taking the blame for everything that goes wrong on a project. It means asking the questions to understand what went wrong, putting together a plan to prevent it from happening again, and following up to make sure that the plan is being implemented. Every mistake made on the team could be prevented by the right process, the right training, the right communication, or the right plan. All things that the leader is responsible for. If you have the wrong people on your team, then it’s your responsibility for hiring them. If you have people on your team who cannot be trained or aren’t contributing, then it’s the leader’s responsibility for getting them off of the team.

Somebody has to do it

Responsibility isn’t just some evil that is the price to pay for leadership. Real leaders seek it out. They understand that unless someone owns the problem, it’s not going to get fixed; unless someone owns the mistake, it’ll keep happening. They want to be the ones who put their necks and reputations on the line to get things done and to solve the problems.

If your hand doesn’t go up when it comes time to solve the hard problems, if you don’t want to get involved because you’re afraid you might make a mistake, if you’re relieved when someone else steps forward and takes the burden, then leadership isn’t for you. Real leadership isn’t glamorous and powerful, it’s dirty, hard, and selfless.

Ask me to find the leader on a team, and I don’t immediately look at the person in charge. I look for the person who takes responsibility, volunteers for the thankless tasks that it takes to make the team succeed, and that person could be anyone.

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.