Hacker News new | past | comments | ask | show | jobs | submit login
On Being an Engineering Manager (nickmchardy.com)
304 points by boyter 34 days ago | hide | past | web | favorite | 76 comments



I don't know if you're looking for advice, but:

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.


As an engineering manager, this sounds like almost every startup I interview at.

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.


Superb insight about 1:1s. They are an essential team process, which the manager alone is responsible for. They can't be delegated; a manager cannot establish and maintain a direct, personal relationship through a proxy. That's just not how human beings work.

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.


It's also commonly a signal of an executive-by-default vs. an executive-by-experience.

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.


I cannot stand weekly or less than monthly 1:1s and I dispute they are an essential team process. They often waste time and I do not find them useful for my team.


Yep the second the words "flat team structure" are used as a positive I'm out!


what kind of structure do you think works best?


I'd argue that flat structures don't exist outside of tiny companies, only clearly delineated and obfuscated structures, none of which are flat after 20 people or so. So when a medium-sized or larger company says they are "flat", it means they are struggling to understand their own organization.

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.


This is how it is at my current company. Neat.


In general I support the idea of delegating more. Which is inherently scary because you're of necessity delegating tasks to people who are less competent at it than you are. And there are lessons you need to learn, such as the fact that it is dangerous to have real decisions made in a 3-level meeting (employee, manager, manager's manager) because it is too easy to accidentally undermine the manager.

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.


Jeff Dean manages a lot of people. He's currently the head of the RMI division if I remember correctly and has at least a few thousand employees under him. Sanjay on the other hand has remained an individual contributor.


> In fact Google's top employee, Jeff Dean, manages nobody.

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.


Thanks for the correction.

I am pretty sure it was true in 2010. I wonder when it changed, and why.


In 2011, when he started the Google Brain initiative.


> In general I support the idea of delegating more. Which is inherently scary because you're of necessity delegating tasks to people who are less competent at it than you are.

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...


I am just a developer and I really like your advice.

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.


Fwiw, there _are_ also times that there are no other people on the team who can do a thing.


I wonder how that can be, though. Either you are constantly surrounded by junior people, or...? I am sorry, but I can't believe that out of 10-15 people there is not a 20% of people who can do part of your job.


I can tell you, out of 10-15 people, there are none that can do my job.

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.


The problem is that at some point you'll become the bottleneck and projects will be delayed as a result. Or you'll get sick, a loved on gets sick, etc, etc. Either way productivity will suffer and things generally start to spiral downwards then (people get bored, leave the company, putting more work on you, etc.).

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.


It's easy to talk about training people.

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.


In this case he is the manager so he can do all those things you mentioned to properly train his team. It takes effort and sacrifice but that's his job.


That's the trap. If you don't let people jump in and fail just because you know you can do it better right now, they will never be good enough.


Both you and your manager have failed the rest of your team.

It’s on both of you to get at least one other person trained.


And without delegating the quality of work will suffer in the long term.

Which is better? Long term failure or short term hiccups?


Depends on whether you ask management.


Yea more likely, I think, is that management is hesitant to give people a shot. They’re probably worried they’ll ask for more money or something.


Then you should train them so they can do the thing. Having a bus factor of 1 is a bad thing even if you have room on your plate.


Aka, a “teaching moment.”


It sounds like from the blog post that the OP opted out of EM in favor of solutions architect but this is still great advice and an accurate portrayal of who this person is (i.e. a junior director not an EM).

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...


I actually think for most of us, after some point, switching to engineering manager track is often far easier to continue leveling up in. Most good companies have an equivalent tech track, but unless the stars are aligned and you're blessed with a supportive manager AND the right project that align with your talents, its going to take a much longer time progressing.

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.


"I actually think for most of us, after some point, switching to engineering manager track is often far easier to continue leveling up in. Most good companies have an equivalent tech track, but unless the stars are aligned and you're blessed with a supportive manager AND the right project that align with your talents, its going to take a much longer time progressing. "

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.


My company has a tech track but NO developers are on it. It’s basically designed so that nobody can ever qualify for it. As far as I can see it’s purely there to entice developers and then push the blame back on them when they inevitably have to turn into managers - “look, you COULD have been on the tech track if you tried harder, you made the choice to progress on the management track.”


I think one thing is that in a lot of companies there still is the belief that your pay is determined by the number of people you have under you and that a manager always has to make more than than the people they manage.


That’s usually the right economics. If you want to make money as an older person, management is the way up.

Very few companies hire engineers above 40. It’s the unfortunate reality of our industry.


Surely it’s insane economics for the company though. My management skills must be almost useless (and I’m considered an ok manager) compared to my dev skills. I can’t understand what’s in it for the company to make EVERYONE into crap managers AND pay them more AND make them unhappy AND ensure that only inexperienced juniors have time to actually do work. Just don’t get it. But every company wants to do it.


The trick in my observation seems to be that, on the manager track, it's possible to get move up by being on a successful project and simply not getting in the way, which plausibly may be what was needed ("the team had gelled and was cranking away and I felt the best way to support them was to free them to do what they needed to do"). This can be repeated pretty far up. As an aside, I'd estimate that the less a manager ends up needing to do, the more likely success ends up being on a project.

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.


There is a lot of generally invisible work of leaders. That can be hard to distinguish from "not doing anything at all" in the moment, but across a year or more, the leaders who carefully build teams, work with the engineering leads to set appropriate goals and scope for projects, make sure that critical roadblocks are removed, ensure that engineers feel engaged with the work and company goals will succeed beyond that of those are literally doing nothing. To the junior engineers in the org, it may not appear any different and one leader just seems to keep getting lucky (appearing to just be dealt a series of good teams, good projects, consistently getting good outcomes, etc).


"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."

The worst manager I've had probably thought they were a great manager - but that was someone who shouldn't be one.


How such do s such tech track is defined. I was researching such role path for our company but did not find a description e.g. what are preconditions, role name and stages, responsibilities...

Really looking for help here how to implement such path.


There are some trade offs when you go into management (from experience):

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.


> Your reports will treat you with respect

On your downside list you need to clarify that being treated with respect isn’t the same thing as being respected.


Very true. Much of the respect shown by reports is out of fear. Everyone complains about their boss behind his/her back. Now you have to suck it up and realize that this person is now you.

That being said, is can be satisfying for people to recognize you as 'the boss' when you're around.


Are there any good books or resources that comes to your mind for better understanding what you've described?


There are a number of good books on both leadership and management. Harvard Business Review has a lot of smaller books on leadership and management like this one:

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)


I have found The Manager's Path useful about this. She goes into good detail about what it means to be a manager vs a tech lead, for example.

https://www.amazon.com/Managers-Path-Leaders-Navigating-Grow...


Not sure what you mean exactly when you say "what you've described," but if it's the technical lead part, this book is phenomenal:

https://www.amazon.com/Becoming-Technical-Leader-Problem-Sol...


When I was a junior programmer (about 25 years ago), I thought it would be great to be a programming manager.

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.


I manage a team that do what could broadly be described as data science, here is one thing I feel unsure about and I'd like others' opinion on:

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?


You are hitting on one of the difficult things to balance. One of your roles is to act as an information filter in both directions - but this is more often done too conservatively rather than too liberally.

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?


I have, over the years, gravitated towards telling everyone in my teams as much as I possibly can at all times. I use top-down information sharing like your scenarios as a chance to connect my teams (which tend to be infrastructure and futher from the core business) to the business and their needs.

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.


Amen. Work without context is demoralising and can lead to micro decisions that don't align with the macro context of the business you're in.


But if you don't share context you can always blame it on the fact that there was a misunderstanding or that you had so much to do, that you couldn't blablabla.

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.


Nobody will be able to officialy blame you, but everyone will hate you privately.

If you thrive in such an environment, more power to you.


>How much should I tell my team about what's going on above me?

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"


You should work to understand all the noise and data that is being directed at the team and turn into something useful for individual team members. If you merely pass information through then you will be overloading or confusing people, because often extracting the signal from the noise is a full time job (your job!). You can't expect someone to do this effectively as well as their own role.

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.


My experience is that many people want to know you will answer any question they ask transparently transparently, but prefer less mettings, and don't need or want you to go into too much detail.

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.


From my experience the best managers are very open and tell people who want to know pretty much everything. But in general I would recommend to treat people individually. Some people just want to get their tasks and then do them whereas others are curious about the bigger picture. Most good managers have the people skills to recognize what people want and need.


IMO the manager’s job is never to subtask. That’s micromanagement.

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.


In general, more knowledge is better. They can do with the knowledge as they see fit.

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.


this is part of your personal style IMO; like sales, there is not one single answer.. work with your strengths, and incorporate that into your team. One thing to add to that is -- burnout, cognitive overload, and the "attention economy" are real.. you are playing a team position, so your part may be to reduce those things, not increase them, for others


Great read. More people need to realize that moving into a people manager role is NOT a requirement for career advancement. If you feel that is the case at your company, and you are more passionate about coding or architecture, you should really consider switching jobs. There are a ton of companies out there that will value a great IC over an average manager.

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.


> More people need to realize that moving into a people manager role is NOT a requirement for career advancement.

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?


> 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.


"I'm gonna code me a minivan."


Hopefully you won't subject your workers to scrum; it is evil. Refer to https://michaelochurch.wordpress.com/2015/06/06/why-agile-an...


I would take everything that mchurch says with a grain of salt.


Granted it's an opinion, but if you've been through as much scrum as I have, especially if you're a senior developer, you'd know it's a true article.


Grain of salt taken, but I don’t think these points are invalid.


I love reading his articles. Always good for a laugh!


It's an extremely serious article. If you think it's good for a laugh, the joke's on you.


It's not the article that is the joke.


Managing developers is weird. I have a unique perspective on this matter as I am a senior developer at one company and a managing principle at another.

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.


If you're having 1:1s each fortnight, you probably won't even need 30mins. In practice, schedule for 30mins but in reality it rarely takes that much time so don't fret about losing so much time.


Thanks for sharing :)


nice write up. Thanks!




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: