The Ten Commandments of an Engineering Manager
Some practices should be considered holy
You’re the engineering manager (or one of them) for your company — congrats! You’ve made it!
But do you realize the responsibility that lies in your hands? You’re not just “the boss” for all those developers whaling away at their keywords like there’s no tomorrow — you have obligations towards them and the company you work for.
So here are the 10 commandments you shall follow from now on, based on my own experience as a manager and as a developer who loved some of his managers and hated a lot of others.
I hope it helps!
Thou Shalt Let Your Devs Do Their Own Work
There are two types of Engineering Managers, those who understand they’ve chosen a path that takes them away from writing code and those who are just thick-headed.
Look I get it, I also like to code, but do it on your own time. You probably have other responsibilities day-to-day, instead of putting on the developer hat because you think your team is not cutting it.
If you’re really having problems with your deliverables, tackle them directly. Understand what’s missing. Is it that some of the devs are too inexperienced? Then train them! Is somebody not following standards or just taking too long to finish a task? Then talk to them and try to understand what’s wrong!
There are multiple alternatives to every potential problem that do not involve spending your day coding.
Don’t get me wrong, there’s nothing wrong with coding, but it’s an activity that requires time and concentration. You can’t code while in a meeting — not unless you ignore the meeting — and you can’t code while answering emails or while you have a 1:1 with someone on your team. Really, coding to close even the smallest ticket from your backlog takes at least a few hours of your day.
Even if you look at it from a monetary point of view — how much is your company paying you to do something that someone else should be doing for less? Again, that may sound cold and harsh, but if it helps you to look at it from that perspective, then go ahead and do it. Just understand that whatever is forcing you to want to code is a problem you need to tackle.
You Shall Not Worship False Gods
We all love those people who you can give a task and then forget about until the task is done. They’re gods to me. I know I can count on them to solve their own problems and only come back to me with a solution or a really big issue they don’t have the means to solve.
But while they might feel like gods to me, they’re not. Nobody is. Everyone in the team — and that includes you, buddy — can be replaced, so act accordingly!
That doesn’t mean work like you’re about to get fired. It means you need to understand that neither you nor the best people on your team should get better treatment than anyone else. You are leading a team (or teams) of people and as such, they all deserve to be treated equally, no matter their sex, place of birth, sexual orientation, where they learned their trade, or anything else.
This doesn’t mean you can’t reward exemplary behavior either. There’s a very fine line between rewarding the things they do right and just giving them preferential treatment because of who they are or where they’re coming from. In some situations the line can be very blurry, so you have to tread carefully.
It should always be about the work they do and everyone should have the same opportunities to get that recognition.
You Are Not the Sharpest Knife in Your Kitchen and That is Fine
You’re not the engineering manager because you’re the best developer, or because you’re the best at gathering functional requirements, or anything that your team needs to do really. That should be the people on your team.
Leave the ego behind, you’re not there to teach them how you’re better than them. If anything, some of them will educate you daily on why they’re the real MVPs.
You on the other hand? You are great at managing them, which is why you’re the manager. Get it? Stick to your job description.
Look, as a manager you could potentially be leading people working with multiple technologies and you can’t expect to be great at them all. In fact, you can’t even expect to stay up-to-date with the latest developments or frameworks on all of them. And trying to do it can end up eating too much time of your day and for what? So you can show ’em you’re still “the man”? That makes no sense.
Understand where your place is and stick to it, mind you, if you want to read about tech and learn about the tools your teams are using that’s fantastic. But don’t expect to be the best at it. That’s not what your bosses should be expecting of you and that is not what your team wants you to focus on ultimately. After all, you’re there to help with the problems they can’t solve because they don’t have enough reach.
No-Deploy Fridays Are to be Kept Holy
Have you forgotten what it was like to deploy on a Friday already? According to Murphy’s law:
If a deployment is attempted on a Friday, whatever can go wrong with it, will.
And that’s science!
Honestly though, having the power to force a deploy on a Friday (even if it’s supposed to start in the morning) doesn’t mean you should do it. Everyone wants that feature to be deployed to production ASAP, and probably the business is pushing to do it. But you’re the Eng. Manager, you know better.
I’ve seen my share of managers who would ask us to come work on a Saturday after a terrible Friday deployment, so we could get that code up and running as fast as possible. And hey, they’d offer to pay for the pizza as well. But they did it because they were pushed by the business and didn’t know how to say no. So now the team has to solve a problem that could have been solved on Monday but, after a bad deployment is now on a Saturday, sacrificing personal time. Don’t be that manager!
Your role is to be a wall between business (or whoever is above you in your organization) and the devs. You choose what you let through and what you don’t. It’s not a fun place to be at times, because that means saying “no” to your bosses to protect your team. It means being yelled at because something doesn’t work and then understanding how to communicate that to the team in a productive way.
Keep your team’s best interest at heart when making decisions and if you’re not able to say “no” to that deployment request, then make sure everyone understands why that is, and make sure your team is actually ready to deploy.
If you liked what you’ve read so far, consider subscribing to my FREE newsletter “The rambling of an old developer” and get regular advice about the IT industry directly in your inbox
Your Teams Will Not Learn Everything By Themselves, You Need to Guide Them
One of your main responsibilities is to make sure your team is up-to-date with the tech you’re using. That, however, doesn’t translate into asking them if they know what they’re doing it.
It means you have to give them the tools to learn. That can be any or all of the following:
- Time to study. Not everyone is willing to be trained during off-hours, sacrificing personal time. If you’re introducing new technology to your stack, make sure study time is allowed for the people who need to catch up.
- Learning resources. This can be anything from buying books, to paying for online courses, to writing the actual documentation yourself. Either way, you can’t just say “well team, next month we’re refactoring our front-end. We’re ditching Angular and starting to use React, so get learning” and hope everyone finds a way to learn React in a month.
- A reason. This one can be controversial, but it’s important for everyone on the team to understand why they’re now suddenly supposed to be learning new tech. It can help them to find motivation and to pay more attention to the training provided.
Thou Shall Never Make a Mistake — But If You Do, It’s Important to Recognize It
Look, you’re not perfect, the manager title doesn’t imply that. You can make mistakes, just like anybody else on your team.
You know what else? You can also recognize those mistakes. That’s the only way to learn from them and grow, personally and professionally.
There are but a handful of things that are worse in our industry than a manager who can’t recognize when they’ve made a mistake. Especially if that means publicly accepting that someone else on their team was right.
Egos are a terrible thing in our career — you need to be extra conscious about yours.
A good practice that more and more companies are implementing these days is 360º feedback. In other words, you not only give feedback to your team, but you also expect them to provide you with feedback on your own performance.
This can be in the form of 1:1s with everyone on the team, or it can be done anonymously. The latter is very useful given that not everyone will be comfortable giving negative feedback to their managers. However you decide to do it, keep in mind that every piece of negative feedback you receive is an opportunity to improve at your job. Don’t take it personally — it’s a growth opportunity.
You Shall Not Worship False Gods — Tech Edition
I don’t care if, during your development days, you worked with Java and everything was good. Technology moves faster than any of us and keeping up with it is becoming a daunting task.
Sometimes it’s best to recognize that your current tech stack might be a little out of its time. This can be evident if, for example, you can’t find junior developers who know the technology — meaning that everyone who knows it has literally been working on it for years and new technologies have replaced it in the eyes of newcomers. Or if senior developers don’t really like the idea of joining your company and working with that tech.
Refactoring a whole project (let alone multiple ones) can be too expensive, which is why some banks and other old institutions are still using COBOL as their main language. However, that doesn’t mean you also have to start every new project with it. You can start adopting new technologies and trying them out by using them on the new projects, even if they’re just small internal tools only your team will use.
Figure out a way to keep your teams updated. They’ll be happy you did because it will keep them from getting bored by learning a new thing. It will also be good for them to stay in touch with the latest trends in the industry.
The Better Things Work When You’re Not There, the Better You’re Doing Your Job
Want to check if you’re doing your job right? Take a vacation — if everything goes to hell, then you’re doing a piss-poor job!
It’s that simple, as an engineering manager you’re a facilitator. You help people solve their problems. If you’re doing it right, you’re helping them by showing them how to solve them.
If instead, you’re the one directly solving everyone’s problems, then you’ve inadvertently become a single point of failure for your entire organization. The moment you’re gone, or are just unreachable, nothing can get done. That’s a terrible place to be, even if initially it feels great. Think about it, you’ve robbed your team of their ability to think for themselves, now you’ve become the brain of the team. Or if we want to use fancy terms, you’re micromanaging them. That sucks — for them because they’ll feel the loss of autonomy and for you because it’ll eat up most of your time.
How can you solve this if you’re already the single point of failure? Start delegating tasks, find people you can trust in your team and start giving them some of the tasks you’re doing now. Train them, of course, but delegate. Start with the tasks that are closer to them (like leading the daily SCRUM meeting, or the sprint planning session).
The goal is not to delegate yourself out of a job, but rather to give them the tools to work without you having to look over their shoulders every minute. In turn, this should free up a lot of your time to focus on higher-level stuff, which is probably something you want.
Standardize the Standards You Stand and the Ones You Can’t Stand as Well
People are different and the more people you have on your team, the more ways of doing the same thing you’ll find.
This is not ideal in a work environment. New joiners (for instance) will take longer to understand how to best perform different tasks. Sharing tasks among colleagues can be a problem if they don’t do the same thing in the same way.
For example, if you don’t standardize the way unit tests are written, then two projects may have different standards, and sharing people between them can become a problem. They would have to re-learn the tools and methodology every time they move from one project to the next.
Standards for development teams are very important because they remove the need to think about the “how” and only worry about the “what.” In other words, worry about the fact they need to write tests but don’t spend time trying to figure out the best way to do it.
This should considerably reduce the time it takes to onboard people into the company, no matter what project they’re joining. Heck, even non-tech people will get benefits from this if they have to jump from project to project.
I Am the Engineering Manager and These Are My Rules…
But if you’ve got some other ideas I’m open to discussing them…
Finally, it’s important to understand that just because it came out of your head, it doesn’t mean it’s a perfect idea. Just as you are a, most likely, a very good professional, so are your developers and everyone else working on your team. Make sure everyone understands that criticizing the status quo is permitted.
Heck, it should even be encouraged. After all, the only way you and your team can grow is by moving with the times. What worked five years ago doesn’t have to work today. But if you can’t see it, you need to have an open mind to be told so by someone on your team. Someone suffering from your inability to understand that something can — and should — be improved.
It might be something as silly as automating a CI/CD process, or something as controversial as having a better remote work policy. It doesn’t always have to be about tech. If you’re a manager, you’re probably in charge of other aspects of your teams.
Remember, you’re there to make their day easier, not harder.
Do you have any other recommendations for new (and old) managers? Leave a comment below and let’s discuss them!