Just became an engineering manager or aspire to be one soon? This post might save you a couple of weeks by bringing you insights and learnings from other engineering managers’ mistakes.

In my past two companies, I’ve had the privilege of leading an engineering team. During this time, I experienced and learnt from the common mistakes that managers tend to make. Believe me, it can drastically hamper the team productivity and growth. When I started Middleware, I was fortunate enough to interact with 100s of engineering leaders and learn from their experiences.

In this article, I’ll be sharing the top 5 mistakes engineering managers make and their possible solutions.

Let’s dive right in!

Mistake 1: Macro management first, Micro management later

Every manager starts with high trust on their team. Hence, they start off by purely delegating the tasks to the report assuming it’ll be done. However, it is not un-common to get blocked or stuck during execution of the task. In the case where a manager is oblivious to this blockage, they only get to know when the task is on a delay.

That’s when they panic and start micro managing because now they don’t trust. Of course, this lack of trust does make their people unhappy(even more unhappier than they were happy) leading to burnouts.

Hence, always..

“Trust, but verify”.

What you can instead do is, micro manage first and macro manage later. Here’s how:

• Create a detailed plan with the team

• Bring a consensus on a timeline which they believe is right

• Now, always follow up on the execution of that plan and be available to unblock them whenever they need you

This makes the discussion objective and constructive than a blameful one and hence fosters more trust and ownership in the team.

Mistake 2: Never say “No”

Said yes to ad hoc tasks every sprint and now you can’t seem to complete the spilled tasks?

This is what you call a negative spiral. I’ll give you an example of our team’s early days.

A few sprints back, my team was working constantly while still spilling their planned work. They were starting to feel burnt out and that’s when I observed the sprint flow below.

Source: Middleware

Our ad-hoc task % was rising sprint on sprint and that made our team de-focus from the planned work, resulting into spillage and hence missing the product delivery targets.

Solution: We put a threshold of 20% on the ad-hoc tasks. This meant, we dedicated only 20% of our effort towards ad-hoc. Anything beyond 20% was alarmed(by Middleware) and said “No” to those tasks. This reduced our planned task spillage and also team burnout.

The result of it? Our product delivery became more predictable.

In fact, in the sprints where there was no ad-hoc work, we started shipping tech level enhancements more!

In all, I’m glad we started saying “no” beyond our threshold. It’s simply because it was not aligned with our goal.

Mistake 3: Become the most important person in the room

If you think that you are the most important person in the room, it’s time to flip your perspective.

Instead of being part of every discussion, empower the team to run without you. It not only enhances productivity of each team member, but boosts their morale too! As a bonus, you also get time on your hands to make other vital decisions.

Now, how to relinquish control when all you have been doing is ensuring that you are part of each and every discussion?

Collaboration

Let’s talk about this with the help of a common example:

The majority of meetings on your calendar are product discussions with the team where you also need to give approval on what is supposed to go as a part of development.

Till now, you were conducting meetings to give your context. Now what you can do is to just pass over a note of context and expected outcomes to the concerned team members.

To prevent another open discussion, the devs can use technical documents to achieve success.

Lastly, in case there is any context missing, you can write it in the same doc itself. Easy-peasy, right?

Mistake 4: Expect the product managers to give perfectly written tickets

Chances are, you must have faced these situations as an engineering manager -

“The team is blocked because the stories didn’t have the details”

“The stories have the edge case missing, please revert on those”

These scenarios block product delivery.

To avoid the above situations from occurring, an engineering manager should not directly pass the user story written by the product manager to the engineer.

Instead, you should sit with the product manager and refine these user stories to add engineering details like constraints of scale and the expected deliverables. You should also break down the user story into atomic deliverables.

I call it the “pre-planning” stage.

Pre-planning between PM and EM

After this, the developer gets the complete context and they can then act upon these atomic deliverables.

The advantage of this entire practice? It saves tons of back and forth.

Pro-tip:

If you’re able to break down the user story into independent tasks, you can also get them built in parallel. Doing so will decrease your time for delivery.

Mistake 5: Have different definitions of “Done”

Let’s admit it — We all have faced this at some point of time in our work journeys.

Having different definitions of “Done” can lead to no or delayed delivery to the actual customer. Hence, it becomes more important than ever to ensure everyone you are working with is on the same page with what “Done” actually means!

“Done” means released to the customer. That’s it, that’s the definition it should have.

Pro Tip: As you know, multiple team members are involved on one particular feature. What you can do is, create a primary owner for the feature. This means, this person will communicate about the feature’s progress on behalf of the entire group. The benefit of it all?

Apart from fostering a sense of ownership among your team members, it will also highlight the visibility of your team’s efforts.

Learning from the mistakes!

Since there is no silver bullet to engineering management, every manager has to pave their own path. However, it helps to learn from the common ‘eeks’ and ‘oops’ of the people who have walked this path before you.

Hope you recognised some of the mistakes you would have encountered, let us know in the comments 💬

PS: Thanks to our amazing team for the review &Amogh Jalan, Samad for their inputs and edits!