14 ms·

Engineering management lessons

375 points by coffeemug 12y ago

coffeemug 12y 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.
- bcbrown 12y 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?
  - coffeemug 12y 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.
    - nawitus 12y ago
      >During crunch time Is "crunch time" a good thing in software development? It's certainly possible to deliver software without crunch times.
      - stevewilhelm 12y ago
        While "crunch time" might not be a good thing in software development, it's essential to a growing business.
      - HeyLaughingBoy 12y ago
        No, it's a spectacularly bad thing. Unfortunately most dev cultures assume that it will always be necessary. In pretty much all cases it's a management failure.
      - prostoalex 12y ago
        But yet there's a day when you're ready to release, and therefore need to coordinate with engineers on monitoring the release and fixing last-minute bugs and dependencies, with ops on deploying the release, with marketing on writing a blog post, and with sales on communicating the features to the customers. This day could be called "crunch time" even if no external deadline is handed down.
    - judk 12y ago
      A manager's main job is to make crunch time not happen. Crunch time is management failure to plan.
- NewHermes 12y 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 12y 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.
- deleted 12y ago
  [deleted]
- hawkice 12y 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 12y 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 12y 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 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 12y 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 12y ago
Lots of gems here, in my opinion. This should be very helpful for anyone moving into management.
tenpoundhammer 12y 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."
- solipsism 12y 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 12y 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 12y 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 12y ago
  That's a project management triangle, related to people management, but something that good engineering managers shield their engineers from.
AndyNemmity 12y 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.
- solipsism 12y 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?
bcantrill 12y 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 http://www.slideshare.net/bcantrill/surge2013 video: http://www.youtube.com/watch?v=bGkVM1B5NuI http://www.youtube.com/watch?v=bGkVM1B5NuI
TheMagicHorsey 12y 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 12y 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.
  - TheMagicHorsey 12y ago
    That is true.
napoleond 12y 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 12y 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 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 12y 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 12y 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 12y ago
seivan 12y 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 http://algeri-wong.com/yishan/engineering-management.html
sheepmullet 12y 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 12y 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 12y 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 12y 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.

375 points by coffeemug 12y 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.

bcbrown 12y 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?
- coffeemug 12y 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.
  - nawitus 12y ago
    >During crunch time Is "crunch time" a good thing in software development? It's certainly possible to deliver software without crunch times.
    - stevewilhelm 12y ago
      While "crunch time" might not be a good thing in software development, it's essential to a growing business.
    - HeyLaughingBoy 12y ago
      No, it's a spectacularly bad thing. Unfortunately most dev cultures assume that it will always be necessary. In pretty much all cases it's a management failure.
    - prostoalex 12y ago
      But yet there's a day when you're ready to release, and therefore need to coordinate with engineers on monitoring the release and fixing last-minute bugs and dependencies, with ops on deploying the release, with marketing on writing a blog post, and with sales on communicating the features to the customers. This day could be called "crunch time" even if no external deadline is handed down.
  - judk 12y ago
    A manager's main job is to make crunch time not happen. Crunch time is management failure to plan.
NewHermes 12y 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 12y 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.
deleted 12y ago
[deleted]
hawkice 12y 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 12y 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 12y 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 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 12y 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 12y ago

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

tenpoundhammer 12y 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."

solipsism 12y 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 12y 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 12y 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 12y ago
That's a project management triangle, related to people management, but something that good engineering managers shield their engineers from.

AndyNemmity 12y 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.

solipsism 12y 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?

bcantrill 12y 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 http://www.slideshare.net/bcantrill/surge2013 video: http://www.youtube.com/watch?v=bGkVM1B5NuI http://www.youtube.com/watch?v=bGkVM1B5NuI

TheMagicHorsey 12y 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 12y 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.
- TheMagicHorsey 12y ago
  That is true.

napoleond 12y 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 12y 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 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 12y 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 12y 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 12y ago

seivan 12y 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 http://algeri-wong.com/yishan/engineering-management.html

sheepmullet 12y 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 12y 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 12y 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 12y 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.