On Being an Engineering Manager
nickmchardy.com
nickmchardy.com
It seems like you aren't a manager, but rather a junior director who doesn't know it yet.
13 people across 4 initiatives is too much to directly manage effectively. Find someone to lead each one, and make them team leads.
Meet twice weekly with your leads, once to plan, once to problem-solve.
Move your HR/career-oriented 1:1s to every-other-week. If any of your team leads are good with people, delegate your 1:1s.
You only need a half hour for recurring meetings.
Delegate more.
In my experience, though, I see managers and therefore companies struggling exactly because they do the opposite. They are unable to delegate, to trust and to think "he or she doesn't have the right experience to do it". Sometimes this stems from pride and arrogance - you are unable to admit that someone else can do what you are doing and you should maybe focus on something else. It can go as bad as a power play: if I grow people, eventually they want more and more.
Other times it comes simply from ignorance: I have always done it this way, and I am not sure how to move forward, because nobody in the team is ready to lead.
This is obviously untrue, they can definitely do it, and there are people I’d be happy to see in those roles, but the quality of work would suffer in the short term, and we have a ton of deadlines/projects to complete.
Which is better? Long term failure or short term hiccups?
In many places there is always something urgent and there will never be a good time to slow down. Then you end up in my first point eventually. So part of your job is to create that breathing room, push back on projects, get people trained, etc. Think long term and not just moment to moment.
edit: And if you think training people now is painful, doing so when you're actually past the breaking point will be be a lot harder and cause a lot more disruption.
I spent a lot of time training people in my previous job only for them to come back to me with basic questions about what I taught them over a year later.
What was missing was technical leadership from above: the managers didn't realize (or value) the need for the team to get familiar with the systems that they were working on, so they didn't make sure that the team learned these things well, or brought in a few more people who could guide them in addition to just me.
It’s on both of you to get at least one other person trained.
That said, it is extremely important to distinguish between a technical lead and a people manager. They require different skillsets and mentalities. It is more likely that a competent developer will make a good tech lead than a happy manager. "Promoting" a developer who doesn't actively want it is too often a mistake that the developer solves by finding a more suitable job. Don't lose sight of the fact that when you promote your best developer to manager, the only things that are guaranteed are that you've lost a good developer and gained an inexperienced manager.
This is why many tech companies have established parallel promotion tracks for tech and people management. With neither being inherently superior to the other. In fact Google's top employee, Jeff Dean, manages nobody. See https://ai.google/research/people/jeff for more on him.
Not true. He has VPs as his direct reports and thousands of indirects.
Maybe it was true at one time, even in recent years. But not now.
I am pretty sure it was true in 2010. I wonder when it changed, and why.
They may be less competent than you are at managing four people. But they may be more competent at directly managing four people than you are at directly managing 15 people...
It's almost always the CTO directly managing ~15 engineers. The CTO is always a man. He's always hiring a manager only because he doesn't have time for the 1:1s anymore. He never believes in hierarchies. The engineering team is flat, he tells me. They don't need teams, no siree. He's only interviewing me, he assures, because 1:1s aren't a good use of his time anymore.
Don't worry, he assures me, he'll still take care of all the architectural decisions. And he might even manage half of the team still, he hasn't decided.
That's usually about the time I nope right out of the interview.
In my experience, the desire to "delegate" 1:1s typically signals that team is raising truthful (and deeply troubling) problems, which the executive does not want to think about. Rather than think, they rationalize: claiming that consistently and privately listening to their subordinates is "not a good use of my time", "drama-filled", "not relevant to the tech", "isn't that what HR is for?" or some easy excuse. Whatever helps them coast until they jump ship next year.
Good on you for avoiding that mess, and for not playing along with their softheaded pretense.
The traditional path to leadership roles generally involve a stepped process from a role that's fully an individual contributor to one that has virtually no IC component. It's progressive enough that by the time you've stepped up to another level of management you've already grown accustomed to what you needed to let go of and what you needed to shift focus to, while having someone above you to essentially provide integration and regression testing as you acclimate to your new role.
A CTO-by-default skips that and goes from IC to "executive level authority and autonomy". They're not only managing people all of a sudden, but architecting teams and org structures. With little or no prior experience to lean on.
So they nope out of it - avoid org structure planning (and ensuing uncomfortable decisions) by keeping it all flat, bring in a people manager as a short term solution to the problem they created with keeping up with everyone, while also avoiding some of the messier side of people management. And seek comfort in the familiar work of system architecture and (maybe) keep directly managing the parts of the team that are the most capable of self-management and aren't as uncomfortable to manage.
Still a mess to be avoided, just as you said. But a mess that's rooted more in inexperience and discomfort than in arrogance and hubris.
Of course, differing degrees of stratification are still possible. The "Spotify model" decouples team leadership and cuts down a bit on stratification by distributing authority. But even then the model is not at all flat when you zoom out. And the smaller degree of stratification comes at the cost of incurring extra overhead resolving decisions amongst multiple stakeholders who have all been empowered over certain limited aspects of different teams/projects/services.
The only thing I would push back on is the 1:1s - evidence shows it's most effective to meet weekly[1]. Delegate the 1:1s to your team leads (effectively making them the real EMs) and then have your problem-solving meetings become your 1:1s. Now you're managing managers, which is what makes you a director in the traditional sense.
[1] https://www.manager-tools.com/2019/01/manager-tools-data-one...
Of course in both tracks, it's no longer only about your own contributions and impact to the team, but that your contributions and impact now translate to everyone else you work with so that they're able to improve their own contributions and impact. Or in another way, is what you're doing helping everyone else do better?! So even though that sounds straight forward, showing that at performance review time can actually be really challenging if you're in a tech role vs. a people management role.
I've heard the complaint that some of us shouldn't be EMs, but I'm a firm believer that if it's something you enjoy, you can absolutely learn how to be a great EM. I would only consider sticking with the tech track if you enjoy the tech work more.
That's a really important point. In theory my company has a technical track but it's freakishly difficult to move up on it. On the other hand I see a lot of mediocre managers moving up higher on the pay scale all the time.
Very few companies hire engineers above 40. It’s the unfortunate reality of our industry.
Meanwhile, hanging back, chilling, reacting, and taking credit for the work of others tends to not get it done on the technical track and even doing great work doesn't mean much without you or someone else doing a bunch of selling for it.
The worst manager I've had probably thought they were a great manager - but that was someone who shouldn't be one.
Really looking for help here how to implement such path.
Upsides:
+ Your reports will treat you with respect
+ You will get more opportunities to travel
+ You will likely get much more visibility in the organization
+ You will get the opportunity to engage in team building activities and have fun
+ You can set the standards and direction of the group
Downsides:
- You will have to learn the art of politics to deal with your peers
- You need to be much more cautious about your communication and actions
- You have a target on your back and so you need to learn how to block
- You will likely have to spend more money on corporate travel & activities than your used to
- You have to have the maturity to deal with 'wasteful' activities that are part of management
One of the biggest problems with people being asked to be a manager is whether or not the organization is asking for a real "manager" or a "leader". This is a particular problem with technical staff being promoted to management.
Managers by definition are there to set everyone straight. Define the rules. Make the process repeatable. Make sure no one is out of line.
However, many companies are not really seeking this from technical staff. What they really want are "leaders". If people are asking you as a manager to set the technical direction or lead and train the engineers or give presentations at conferences, they're not asking for a traditional "manager". Ultimately, if you seek to be a traditional manager (in this type of environment) you're doomed to fail.
Great people managers are really a type of coach. They give pep talks, they throw events, they motivate, recruit the best talent, etc. Think of your high school football coach.
In this style of management you're going to be graded on retention, motivation, drive, energy, etc. etc. If this isn't you, you better think twice about moving from engineering.
If this organization is really looking for an Architect or Principal Engineer that will dive the direction and strategy for their technology, they let them know that.
https://www.amazon.com/Managers-Path-Leaders-Navigating-Grow...
https://www.amazon.com/Becoming-Technical-Leader-Problem-Sol...
https://www.amazon.com/Managers-Become-Leaders-Michael-Watki...
One of the challenges though in management is understanding what the business wants from you. Once you understand that you can be effective (and pick the right books to read)
On your downside list you need to clarify that being treated with respect isn’t the same thing as being respected.
That being said, is can be satisfying for people to recognize you as 'the boss' when you're around.
One day, a senior programmer told me he'd been a manager for a while. I was surprised-- I figured it was a step down to go back to coding. I asked him why he went back to programming.
His reply: "When you are a programmer, you have a boss above you that gives you tasks. When you are a manager, there is a boss above you and several people below you that bring you tasks. They nip at you from the top, and they nip at you from the bottom."
It made sense to me.
How much should I tell my team about what's going on above me? If my manager tells me about a customer meeting where they request a demo with certain broad requirements by a certain deadline. Should I go into the details of the overall business goal of the client and the exact deadline for the final demo? Or should I just delegate specific subtasks and keep the information structure within my team somewhat modular/encapsualted?
Any system of information sharing that requires me to remember what and with whom I shared specific bits of compartmentalized information is ultimately doomed to fail. You'll forget who knows what and eventually screw up and then you look like a manipulative middle-manager for withholding information.
Unless there's a clear reason not to share (layoffs, acquisitions, etc.), I share.
And who is gonna challenge a manager and say that it's his job to prevent misunderstandings by sharing information?
The blame game is a great asset when you need to hide incompetence and you are afraid of judgement.
If you thrive in such an environment, more power to you.
I've always erred on the side of over sharing emphasizing the link the work the team is being asked to do with the business goals/company objectives.
My internal metric was to always ensure that my leaders and direct reports all heard company news from me, before they heard it from the rumor mill.
I think everything you reasonable can. It will allow your developers to decide how to spend their time most effectively. Ex. You tell a developer to build out a certain demo screen. Even given the same specs there is a huge difference between "this screen will be shown to the other companies CEO and could be the cornerstone of a multi-million dollar deal" and "yeah we promised to deliver this screen in the deml, but now we dont think it's important. We're pretty much only building it because we promised.".
Not to mention there is going to be lots of new information that your subordinate will learn over the course of solving a problem. And if he knows everything you know he'll know what information is new and which you already knew.
But if he doesn't know what you know or assume it can lead to all types of messes. "I thought you knew this was going to be a 3 week change, and would break backwards compatibility"
My advice would be:
- if the information is providing context on current work, or information that will affect the teams tasks/deadlines/etc. share it as soon as you can
- if the information is of the "might happen in the future" variety don't share it until it's concrete. Vague concerns that aren't actionable don't help anyone, and will stress some people out.
- it's trickier with things that are less clear cut (e.g. this other team/division is having a real problem but nobody knows what to do about it yet.). In this case I would lean toward sharing the positive things and holding on the negative ones while they are still uncertain.
- it's also very dependent on the person. Some people want to know a lot more details to be comfortable than others. One size fits all probably won't work that well. Does the team feel comfortable about approaching you for more detail?
Finally a question - how are you "managing up" for this team? To use your example, if your manager tells you about a customer meeting with a deliverable and date that will involve your team, how are you making sure the team has meaningful input on scoping that deliverable?
There’s absolutely people that won’t give a flying fuck and just continue working as they always have, but you’ll also find people that take some initiative based on the information you have provided them.
If you set a clear context for the team they will be best able to deliver the results you want. I’d go so far to say they can’t deliver the results you want without clear context.
You may have recently been a successful individual contributor at your company. So it may seem like you know more than your employees about how to do the work. But even in this scenario you need to let go and realize your job is completely different now. You have had a tech lobotomy and are now a manger. A different species with no expectations of expertise.
The information you should share is strategic direction, priorities, and background information about things that might affect the team. Then you connect your team members to the people they need access to do their jobs; if you're trying to act as a go-between you're just adding latency and noise to the process.
In your example your team member needs to know how important the project relative to their other work, what your expectations are around timing or effort, and then to be connected to a stakeholder who can fill them in on the details.
If you are at a smaller company, push for them to formalize a career ladder which has parallel tracks for manager and IC roles going all the way up till C-level execs.
It kinda is though. At any reasonably level of comp you care to name there's someone playing sports making that amount of money. Nonetheless it is entirely reasonable to say that playing sports isn't a great path for career advancement. Same thing with tech IC. Sure, there's someone, somewhere making $1MM/year as an IC, but there's a heck of lot more people with reports at making that. Same thing is true at $750k and $500k.
Maybe at $300k it isn't? And yes, to be sure, that's a ton of money. But given how hard it is to advance from there, can you really expect to sit there for 20+ years? How many organizations are there around that don't have some kind (possibly unofficial) up or out rule?
They don't push out the person that wrote all that business critical COBOL spaghetti. It's not all that hard to code yourself into job security. Digging into someone else's technical debt and stewarding it along for years 13-28 of its life is easy too.
As a senior developer I am deeply introverted and I am skilled at my craft because I can go into these fugue states of deep focus blocking out everything else. I don't need to be concerned with the world outside my team, and often not so concerned with my teammates. As an individual contributor your success is largely determined by the quality and frequency of your contributions.
As a manager you need to be more concerned with what is going on outside the team than within. You are the interface and diplomat between the team and everything else. You are interfacing externally outside the team so that your team doesn't have to and so that you are the single funnel of priority and direction.
As a manager you are largely done writing code. Use your experience writing code to set the proper tone and direction when your developers hit a wall. Guide them into the proper direction for resolution and provide them with resources they likely aren't even aware of. That is you, the manager, providing a vague solution to a code problem without having to write any code.
Your coding experience allows you to set business standards (not code standards) that determines acceptable contributions and enforce those standards. Code standards tend to be highly subjective and are often completely vane or superfluous. By ensuring the standards exist outside of code, such as execution speed or statement count, the standards are likely to be objective and uniformly applied. You should automate this enforcement as much as possible and grant exceptions only with careful deliberate consideration.
Setting high standards is a defensive action against future stupidity. Even as a manager there is still much in the world you do not control. Strong leaders are proactive in shielding their team from stupidity as much as possible. Perhaps the strongest and most enduring form of stupidity defense is CYA (cover your ass). High standards of deliverables is proactive CYA.
If standards are set high members of your team will complain. It will happen. Accept it and own it. Managers without a strong development background or weak soft skills may find it easier to keep the team happy. That is bad. Remember who your team works for. They work for you, not the other way around. If you are quick to cave on product quality its like sharks smelling the blood in the water. Smart managers will spin this as the company's product is merely a tool to advance the team members personal development and competence of their craft. If after sufficient time, patience, and training are exhausted and a teammate still cannot accept the high standards transfer them off the team. Incompetence is a drag on everybody.
The most common reason why product quality slips is because either the business is setting unreasonable delivery timelines or because your team lacks confidence. The second is far more common than the former since, as the manager, you can often negotiate more realistic external delivery terms. An inexperienced team is not a reason to release shit back to the business. That is the opposite of CYA.
Fortunately your team will make this foolishness clear to you by advocating for easy. If you ever hear your team advocating solutions or alternatives because of easy or hard take a long hard pause and reevaluate what they are really saying. When they advocate for easy it might sound something like: "We should use framework X because it makes things easy and then we can deliver twice as fast!" What that really says is something like: "We are slow to make decisions and our jobs are challenging!" In that case the problem is insecurity/anxiety and the framework is a bandage over a much larger wound. Always remember the name of the game is high quality output so that you put your CYA immediately up front. The easy option your team advocates is likely to shred every ounce of CYA both now and in the future.
One way think of your place in the world, as a manager, is that the group is worth more than an individual but the product your team supports is worth more than you or your team. Your entire team can be laid off and that product will continue to live.