It’s Time to Be the Bad Guy
An Engineering Manager’s Guide to Taking Ownership by Taking Heat
Introduction
At my first project management job, I was given the nickname “Mad Dog”.*
Any time new sales reps would join the company, the existing reps would try to scare them by telling them “Oh shit, you’re on Mad Dog’s project”.
The joke, of course, is that I’m a big ol’ ray of sunshine: After a few days of being scared to encounter Mad Dog, those reps would meet me and realise they weren’t going to have a problem with some hard-ass micromanager.
The same is still true today, but I’ve also come to realise that there are some benefits to being Mad Dog. Sometimes, the best way to help your team is to lean into being the bad guy.
In this post, I’ll cover some situations where it’s good to be bad, and why being the bad guy is a core management skill.
* The nickname came about due to my name’s similarity to a famous football player (Adam “Mad Dog” MacDougall). Say “Anna McDougall” and “Adam MacDougall” ten times and you’ll hear it.
Leadership means stepping out of the team
As you move up the engineering leadership chain, from EM to Director to VP to CTO, you become less and less a part of the development teams. This sense of social isolation often drives leaders to try their best to be buddy-buddy with developers, to attempt to completely eradicate any sense of hierarchy, and to improve psychological safety.
In general, this is a great idea.
As a leader, you do need people to know that you’re just human. You should have people trust you with their real thoughts. You must enable a culture where failure and feedback are freely given and learned from.
But…
You are also the one who has to take the heat from above, and sometimes you have to be the bad guy to the team when it comes to responsibilities and work expectations.
By moving from engineer to team lead or engineering manager, you move from taking and executing tickets to a far more world where you have to balance the needs of the engineers, stakeholders, product and the business.
You have to deliver hard feedback, push the team on goals they may resist, and sometimes say no when it would be easier to say yes or be vague.
By far one of the biggest struggles I’ve seen new managers deal with, is not being able to separate themselves from the team. Although you should create a level of safety and friendliness that enables free exchange of ideas, you also have a different job to execute. You are not an engineer any more, and your priorities need to shift with that changed role.
To give new managers an idea of how this looks, here are some sentences I’ve had to say in my leadership roles over the past 5 years:
- “I know that’s what you want, but it’s not going to happen.”
- “In the end, that’s the job. I know it’s not fun, but it’s what the business needs right now.”
- “Like it or not, that’s the impression you’ve given them”
- “If I had a task like that to give you, I would. But it just won’t be an option for at least a few months.”
- “If that’s the direction you want your career to take, it won’t happen here at this company.”
Don’t provide false hope
All of the above example sentences are similar in that they acknowledge what the developer thinks/wants/believes, but gives them a quick and crisp answer that is clear. This directness is a blessing.
Most disappointment, resentment, and frustration comes about when expectation doesn’t match reality.
If you know a certain goal, opinion, or option is just not going to happen, you should never try to cushion it in terms of “maybe” or “let’s see”, because people will pin their hopes on that. Being clear that you don’t expect it, or you can’t offer it, helps people to understand where they’re at.
Similarly, if a developer is complaining about their work expectations/tasks, you can absolutely empathise, but at the end of the day: that’s their job. They can complain all they want, but at some point they need to buckle down and do it.
As a very optimistic, smiley person, it has been crucial for me to learn to not always make people feel good.
Sometimes, the work just sucks: be it because of some uninspiring feature, a nasty bug, a lot of testing/documentation work, or colleagues you just don’t click with. None of that changes the fact that the work needs to get done, and it’s my job to make sure it does.
Empathise, but don’t make promises to change something that is a reality of the job. What you’ll often find is that, over time, by being the bad guy and being upfront about these things, you are actually building trust.
It feels bad in the moment, especially if you’re used to being part of the team or being eternally optimistic, but what it does is show the developers that you’re serious, direct, and will tell them the truth. You won’t just say nice things to be nice, or give them false hope when it’s not going to happen: they can take you at your word.
Then, when good stuff is on the horizon, compliments roll in, or you say something is possible, there will be a lot more excitement and buy-in.
Actively taking the blame
For those of you already feeling sad that you can’t just be part of the team and enjoy the experience, I have some good news for you… Being unafraid of the “bad guy” title can also give you options to help the engineers.
Here, it’s about being ready to take ownership of the team, their priorities, and your decisions.
Let me again provide some examples:
- “You shouldn’t be spending your time on that, and if Sarah has a problem with it he can come to me.”
- “No no, don’t let them rope you into that. Do it the way you want to, and then just tell them it’s me being a hard-ass and making you do it.”
- “Our priority right now has to be Initiative X. If anyone tries to get you to work on anything else, you tell them it’s out of your hands and just blame me.”
You are the one expected to stand between the team and the pressure coming from outside. When stakeholders are upset or deadlines are tight, you are and should be the one taking the heat.
This process should not be accidental, but purposeful. You know the engineers are going to get pushback on something, so you prepare for it by giving them an out.
At this point, “Just blame me” should basically be printed on my tombstone.
When you say, “Tell them I am making you do it this way,” you give them cover. You protect them from cross-team or cross-company conflict and let them focus on their work. You allow them to treat you as the hard-ass so they can keep their heads down.
This is part of being a shield for the team and is a valuable part of building trust and accountability in your role. In the end, you need to own your decisions, and doing so in this very public, social way is beneficial both to your engineers (they don’t need to come up with their own justifications) and to you (you get to show that you back your own decisions).
Why this helps the team
Being the bad guy does not erode trust. It builds it.
The team knows you are willing to carry the weight and make hard calls. They can trust you to tell them the truth and to look out for the bigger picture so they can focus on their work.
By giving them truth directly, even when it’s hard to hear, you let them know that your positive moments aren’t false or designed to mislead or please them.
By being the shield and actively taking the heat from any pushback, you are showing the team that you are willing to defend them and to put your own reputation on the line for the decisions you make and for what the team delivers.
So, dear manager, it’s time…
It’s time to be the bad guy.
