This is the 3rd in a series of 4 articles I’m writing about engineering management. The first talked about valuing, respecting and nurturing people, the second was about delivering business value, and this one is about being an effective team member yourself while managing people, and earning the respect of your team.

Your #3 Responsibility: Understand in Detail

To be an effective engineering manager, you have to grit out the details: this is often a difficult job especially if you don’t understand the problem space, or you are unfamiliar with the technology stack. The important thing here is to be humble:

1. There will always be team members who know more than you do. As an engineering manager, your job is not to be the “know it all”, the bloke who provides all the answers. Your job though is definitely to understand what those challenging problems are, and continuously work with the team, the business, and at times, even external consultants to solve these problems. In short: you are an impediment remover, but to remove these obstacles, you have to first know that they exist.
2. The best^[1] way I’ve found to understand these problems is to work as part of the team. So if you manage a scrum team, you allot a few of these stories to yourself. Let me be very clear here: The aim is not to prove that you are a rockstar. In fact, it might help the team (& give you a dose of humility) if they see you struggling and they come to your rescue. You should not hold yourself to unreasonable standards here: in fact it’s very likely when you first join a team that you will make stupid mistakes, bring down a server, and generally make a mess of things. You should accept all of these mistakes with grace, and ask for help from the team to fix these issues.
3. So what’s the point of being part of the team and working like them? I’ve found that if you are curious, and if you approach development with a mindset to fix problems at their root causes, and to constantly strive for long-term stability, you will identify several areas where you can make a difference. These differences are mostly because of your broader overview of the business, and how you can mobilise resources that the team doesn’t know is available. As an example, when teams struggle with technical debt, and the problem of “when I fix one thing, something else breaks”, you can see a test automation strategy taking shape. When you break the build twice in the first week^[2], you can see that those same automated tests are very fragile, and break at the slightest change in business logic.
4. Most times, you might not be the most knowledgeable person in the room. But sometimes you are. Maybe because you have “done this before”, and you know a quick and easy fix here. Or maybe because you point out problems in a possibly dead-end approach, and maybe because you bring in new resource or a new way of thinking: “How about we use AWS SQS for this instead of our legacy Rabbitmq?”. At these times, you are a genuine value multiplier.
5. My thumb-rule for new engineers here is: deliver at least 5 story points every sprint (or if you’re not story-pointing, at least 2 stories). And if you have time, deliver as much as you can. It’s also good for the soul: for a bit of time you can get away from squishy world of humans and struggle against a computer instead 😉

Earning Respect

So earning respect is at the same time the most simple and difficult thing you’ll do as part of your job. Be a part of the team, do the same work they do (even if you do it worse), and help them solve their problems. Listen to them, and together, build the best team you can.

So that’s it! Next week, some assorted tips about managing people, and some closing thoughts!

^[1]: This is the only way I’ve practiced engineering management, although there are teams and companies (example) that separate out the people management and nurturing function entirely from technical leadership. I understand why they do that honestly: managing people is often a full-time job, and clubbing it along with an individual contributor role is challenging.

^[2]: This is a real example, just from last week! 🤭