Engineering management lessons

http://www.defmacro.org/2014/10/03/engman.html

by coffeemug • 12 years ago

375 51 12 years ago

coffeemug2• 12 years ago

Author here.

These are the most important things I learned about engineering management after five years of doing it. There are lots of subtleties between the lines, so let me know if anything feels vague and I'll try to clarify it.

bcbrown2• 12 years ago

[Don't] Personally fix bugs and ship features. You have to write code to remain an effective tiebreaker, but that’s where your coding responsibilities end.

How do you write code without fixing bugs and shipping features? What do you mean by tiebreaker?

coffeemug2• 12 years ago

How do you write code without fixing bugs and shipping features?

What I meant here is that you have to fix an occasional bug and ship an occasional feature, but only in order to remain an effective tiebreaker. Fixing things is no longer your primary job. During crunch time new managers often feel that the best way to help the team is to dig in and fix things themselves, but in reality they can help much more effectively by doing other things.

So fix an occasional bug, but remember, you're only doing it to stay in tune with the codebase, not to ship things faster.

What do you mean by tiebreaker?

I'm talking about making decisions when half the team thinks "we should do X" and the other half thinks "we should do Y". If the team can't reach consensus someone has to decide, and as a manager, that's you.

NewHermes• 12 years ago

My only advice would be to try to be more effective with your points. While you seem to have a lot of knowledge, giving the reader so much at once makes it feels like nothing is important.

I would remove a lot of the redundant or obvious points and try to consolidate others. I like the idea I just think asking someone to read 44 points and remember any significant portion is too much.

I enjoyed the article, I just don't know how much I would remember if asked about it tommorow. I imagine it would be a very valuable tool for newly hired managers inside and outside of engineering though.

thoughtpalette• 12 years ago

I love this one, #19

"If you find yourself blaming someone, you’re probably wrong. Nobody wakes up and tries to do a bad job. 95% of the time you can resolve your feelings by just talking to people."

That could just be a general statement that would do wonders for people to think about.

hawkice• 12 years ago

I am extremely concerned with:

[Don't] Personally fix bugs and ship features.

So, obvious but mostly irrelevant concerns: Team size. If there is only one person you manage, this is likely a mistake. You don't clarify when this rule kicks in, but I assume we don't actually disagree on that point.

I am also concerned that you seem to place no emphasis on engineering excellence in those who manage engineers. I've yet to see a single example of this working out well, but it could just be that you didn't mention this and the stuff you did mention paints a picture not representative of your beliefs.

My primary concern isn't with making up 40 hours of management for one person, nor non-engineering managers.

My concern is that I've seen excellent engineers promoted past the threshold where they're writing features like everyone else. And their responsibility to manage started trumping the professional necessity to push back on things "the management team" would give them. In one example that sticks out, he started bending rules, making them up, and breaking them anyway. I've seen well meaning people turn a blind eye to criminal fraud and people stealing from the company.

You can't be an effective leader if people don't see you as part of the tribe. CTOs are often considered part of the management team, and not part of the technical team. I cannot imagine how this makes them better at their jobs -- but if they are in-group for the management team, I understand how it makes them seem like they are better at their jobs.

seanflyon• 12 years ago

I you are a manager that codes and only manages one person then your title does not reflect the fact that you are actually a lead engineer and not a manager. I don't think it is a problem if your title is non-descriptive, but I would not expect all management advice to be applicable to engineers.

dirtyaura• 12 years ago

Thanks - again - your 57 startup lessons is one of the best posts about startups I've read (http://www.defmacro.org/2013/07/23/startup-lessons.html) I understood most of the points deeply only after failing in almost all of them.

Same applies here. Many seem to object to #7, but I totally agree with you. A great engineering manager is there to support the team to do their best work and the authority is not gained by writing code, but by making the hard decisions and solving people issues. Manager should only write code to be better in supporting the team by not slowly turning to a pointy-haired boss.

JoeAltmaier• 12 years ago

I'd like a more actionable list. Its good to be reminded of what the right actions are; but when and where are what distinguish great managers from ordinary. Fire somebody after two reprimands? After behavior rises to what bar? And so on.

sbarg• 12 years ago

Lots of gems here, in my opinion. This should be very helpful for anyone moving into management.

tenpoundhammer• 12 years ago

A good in-depth list that clarifies the finer points of the job. These points could fit into the more broad container of "treat people with love and respect as if they were mature adults."

solipsism2• 12 years ago

Respect, yes. Love? That's kind of silly. The trick to being professional is treating people who you do not love, or sometimes even like, with respect.

weixiyen• 12 years ago

Agree with basically everything here. The biggest surprise about engineering management is that it's less about making technical decisions and more about nurturing other people to make technical decisions. It's almost entirely people management skills that don't even specifically apply to engineering.

The other thing is the role is very rarely leadership and more service. Leaders usually blossom from within your teams naturally.

polskibus• 12 years ago

There's not much there about the management triangle - cost, schedule and scope. The hard part in management is navigating between these vertices day by day. It's great when you can take "cost" out of the equation (and often partially schedule for some time at least) because of VC funding, but the truth is that you have it much easier than most other managers.

HBR is full of similarly writted golden thoughts written by really experienced managers and leaders, however it is hard to relate to them in normal business scenario, where the customer is almost screaming at you because of deadline approaching, the sales team sold something that doesn't exist, the cashflow is close to negative (no VC).

ryoshu• 12 years ago

That's a project management triangle, related to people management, but something that good engineering managers shield their engineers from.

AndyNemmity2• 12 years ago

I agree with the vast majority, however I will focus on what I disagree with because what's interesting.

- Your team looks to you for leadership. Have the courage to say what everyone knows to be true but isn’t saying.

I don't look for management for leadership, I look at management to resolve conflicts that due to a hierarchy they are the only one given the authority to do so.

Leadership is found everywhere, and management doesn't have any more or less of this quality.

- Most intellectual arguments have strong emotional undercurrents. You’ll be dramatically more efficient once you learn to figure out what those are.

I'm not sure what you mean here. If you mean by strong emotional undercurrents, biases.. sure. That's extremely important to determining how rational a decision is.

I don't think it's particularly emotional though.

- Once everyone is heard, summarize all points of view so clearly that people say “Thanks, I wish I’d thought of putting it that way.” List any points of agreement with each view, and state what you’ve learned from everyone. Then make your decision.

I don't think this is because, "I wish I'd thought of putting it that way", and more to validate that you understand the issues and arguments. If everyone can agree that you've at least stated the situation properly, we have a foundation on which to make a decision.

-When disagreement gets personal or people don’t accept well-reasoned decisions, it turns into conflict.

Is that a lesson? When things are conflicts, they turn into conflicts.

-If the conflict persists after you’ve gone to reasonable lengths to hear everyone out and fix problems, it’s time for a difficult conversation.

What are you implying? Firing someone? What is this difficult conversation you're talking about?

.... There's a difficult conversation section after this... I'm getting the impression you mean, dealing with a conflict and telling them to suck it up. Okay.

- Occasionally someone will push too far. When they do, you have to show a rough edge or you’ll lose authority with your team.

I don't need shown a rough edge. You have authority because the company gives it, that's all that's required. Perhaps these are just the types of people I don't deal with, and thus don't have this experience.

...

By majority a lot of solid advice and thoughts. In there are some odd phrasings and issues. Perhaps many people take value in this stuff, it's quite possible as a person I don't feel the need for much of it because I'm not the type that requires it.

solipsism2• 12 years ago

it's quite possible as a person I don't feel the need for much of it because I'm not the type that requires it.

By that you mean... you're not a manager of engineers?

AndyNemmity2• 12 years ago

No, I am.

lifeisstillgood2• 12 years ago

Leadership is found everywhere, and management doesn't have any more or less of this quality.

Yes but "saying what no one dares to" needs a pre-requisite of having sufficient authority that no one can fire you for pointing out the emperor has no clothes.

If a manager can say out loud what no one else will, I bet you they all whisper it in the kitchen.

bluesnowmonkey• 12 years ago

I don't need shown a rough edge.

Well, most people do. They're biological organisms and all full of emotions and quirks. For instance, did you know that if you laugh at people's jokes, they tend to be more open to your ideas? True story. Does that make any sense at all? No.

In the same way, leadership isn't just about your position on an organizational chart. Sometimes you need to be stern when someone is out of line. You need to be assertive with your ideas, not just express them and expect people to understand their merit. It gets complicated.

It's not enough to be technically right or "in charge." You have to recognize that we're a bunch of apes building computer software. It's been an evolutionary blink of an eye since our intelligence and social structures became sufficient to farm and live in large groups. We're pack animals.

If you could summarize good engineering management in a sentence, I think it would be, "Treat people like people." The engineering part doesn't even factor into it until you've got everyone acting like decent human beings.

calibraxis• 12 years ago

Good points!

As a manager, I absolutely hate: "Your team looks to you for leadership." The disturbing thing is, mine kinda does. :) I hope it's because they're untrained in the arts of conflict resolution and "Imagine yourself as more than 1 person". Society relentlessly drills people as hyper-individualized followers. (If it's not just training, may god have mercy on their souls...)

Instead of "emotional", better terms might be societal and psychological? For example, part of my training in the male gender is obnoxious use of abstractions unsupported by the particular situation. When people do this, my thoughts turn savage. (Naturally, I try not to do it except when preceded by, "Don't know if it applies, but please let's consider...")

Breaking ties & whatnot reinforces your position as boss. This can contradict goals like promoting others as leaders. (Say, in proportion to their disempowerment in society. Because overall they need to be more observant than the more aristocratic types on top.)

On firing, is it so hard to help them find a job elsewhere?

On rough edges... the more assholish your team, the more rough edges you'll need to show. But ideally, one should escalate from more discreet routes.

bcantrill• 12 years ago

I had the same reaction to this as many others have, in that I think much of this stuff is good/fine, but the advice that engineering leadership shouldn't actually directly contribute in a technical fashion is wrongheaded. I have elaborated on this in the past[1], but in particular, I don't think it's reasonable to expect to be the "tie breaker" in what is (tautologically) a sharp divide on an engineering team when you no longer contribute: as a non-contributor, you will be relying on what people are telling you instead of your own engineering judgement.

But my objection to the advice that management should not contribute technically is actually deeper than technical conflict resolution. Software is so hard that it becomes like child birth in that we have an overwhelming bias to forget the pain: the second you stop writing software, you start rewriting your own history. So as far as you can remember, it was all pretty straightforward, you always hit your deadlines, etc. And with this, you have started down the primrose path in which you just can't understand why this is taking so long and can't you guys just get all of the bugs fixed?! I (like many -- if not most -- software engineers) have seen this first hand: one of the most technical people I've ever worked with ventured into management, stopped writing software entirely, and -- with astonishingly short latency -- forgot over a decade of experience of pain. He forgot the inifinite complexity of software, and instead assumed that bugs were due to a lack of urgency, laziness, or worse. At one point, we were getting crushed by a very nasty issue, and he called a meeting to spend an hour telling us how important it was (oh, thanks!) and that he "didn't want to hear details; just get it fixed". If he had only asked "what I can do to help?", I was ready with: "You are -- or at least were -- a damned good engineer; you can help us debug it."

This brings me to a slightly broader point: as technical leadership, I believe that direct contribution is essential, but you do need to be very careful about how you contribute. The last thing you want is to be on the critical path of some feature and have the team blocked because you've been called into a board meeting (or a customer visit or an off-site or a planning meeting or any of the other of zillions of ways in which organizational leadership must spend some portion of their time). For me personally, the answer this is particularly easy because it dovetails with what I love to do anyway: my way of directly contributing to my team is to debug. By picking up bugs that no one else is looking at, you're out of the critical path, but you are helping the team, staying technically current, and reminding yourself -- constantly! -- of the brutal complexity of software engineering.

[1] http://www.slideshare.net/bcantrill/surge2013 video: http://www.youtube.com/watch?v=bGkVM1B5NuI

lifeisstillgood2• 12 years ago

I liken software literacy to "real" literacy - and see enormous parallels with software organisations and newspapers. Even once in management, the managing editor still was expected to read the more important articles, and if they were not good enough reject them. And if he was to write the leader, it still had to meet the deadline like everyone else.

So I agree with never stop writing software - but it is also important that management learns to "let go". The article will never read as well as the one you imagined Ou would write. And somewhere there is a difficult balance between code that is not to your taste but still good enough and code that is not to your taste and not good enough.

I still have not worked that one out.

snowwrestler• 12 years ago

Unless the proponents of competing ideas are actually lying to management[1], there should be distinguishing characteristics that allow a reasonably savvy manager to make a decision. One does not need to check code into the repo regularly to understand the conceptual differences between two different architectures.

In the case where there is not enough data to make a reliable decision, the proper management move is to instruct both teams to collect more data, through load testing, user research, beta trials, etc. A well-known example of this was the early iPhone software development, in which one team built off the iPod OS and another off the Mac OS, until the best way forward became clear.

If the disagreement is not likely to be decidable with data, then it's probably a matter of opinion anyway, and a quick decision that sticks is better than agonizing.

[1] If you think your staff is lying to you, there are bigger problems than technical competence.

tjradcliffe• 12 years ago

Managers should be able to build and run the application (assuming its an application) and fix minor bugs, including going through review and check-in. The size of the technical issues they should touch with their own hands scales at least linearly with the size of the team. On a small team there is no problem with the manager being deep in the code. On a team with more than five people the size of things they should be dealing with starts to drop pretty precipitously, and by the time they are up to 15 or 20 people they should be doing not much more than the odd cosmetic tweak.

The reason for this is that life is a personnel problem, and as the team gets larger than 5 you just don't have that much room in your brain to accommodate the different modes of thinking required for dealing with people and code (or maybe you do: I don't, but my brain is particularly small, or so I've been told.)

With regard to the manager you described: they are simply a bad manager. Good managers are always working to facilitate their team's progress. Doing things like calling a meeting to harass over-worked people into working harder is bad management, and no amount of technical hands-on will change that. So my prediction is getting a person like that into the code won't help.

Jormundir2• 12 years ago

Based on my current experience, I would avoid joining a team that had a manager partaking in programming / devops.

All different types of managers can be good or bad, my personal experience has just been that managers who dive into technical tasks, even just bug fixing and devopsy stuff, tend to neglect their managerial responsibilities just enough to be a chronic frustration to everyone below them.

Having only been in the industry a few years, it's also extremely frustration when a manager does not delegate responsibilities you're interested in taking on. So my view now is that if you're a manager taking on technical tasks, you're denying your employees opportunities to grow professionally. It certainly depends on mood at the time, but in a negative cycle, this can feel like a vote of no confidence from your manager.

sbilstein• 12 years ago

My best experience with a manager so far has been one that generally delegated all technical tasks but was available to solve them should the need arise. It's 9am and no one else is around to help a blocked QA fix a broken build? It can be 'fixed' or at least reverted in a sane way. Or (esp. with a large company) some other team's service/lib is behaving unpredictably, get the right people in the chat/room/phone to make sure an engineer can get things working.

Managers should empower teams to do their best work, not get in the way or do their work for them.

TheMagicHorsey2• 12 years ago

I think there are different kinds of engineering managers and different kinds of teams. I think it might be realistic in a large organization, like Google or Facebook, for an engineering manager to not write code. There is enough political busy work every day in those organizations to keep you occupied with non-engineering tasks.

Working on small teams, in start ups, with just 3 to 4 other engineers, I found it was more productive for me to tackle at least one or two small technical problems with each release. For one thing, it helped me to understand what kinds of shortcomings there were with our tools--and whether we needed to invest more in them to improve productivity. Also, because I was immersed in the code, it was hard for people to bullshit me about what they were doing, and how long it was taking.

There is an attitude in Silicon Valley that everyone is always working for the good of the organization, or has the intention of doing so. I think you can be fortunate and put such a team together. But sometimes you get someone who has either lost the motivation to contribute, or has never had it. You can try to help such a person get another position, so you can hire a replacement, but sometimes you need to get through a release before that can happen.

In such a situation, being able to have an honest conversation, where they know they can't bullshit you about technical stuff, is important.

freshflowers• 12 years ago

Has nothing to do with the size of organization, but the nature of the context. A small org can have a lot of clients, stakeholders, external partners or other communication overhead between the team and the rest of the world.

TheMagicHorsey2• 12 years ago

That is true.

napoleond• 12 years ago

Most intellectual arguments have strong emotional undercurrents. You’ll be dramatically more efficient once you learn to figure out what those are.

What does this mean?

courtf• 12 years ago

Not the author, but taking a stab at your question: I think it means that regardless of how logically unassailable you believe your position to be in an argument, that position is heavily influenced by your emotions (whether you realize it or not).

This is I think a very good piece of advice to consider carefully. It is common with engineers I've worked with to see people cringe when emotions are brought up. Surely, the ideal state for an engineer is to be devoid of strong emotion while assessing information and writing code? I'm sure we'd all like to believe in the consistency of our own performance and our ability to remain rational despite varying circumstances.

The truth is that without the powerful emotional signals in your brain, you would be mentally crippled in practically all decision making tasks. There's a good deal of science on this. A single paper can be found here: http://www.ncbi.nlm.nih.gov/pubmed/15134841

If you can key in to the emotional state of team members, you may be able to navigate arguments by understanding/anticipating their angles and communicating in a way that is more likely to be heard/well-received.

drblast• 12 years ago

I think the don't section is far too specific and short. I also think you can learn a lot more from failure than success, but I might be biased there. My management experience is in large bureaucracies.

Here are my top ways to fail as a technical manager:

1. You don't understand what the people who work for you do well enough to know good work from bad work. This has all sorts of bad ramifications. You can't be a leader if you don't understand what's going on. Does that mean you should be able to write code? Maybe. . .it depends on the job. It does mean that "Don't write code" is not universally good advice.

2. People don't trust you. This might not be because of anything you've done but things you've failed to do, like chat with people regularly and give them bad news quickly.

3. You don't manage the careers of subordinates so that they feel like you're helping them succeed. This is particularly important for the typical engineering personality type that finds "selling yourself" repulsive. Don't have enough data to "sell" a subordinate at review time? See #1.

4. You don't set a goal or direction. Details are the engineers' job. You have to know about the details and understand them, but your job is to give a clear overall direction and goal and help the team stick to it, and change it when necessary. If you've hired good people who want to accomplish something, they'll do that. Just make it clear what that is.

5. You forget that your success might occur in spite of you. Especially as a middle manager, you're like an insurance company; if there's anyone on your team that causes that team to be a success, you look like a success. A mostly dysfunctional team (or a completely dysfunctional manager) may still succeed. Understand that great people risk a lot more working for you than you risk having them work for you. If you're successful, you should live in fear that you're doing everything wrong and constantly check yourself. You also need to hide this fear from everyone.

6. You don't live to serve. Your goal every day should be to give your people the tools they need to succeed.

ritchiea• 12 years ago

What does managing careers of subordinates mean? Sorry to ask a basic question but most of my experience is at startups that barely have structure to the team. What specifically should managers be doing to support their team members's careers?

chris_mahan• 12 years ago

Teach them, mentor them, introduce them to people, give them exciting, challenging projects (for that person)...

quanticle• 12 years ago

It means telling me what I need to do to get to the next level on my career path.

Step 1 is asking what your subordinate's next position will be. Are the looking to stay technical? Are they looking to transition to a more managerial role? Do they not know? If they don't know or are uncertain, take a step back and ask them about what they enjoy doing, present them with options and then let them decide what their goal state is.

Step 2 is figuring out what you and they need to do in order to move to that goal.

Also, like the original article states, a lot of engineers are really bad at selling themselves. They won't ask for a promotion. They won't ask, "Okay, what am I missing that's preventing me from getting an acknowledgement for my skills and experience." If they're anything like me, they'll just look around after a while and jump ship when they find a position somewhere else that does give them what they want.

Finally, I should note that I am not a manager, nor do I have any desire to be one. But I've dealt with a fair number of managers, and the ones I've been most comfortable with have been the ones who've been direct about asking me (after 4-6 months) where I want to go in the organization. The worst feeling is going to one-on-ones week after week, and just rehashing the same points you go over in your daily stand-ups. Weekly one-on-ones should be about the developer and the manager figuring out where the developer wants to go in the organization and what needs to be done to get them there.

bcbrown2• 12 years ago

The very first meeting I had with the best manager I've ever had, he asked me what my career goals were. After working for him for a while and demonstrating my interest in a certain sub-field, he got me an invitation onto a new team focusing on that sub-field.

Know what your people want, and put them in a place where they have the chance to achieve it. That's what I want out of a manager.

seivan• 12 years ago

More people need to read Yishan Wongs articles about this. Mostly because I want more work places with his methods :(

http://algeri-wong.com/yishan/engineering-management.html

sheepmullet• 12 years ago

People management, product management, project management, strategic management, and technical management (i.e. tech lead) are all separate roles with their own best practices.

These roles are often conflicting which makes management advice articles difficult to follow.

For example "[Dont] Personally fix bugs and ship features." is great advice for the Product Manager, the People Manager, and the Project Manager, but horrible advice for the Technical Manager.

A good technical manager needs to be right in the thick of it and the longer they go without touching the code the worse they become. Trying to be a tie breaker on a technical issue when you aren't qualified to make the call will quickly result in the team losing faith in you.

kuni-toko-tachi• 12 years ago

I approach managing software teams the way a coach approaches winning games. Top down leadership is not edicts from the top, it's about creating the conditions from the top using the resources available (time, team, etc) that lead to bottom up enpowerment and action.

IMO, any "manager" who asks the question "what are you working on today?" has no business being in the role. This type of clipboard task master nonsense is the hallmark of someone who doesn't have the emotional, intellectual, and leadership chops for the job. You job as the manager is to _know_ what people are working on, not to ask. A true manager doesn't ask "what are you working on?", they ask "how are you getting along?". Daily status reports and "what are you working on" create natural resentment and skepticism and rightfully so.

mathattack• 12 years ago

I don't think there is a universal answer here on "Should managers code?" (Disclosure - I'm in an organization that does expect them to code)

One general observation that seems to be missed here though... If you do choose to have engineering managers code, you have to be careful about a few things:

- That the managers don't confuse positional authority ("Do it because I'm the boss") with intellectual authority ("Do it because I'm right")

- That the spans of control have to be smaller since the engineering manager has less time for care and feeding. In this sense, and idea that "Keeping managers hands on, and the organization flat" actually results in added hierarchy. If you have 8 employees per manager, you can have 64 engineers in 2 levels of hierarchy. If you have 4 employees per manager, you need 3 levels of hierarchy.

- Is there room for superstar developers to emerge purely as individual contributors?

None of these is to say that one model is any better or worse than the other. I think it's very situational.

andyidsinga• 12 years ago

loved this ..having done a little bit of tech lead and people management.

see also "managing humans..." by Michael Lopp ( aka Rands ) ..its basically the long form and much more entertaining version of the post :)

this is the only thing i didn't like:

Dont't
Personally fix bugs and ship features. You have to write
code to remain an effective tiebreaker, but that’s where
your coding responsibilities end

....bug fixing js a fantastic way to stay in the code, and also show that most bug fixes don't require a re-architect.

Engineering management lessons

Related Stories