When to intervene
Lean In
In the course of the last two decades, the realities of what a manager is and does has dramatically changed. Long gone are the days of type A, loud, cigar-smoking, suit-wearing men giving orders to perpetually overworked and scared employees. They have been replaced with empathetic and diverse leaders who encourage bottom-up thinking and use empathy and empowerment to motivate employees. However, in this loud drumbeat of how to behave like an all-empathetic, all-empowering, all-caring 21st-century manager, an important fact gets lost. The hard truth is, at the end of the day, you, as a people manager, are responsible for ensuring you are getting the most out of your team and delivering a positive return on investment for your company. All the decisions your team is making, you are automatically underwriting them. If you constantly keep underwriting bad decisions, at some point, your boss will fire you. I am sure we managers have had moments when we go in our heads, 'Hmm….I am not sure my team is doing the right thing here. Should I intervene, or should I let them figure this out?' This post is about when to intervene and how.
People Issues
Employees and their work-related issues are one of the most difficult categories of issues to fix and the bane of every manager's existence. However, they can cause a lot of damage if left unchecked. There are broadly two categories of people-related issues that a manager needs to intervene in: individual performance issues and personnel conflicts.
I have talked a lot about individual performance issues and how to deal with them in my previous post. Additionally, there is a ton of material online about this topic, so I won't go into this in detail in this post. TLDR is, if anyone (somebody on your team or someone in the company) comes to you with concerns about an employee's performance or you have your own suspicions, please act on it. It is always easy to ignore these things but listen to the annoying voice in your head. With that said, let's get into personnel conflicts and how to resolve them.
Personnel conflicts can severely impact the productivity of teams. Conflicts typically happen when two people (or groups of people) have to align on a path forward and are unable to do so. In my career I have spent thousands of hours trying to resolve conflicts inside and outside my team, and I have come to the conclusion that convincing people to do something they don't want to do is a fool's errand. I have tried cajoling, using authority, using their bosses' authority, hardball tactics, softball tactics, and a million other things. I even read Harvard's MBA course material on negotiation and tried using it! I can't point to any of those things as a sure-shot way of resolving conflicts.
IMO, the most effective mechanism to resolve conflicts is to create a set of employee behavioral tenets (a.k.a values) that clearly describe how employees should resolve conflicts on their own.
This way, you are not trying to change people's behaviors every time there is a conflict but are preemptively telling them what are acceptable behaviors and outcomes. Ideally, your company values include values that tell employees how to navigate conflict situations. Amazon has 'Disagree and Commit' and 'Earn Trust' that help employees navigate conflicts, and IMO is the best example of how company values can be used to resolve conflicts. Netflix also has a handful of values that teach their employees how to navigate conflicts, e.g., 'You use data to inform your intuition and choices,' 'You make decisions mostly based on their long term, rather than the near term, impact,' 'You debate ideas openly, and help implement whatever decision is made even when you disagree,' 'You make tough decisions without agonizing or long delay,' and so on.
Take Google, on the other hand, which does not have a company value around this. I have many friends and family who work at Google and can say with some level of certainty that Google struggles to make decisions as a company. There is a lot of discussion and heated debates about even the simplest decisions that slow progress down to a crawl. Google is not the only one with this glaring deficit. Microsoft is another one, and we all have heard about the horrors of politics that employees have to deal with over there. In fact, most companies do not have explicitly defined company values that provide their employees with a blueprint for navigating conflicts without breaking trust with each other.
After encountering multiple companies that didn't have corporate values around conflict management, I decided to create my own set of tenets that I hand out to my team. This is what I use
Never shy away from conflicts. Yes, It will be uncomfortable, but you, as a leader, are obligated to lean in and find a path forward.
Display a high level of emotional intelligence. Never become passive-aggressive or aggressive.
Have a cause and conviction.
Base your arguments on sound business judgment, not your personal opinion.
Validate your assumptions with your peers, your manager, other teams and against industry standards.
There are no absolutes in life or business, be ready to compromise. We all live in an imagined reality.
Feel free to repurpose them for your team as you see fit. The bottom line is, focus on creating a conflict resolution blueprint for your team versus focusing on getting better at teaching individuals how to resolve every single conflict.
Project Management Issues
Project management! The crucible where every engineering manager's dreams and aspirations will be crushed, melted, and reforged into the realities of the revered quarterly timeframes in the corporate world. OK, fine, that is being a bit too dramatic. But, project management is another area where engineering managers need to intervene if they see issues crop up. Project management issues typically fall into two buckets: issues that crop up during planning and issues that show up during execution. Let's unpack.
Planning Issues
The biggest planning-related complications occur when the team is planning large projects that could span multiple months. I can almost guarantee that if you ask your team for an end-to-end estimate for full delivery of any project that will go beyond two or three months, they will tell you the answer is six months. The key is to ask the team to break the project down into milestones and ensure that the distance between each milestone is less than a month. If the team is unable to scope the milestone down, then start cutting scope until you get a milestone that is reasonably timed. This is when you can also find out if your team is sandbagging estimates and/or making incorrect assumptions. If you don't do this exercise, I can almost guarantee failure. At the most, a team can accurately plan for a month. Anything beyond that, I can almost guarantee some gremlin (scope creep, bugs, acts of god, vacations, etc.) side-swiping the project that will push it off the tracks. So, to recap, if your team can't scope projects down to monthly milestones (or less), you, as their manager, have to intervene and work with your team to scope it down to under a month. If your team is unable to figure this out after a lot of hand-holding, you probably have the wrong people on your team. I understand that most teams are not filled with rockstar engineers, but there should be at least one senior/staff level engineer on the team who can help you get the team to do what they don't want to do.
Execution Issues
Execution issues typically center around timelines slipping because of three reasons,
Inertia setting in because the team can't agree on a path forward, a.k.a analysis/paralysis
Timelines slipping because the team keeps uncovering new complexities
individuals on the team having a performance issue.
I am not going to talk about #3 because I have beaten that to death in a previous post. My rule of thumb is if an individual misses a deadline three times in a row with everything (scope, tech complexity, etc.) remaining relatively constant, then something is going on with that individual. Let's unpack the others.
Analysis/Paralysis
If you put a smart group of engineers in a room and ask them to solve a complex problem, there is about an 80% chance they will get deadlocked about how to move forward.
This problem is especially acute when they are working on a greenfield initiative. The biggest delays usually occur during the planning/design phase of the project. Greenfield initiatives are a magnet for a thousand great design ideas and a thousand more bad ideas. The more people involved in the project, the worse it becomes.
When I am kicking off greenfield projects, I always make sure there is ONE person responsible for the design. I typically assign a senior engineer (or an engineer on their way to becoming one) responsible for design, and I empower them to make critical design decisions for the project. This doesn't mean the engineer operates in a vacuum. Peer feedback is essential, but I empower the engineer to move forward with design choices even if it isn't super popular with their peers, as long as I (the manager) am comfortable enough to underwrite that decision. It is natural for humans, especially engineers, to look for consensus, and this is where delays come in. Engineers will pore over every single negative feedback and try to figure out how to accommodate that feedback into their design.
One of the mechanisms I use to enforce efficient decision-making is design milestones. I don't give teams more than a month to hash out the design for any project. Most designs should typically take a couple of weeks. If I notice the team missing the 'design locked' deadlines a few times in a row, then I intervene. I typically sit down with the lead engineer and the product manager and prioritize the outstanding design decisions based on what we believe is needed for the first version of the product. We then talk about how much additional time it will add to the overall project and start ruthlessly culling that list. As long as the decision is a two-way door, and most engineering decisions are, I am comfortable pushing forward and moving the mid and lower-priority changes to later phases.
Timelines slipping
This is also a common occurrence in complex projects. This is when the team starts micro-slipping on their planned projects, which ultimately will accumulate into full-blown project delays. I typically intervene when the team misses deadlines on a project more than twice on the same tasks.
Good engineers are always looking to make their mark in the team and the company and going the extra mile, so when their product manager tells them, "There is a small change in scope," they try to absorb it in their current timelines by working a bit harder. Obviously, the team can't absorb this forever, and at some point, delays creep into the project. The fix is straightforward. Take a pause, sit down with the product manager to either cull the new scope or, if the new scope is absolutely needed, re-plan and adjust timelines as needed. However, if this happens a handful of times, you have to take a stronger stance and, start questioning the entire project and push the team to figure out what are the bare minimum list of features needed to get a delightful product in the hands of customers sooner rather than later. Feature scope creep is not the only flavor you will encounter. Additional engineering complexity can easily creep into large, complex projects. However, the solution is the same. Pause, figure out if the scope is actually needed, re-plan, re-adjust timelines, and communicate.
Communication Issues
Chinese whispers are the bane of every manager's existence. There is nothing like a game of badly played telephone to ruin project timelines, destroy trust, and crater promotions. The biggest communication issues occur when communicating statuses upwards. Imagine for a second you were out sick on status update day. You wake up bleary-eyed and shoot off a hastily written email to your team saying you are sick and ask one of the engineers to represent the team in the weekly status meeting. When it is your team's turn to report on status, this is what your engineer says -
The engineer says, "Hmm, it feels like we are still green, but it is hard to say with certainty if it will stay green next week. There are still a few weeks worth of work remaining".
The project sponsor, now a bit worried asks, "This is the first I am hearing about this. Why do you think you won't be green?"
"I don't know"
"Then how do you know you won't be green next week?"
"I don't, but we haven't planned the next two weeks of work, so there COULD be unknowns there".
"Can you take a rough guess on where the risks might be?"
"I don't think there are many risks."
"You just said there might be risks."
"Actually I said unknowns, not risks. I don't know if one of those unknowns will become a risk"
"Sigh"
A week later.
"Did you hear that MG's project is delayed by multiple months?"
"Where did you hear this?"
"Oh, Andy told me."
"I just had a 1:1 with MG an hour ago, and he told me things were on track."
"Oh, I don't know. I am just telling you what Andy told me."
"I think I will bring it up with my boss, just in case."
This is obviously a hyperbolic example. The point I am trying to make is, managers typically have more context about the state of things than the engineers on the project, so you have to keep an eye out for incorrect messaging about your team and intervene as soon as possible, especially status updates. I keep in close touch with all my stakeholders, and I tightly control what statuses are communicated upwards and sideways. If I fall sick on status day, I write up the status and send it to all my stakeholders, including the person who ends up representing the team on my behalf. Nothing against engineers, but I have found that product managers are often better suited for reporting statuses (especially a bad one) than the engineers on the team. So whenever I am out of pocket, I typically lean on my product counterpart to represent the team in status meetings, metrics reviews, etc. Most engineers lack nuance. Sorry! But that's the truth.
A quick recap of takeaways from this section
Bottoms-up doesn't work all the time. There will be situations where you have to lean in, take charge, intervene, and forcibly change things.
Create tenets that employees can use to resolve conflicts on their own versus solving it for them.
Force your team to break down larger projects into smaller customer-facing milestones that are less than a month apart.
Create time boundaries for the design phase of projects and intervene if the team misses the deadlines more than a couple of times. Pay very close attention to this milestone for greenfield projects. Be comfortable making two-way door decisions.
Watch out for scope creep.
Keep an ear out for incorrect narratives about your team or the projects they are working on, and intervene quickly. Be VERY careful of delegating communications to someone on your team.
Coming up next week - Why managers need to write well!
P.S. - If you enjoyed this post, consider sharing it by clicking on the button below!