Dealing with negative feedback from a high-level executive

Mike is a software development manager at Captar, a post-series C startup going through hyper-growth. Mike had been with the company for almost two years and is considered very strong technically by his peers and direct reports, who regularly give him great feedback.

Lately, Mike's team was responsible for the development of a complex service as part of Project X, a big project with high business value. As expected in mid to large size projects, re-iterations, unexpected dependencies and other technical blockers, led to a delay on project X by almost two quarters.

During the project, the inter-team oral check-ins between Mike and Kumar, the CTO (two levels above Mike), seemed to be OK with little digging from Kumar when discovering delays. On the other hand, Mike's manager was little involved, since the two of them don't have a great relationship.

During the post-mortem with his manager, Mike discovered that Kumar had a very negative appreciation of Mike's handling of his project. More specifically, the CTO found that Mike lacked transparency and engagement, and had a 'blaming' attitude, calling out discoveries as 'new requirements'. More importantly, Mike's delay is being blamed as responsible for the overall delay of project X.

The feedback seems motivated, and Mike's manager is asking Mike to consider going back to a senior individual contributor role, with no responsibilities on project deliveries and communication.

What should Mike do?

What happened to Mike is a classic case of bad upward management and communication from Mike. During the project, Mike focused on reducing delays by solving every new challenge that was discovered and trusted his managers to understand how complicated his situation was. Before getting to what Mike should do now, let's see first what Mike should have done.

When technology organisations reach a certain size, high-level managers do not have the ability anymore to get into the details of every single project. They're also under much more pressure since they're always dealing with the business impacts of technology decisions. With that in mind, even with the best intentions (which might have been Kumar's case during the project), high-level executives don't have the time to appreciate unexpected discoveries.

What Mike should have done:

• He should have had regular structured communication towards his managers (both his direct manager and Kumar). Such communication could be a dashboard with the key project metrics, traffic light indicators to express progress, and should have been sent weekly or bi-weekly.
• He should have focused his communication on the business impacts of every single discovery, rather than the technical explanation of why this was unexpected.
• He should have organised meetings with key stakeholders (with written minutes sent out) every time a significant delay was forecasted, with proposals on how to reduce it (changing the scope, hiring contractors, using other teams…)

What probably happened is that since Mike is technically proficient, the time he should have spent on communication was spent with his team on architecture, implementation and other technical challenges. That's why Mike's manager believes Mike should go back to being an individual contributor.

Now, if Mike still wants to continue working as a manager (at Captar or elsewhere), he has to focus on two things:

1/ Repairing the relationship with his manager: we don't always choose our managers, and some relationships are more challenging than others. But if Mike's manager is competent and honest, there are no reasons why the two of them couldn't work together. A good starting point for Mike would be to ask his manager what he should do to improve his behaviour as manager (with objectives and metrics) and use their regular one-on-one(s) to monitor his progress.

2/ Start acting as a manager rather than a tech lead: a manager's responsibility is to make sure his team reaches their objectives while making sure every individual is the best version of themselves. To do that, managers should spend 60-80% of their time empowering individuals in their team (to address technical challenges, for example), without working on them themselves. The rest of their time should be spent on communication, inside the team and outside.

But going from being (a strong) individual contributor to being a manager can be challenging, especially if team members rely technically on their manager, whether it's because they know the codebase better, or because they're just more experienced. In this case, the very first step for Mike would be to make sure his team becomes much better than him technically (through training) so that he can focus on coaching and communication, rather than operations.

One last note. This whole situation wouldn't have happened if Mike's team had sufficient time before the project to analyse dependencies and scope it more accurately, but we know how these big projects can come out of nowhere and have to be completed for yesterday 😉