How Engineering Managers can Help Tech Leads on Projects in Duress
How Engineering Managers can Help Tech Leads on Projects in Duress
A practical guide on how to help tech leads when the going gets tough and the pressure builds up
Welcome to the Captain’s Codebook newsletter. I'm Ilija Eftimov, an engineering manager at Stripe. Each week (or so) I write a newsletter article on tech industry careers, practical leadership advice and management how-tos.
Let me tell you about Hannah. Hannah was a tech lead I worked with. Excellent engineer. A hard-working individual with a high sense of ownership. She was always tasked with complicated, cross-functional projects because she excelled at them.
As any tech lead, Hannah pulled a lot of weight. Her TODO list was always long: stakeholder management, leading technical architecture, day-to-day execution, managing the project team, work planning, and so on. While leading a big project, Hannah got stressed from the overwhelming responsibilities of running it. It happens to the best, too.
The pressure on the tech lead is high when a project gets messy. Complications take many forms, such as :
Stakeholders being challenging to manage
Shifting timelines and pressure (escalations) from leadership
Scope creep or constraints changing
Quality issues: complicated code, delivery problems, customer escalations
Managing team dynamics: conflicts, bridging communication and collaboration styles, motivation issues, straddling timezones
So, as Hannah's manager, I wanted to understand how to support, de-stress, and empower her. She was one of my best engineers, and I was ready to pay any cost to release the pressure that had built up. In continuation, I'll share some lessons I learned while helping out Hannah.
We will cover:
First step of getting help: admitting they need it
Calming down the nerves through new perspectives
Debugging the stress
Allocating more resources
Taking over responsibilities
Split-brain mode
Rebuilding confidence
Admitting they need help
Hannah showed signs of stress but couldn't admit that the project had issues. It wasn't her fault; other factors complicated the project. Yet, she took it on herself, doubting her engineering leadership skills.
Like Hannah, individuals with a high sense of ownership are great tech leads. But they also find it difficult to admit that they need help. People who take pride in their work think asking for help is a sign of weakness or incompetence (hint: it's not!).
Before I offered help, I wanted to get Hannah's explicit request for help. Stepping in to help without being asked can be perceived as an intervention. Instead of lowering the stress levels, an intervention would further stress Hannah, undermining her confidence and trust. It's always best to approach things with curiosity and patience in such situations. Steer the technical lead to the revelation that they need help through questions. Once they internalize that they do need help - jump in!
Some conversation starters:
“In the latest [PROJECT] update, you flagged we're having difficulties with [TOPIC]. Are there other challenges you're working against?”
“What aspects of [PROJECT] are going as planned, and where are we facing unexpected challenges?”
“How are you feeling about your workload with [PROJECT]? Is it manageable within your current schedule and responsibilities?”
“On a personal level, how are you finding [PROJECT]? Are there aspects that you're particularly enjoying or finding more stressful?”
“If you could change one thing about [PROJECT] or how we're approaching it, what would it be?”
Calm down the nerves
It isn't easy to appreciate all the team has accomplished when the project is still not over the finish line. Despite Hannah's outstanding leadership, she struggled to see the forest for the trees. Her team was in deep execution mode. Different individuals needed help, so she was often in the trenches with them - as she should. But it was challenging to keep an eye on the whole battlefield from the trenches. Trying to do too much added to the stress.
Once I received her request for help, I knew it was time to act. Hannah needed help managing her workload and energy, but we needed to work on getting her in a more relaxed state before we could get there. We reflected on the team's accomplishments. Together, we looked back at all the great achievements the team had so far. "See how far we've come, don't you think?" was my question.
Also, what worked was to provide Hannah with the external perception of the rest of the organization on her work. In other words, I explained how her peers and their bosses perceive the work that she is doing with her team. It was evident that people were impressed with her skills and that there was nothing to stress about.
Conversation angles to give perspective through:
When you look back at the past [period], what milestones stand out as our key achievements?
Can we discuss some significant hurdles the team has successfully overcome? How do you think these challenges have shaped our team?
From your perspective, what achievement are you most proud of regarding the project team's work, and why?
Given what we've achieved, what opportunities or new directions do you see opening up for the project team?
Debugging the stress
But it wasn't easy to get rid of the stress. Sure, the new perspectives helped Hannah de-stress a bit. But the stress was still here, still looming, waiting to strike.
In such cases, it's best to dig to the source. What is the problem? What _truly_ spikes her cortisol? Is it the project deadline? Is it the work that's still to get started? Is it the quality of the work? Was she afraid of causing incidents? The blast radius of the code changes? As an EM, you've got to let the questions flow in these situations. I did it, even at the risk of annoying Hannah. I just had to figure out what were the stressors.
In our case, the cause of the stress was the impending deadlines. There was still too much work, yet the time was flying by. Simply put, Hannah thought we wouldn't get to the finish line on time. And that was great - now we had something to work on. If you're in a similar situation, you must keep prodding to find the root stressors.
Once we uncovered the root, we could discuss mitigations. Would adding more people help? Can we de-scope something from the initial launch to ease the pressure? We could ship the remaining scope as fast-follows. Can we remove interruptions on the team? If yes, what are these interruptions?
Resisting to add more resources people
Projects can sometimes be de-risked by adding more people to the problem. It's the oldest trick in the management book. Allocating more people is a mitigation strategy for projects with low cross-functional dependencies or low-to-medium technical complexity. However, adding more people doesn't always work. It can be a trap.
Hannah's project was cross-functionally complex. Delivering on the project needed lots of coordination. There were dependencies. The involved teams were spread between many time zones. Different cultural backgrounds made communication challenging. Hannah grappled with coordination, which pulled her away from what she enjoyed doing - solving difficult technical problems.
Adding more people in complex cross-functional situations won't do the trick. Such projects usually get stuck within the dependencies, i.e., team A is waiting on work to be done by team B. Adding more people to Hannah's team was not the right move. She would need to spend even more time coordinating both within the team and externally.
We both agreed that she needs not more people but more help with coordination.
Take over responsibilities
When a tech lead struggles with organizational complications, it's worth investigating everything they need to do to keep the project moving. In Hannah's case, there were dependencies to track, coordinate with other teams involved in the project, code, help other contributors, make progress updates to management, etc. It was evident Hannah had too much on her plate.
In these such situations, engineering managers have to detect the needless shit. Then, become an umbrella for your tech lead—even a hazmat suit. Do whatever you can to make their life easier. There are administrative tasks, stakeholder management, meeting running, cross-functional team communication, and much more to take over. As an EM, you should think through the prism of servant leadership: provide support, remove obstacles, and stay away from the critical path.
In Hannah's case, I began by attending daily sync meetings, following written communications, and taking over tracking dependencies. In meetings, whenever Hannah or her team didn't receive a crisp update or commitment from another team, I would play the "dumb manager" card and say, "Just for my understanding: we're expecting the new [COMPONENT] to be ready by [DATE]—are you folks saying that it will be ready by that date? Or are we delayed?"
When dependencies were not panning out or the team got mixed messages, I'd go to the technical project manager and start flagging issues immediately. Engineers are conservative about raising flags, but as a manager, I find it necessary—as long as the engineers are not disrupted by the ruckus.
Taking over responsibilities from Hannah allowed her to remain close to the technology, the code, and the architecture.
Split-brain mode
With less experienced tech leads, one easy way for the tech lead to load-shed responsibilities is to hand over the project logistics to the engineering manager. In this 'split-brain' mode, the tech lead gets more mental bandwidth to remain in the details, while the manager can cover the cross-functional processes and alignment needed with the project.
Some examples of the cross-functional coordination aspects:
Collaborate with PM on how the new product will interoperate with existing products
Bring in non-obvious stakeholders to the table
Get buy-in on the change of plans or new timelines from leadership
On the project logistics side, they can:
Consider whether the project has the right expertise. Would it benefit from more people or people with newly acquired skills?
Identify potential risks to the project, including technical, resource, and timeline risks.
Audit team processes and find opportunities for streamlining or optimization
Prioritization and scope. For example, if there's too much at stake for the initial launch, identify things to de-scope and fast-follow.
Rebuild their confidence
Hannah did a great job as a tech lead, yet she doubted her abilities. All of that was because she struggled with the project due to too much necessary coordination. Individuals who take pride in their work struggle in such situations, as they doubt their abilities. Understandable.
The engineering manager must rebuild the tech lead's confidence in such situations. So, choose the next project wisely after the team completes the complicated project. It must be complex enough to be engaging, but you must be sure it will be a home run for them. Having a project they succeed at will reassure them that the issues on the previous project were transient and do not speak about their abilities overall.
And once they hit that home run on the next project use the opportunity to reinforce the idea that their skills are up to par. Say, "You did a great job here and nailed the project. You see, the struggles you had before had nothing to do with your competence or abilities".
And that’s it for this week! If you liked this, consider doing any of these:
1) ❤️ Share it — Captain’s Codebook lives thanks to word of mouth. Share the article with your team or with someone to whom it might be useful!
2) ✉️ Subscribe — if you aren’t already, consider becoming a subscriber. Seeing folks read the newsletter energizes me and gives me ideas to write.
3) 🧠 Let’s chat — I am always on the lookout for questions to answer, to help out with challenges, or topic ideas to cover. Hit me up on LinkedIn, Twitter or send me an email to blog@ieftimov.com.
Until next time,
Ilija