12 ms·

Engineering management lessons (2014)

517 points by mzehrer 9y ago

alexchamberlain 9y ago
Strongly disagree that an engineering manager shouldn't code; that is the shortest way to lose the respect of the team. Don't get me wrong; you need not be the "best" or the expert in all areas, but you do need to stay on top of technical developments both within and outside your organisation.
- manojlds 9y ago
  Where does it tell to not code?
  - mpweiher 9y ago
    In fact: "You have to write code to remain an effective tiebreaker, but that’s where your coding responsibilities end." Just not "Personally fix bugs and ship features."
- endymi0n 9y ago
  There's an easy way to accomplish this: Commit yourself to 95% reading of code and 5% writing. Through great code reviews, spread your knowledge through the company and make others as good as you. Has the added benefit of making the stack more homogenous. (I still code review 50% of all commits relating to the data model - SQL & API interfaces myself) Then about the 5% - this is high prio, high visibility fixes where you bring in your extraordinary expertise in some domain. Believe me, that's enough to stay respected. Your time is much better spent at sparring systems architecture & high level design, hiring and building well-oiled teams and discussing the business needs with the rest of the company. Isn't as fun, Doesn't feel as good, but it helps most the long run. The alternative is a high performance coding monkey that gets a tiny area of the company right - and the rest of IT goes wild and rewrites core APIs in the latest three hype language because "we needed to get rid of technical debt". The 44 lessons of the OP are distilled gold from years of experience, I rehearse them every year and can recommend them to any aspiring tech lead.
  - watwut 9y ago
    Code reviews by a dude who codes only a little and has formal power are pure hell. It is tricky when he is wrong, he can force you to do things that cause trouble and so on and so forth - all that because writing and reviewing code are much different and he is gradually out of touch.
    - valuearb 9y ago
      Why did you code it that way? How hard is it to answer that question?
      - NortySpock 9y ago
        "It will cause performance problems if you don't" , with only a gut feeling to back it up, and no actual testing. I just ran into this response yesterday, and I ended up going over his head (unfortunately) and asked our DBAs for a recommendation. DBA solution worked faster than either of the previous two solutions. I still need to apologise for that one.
        mncharity 9y ago
        > I still need to apologise for that one. Curious. Running an idea by people to get their thoughts, because it's currently leaving you short on warm fuzzies... is something to apologize for? The initial solution was low on warm fuzzies for him. Your second solution was low on warm fuzzies for you. So you explored further. Where's the problem?
    - sanderjd 9y ago
      It sounds like you've run into some bad apples, likely due to "promoted too early" syndrome, which is unfortunately pretty common. In my experience, code review by senior engineers is extremely valuable whether or not they're currently writing much code.
      - Spooky23 9y ago
- didibus 9y ago
  I'd rather a manager who seems to care about me. Someone who is fair to the team, and shields us from the executive pressure. Someone that gives me challenging work which I could fail at, and recognises that I can fail and that it's ok if I do. Most of all, someone who dispays real appreciation for the value I add to the team. I honestly don't care if they code or not.
  - freekh 9y ago
    Second this a lot. In fact I am gonna steel exactly this and feed it back to my org
- kayoone 9y ago
  Engineering managers that also code a lot usually fall short on the managing part, at least in my experience. Imo it's better if they focus on building a great team, guiding the team in the right direction by doing code reviews and making the hard decisions and be somewhat of a shield between the devs and other internal or external stake holders. Sounds boring, but provides more value as a whole imo. It's also why i opted to not be a manager right now so that i can still code full time. This does not apply if you are a <10 people company though.
  - kochthesecond 9y ago
    I recently quit a job where I was in practice the tech lead. I did probably 60% code reviews, and made sure the architecture as a whole kept moving towards a coherent view and quality. But it was boring as I don't particularly enjoy teaching new developers basics of coding production ready systems every few months, especially when tied down as a consultant for a government organization. I ultimately had very little to say in what tech we could deploy. I therefore decided to go somewhere I might get more freedom to build quality with a bit less politics.
  - TH3R3LL1K 9y ago
    I'm currently working for a company where the our manager holds a tight grip against the code we write, but he doesn't seem to guide us in the correct direction.
- samlittlewood 9y ago
  A recipe for disaster is for a manager's code to wind up on the critical path, then become a blocker - bad code & bad management. A possibly better approach is for managers to have a few side proejcts, scouting out potential risk reducing things, at a higher temperature, away from the main project. Great if one of them lands - no added problems if not. Also, if they land in the project, they are no longer the responsibility of the manager.
- pjmlp 9y ago
  I have about 30 years coding experience, never had a manager that was still writing code after earning the position, other than a few Office macros. It was never an issue to us and they were always respected by the team, except for the few ones that never should have been managers to start with. Any manager that wants respect from the team needs to support them, specially against stupid decisions from upper layers. Have good social skills and specially important, how to raise morale in darker times. Knowing to code is irrelevant.
  - kochthesecond 9y ago
    I agree, having good social skills and being good at moving things forward (often in a political landscape) is more important than coding skills.
  - hoschicz 9y ago
    Where have you worked during your 30 years of experience? Big/small companies? What sector?
    - pjmlp 9y ago
      Education, Research (CERN), Shipping (Harbour IT), Telecommunications (CRM, Mobile Operators, OEMs), Life Sciences, Manufacturing. Mostly enterprise size companies.
- watwut 9y ago
  I had great managers who did not coded and had respect. They managed politics out of department, managed to find good trade off between autonomy and controll, made decisions where the team could not.
- tootie 9y ago
  I'm currently managing projects on tech stacks I have no experience with. It's definitely a handicap but I can still do 90% of my job pretty effectively. I just felt on my team more. One big thing I've learned is the manager should never take on big pieces of development. The other demands on your time mean that every task will take longer and you'll end up being a bottleneck.
- xborns 9y ago
  Actually I somewhat disagree with that. I think they should code to some extent, but it doesn't scale in my experience. I lean to say #7 is a good point. If the manager is required to complete the feature their "free" time is't the same as an engineer - read meetings/discussions. I manage two teams and when I first became a manager my instinct was to take tickets along with the team. Yet my other responsibilities came in play and made it harder for me to finish tickets I assigned to myself and others on the team waited. I still code review and partake in high level design and some scripts here or there etc. but not mainline code that another engineer will depend on to be completed by xyz date. The goal of a manager is to ensure the work pipeline and project trajectory are on path with the company needs while still taking time to learn new tech and skill-sets of the team. Of course most importantly protecting their time from distractions. To move from manager upwards, building a great team that trusts each other and follows and ensures the team standards is crucial. If I am required for every decision or code review, then I become the bottleneck. Empowering other people and trusting their judgement was one of the harder leanings growing from manager upward.
- ransom1538 9y ago
  Couldn't agree more. Engineering managers that have removed themselves from the ability to contribute will also lose touch with: design, build systems, architecture, qa, etc. At that point they are just a bad PM. When I was a vp eng. what helped me the most was having ONE feature that I owned. I was forced to use the build system, go through qa, fight with design. It was never something massive, or hindered other groups, but if someone on the team bitched: "this framework sucks because.." -- I was able to jump in.
- curun1r 9y ago
  It's not that you don't code...you need to code to stay relevant. It's that you shouldn't code serious production features/issues. As a manager, you're context switching constantly and it's very difficult to achieve the necessary quality. You'll never get the uninterrupted time necessary to do anything big. 5-10 min fixes are good targets for a manager, as are projects that would otherwise distract the team, like spikes on potential new technology. You should use your coding to further your overall goal of keeping your team focused and you should limit your coding so that all the major accomplishments of the team belong to the team members and not the manager.
deleted 9y ago
[deleted]
gcatalfamo 9y ago
Number 11: you are probably talking about authoritativeness and not authority
bmsleight_ 9y ago
"Don’t make decisions unless you have to. Whenever possible, allow the team to explore ideas and make decisions on its own." Spot on, a good leader does not make all the decisions. It is counter-intuitive to popular culture, but this is stop on. I would go on to say minimising your decisions, also helps to spend more time on a key decision when it is really necessary.
- samlittlewood 9y ago
  A variation on this is not swoop in and make discoveries that the team is very close to finding - let them enjoy the thrill (even if you have to nudge them a bit in the right direction).
jkovacs 9y ago
Question: It says at point 8: > Don't supervise the quality and volume of people’s work. And I agree with the argument following that sentence. On the other hand, 2 points above that it says: > Do enforce behavioral and performance standards. Fire bullies and underperformers. So how else do I recognize underperformers without taking note of quantity and quality of people's output? Surely I can't just take someone else's word for it (and by the point a peer complains about this it's probably too late already anyway?).
- pweissbrod 9y ago
  Measure timeliness with respect to estimates. Measure the transparency in which they communicate the progress and focus of their work. Measure the clarity in their design and scoping. Measure what other developers say about their work in peer reviews. Measure how well their work runs in production, how many escalations and emergency bug fixes are needed?
  - afarrell 9y ago
    > Measure timeliness with respect to estimates What if you have an employee who doesn't know how to do software estimation? Do you know of ways to teach people how to do estimates or resources/habits they can follow to learn how to estimate how long tasks will take? I ask this as someone who has only received the advice "go with your gut and triple it." There is a book by Steve McConnell on estimating larger projects but nothing out there on estimating things within a week.
    - Terretta 9y ago
      You can only estimate what's known. If the problem is in fact known, your estimate will be the time to pull in a library from GitHub. If it's not to pull in a library, you're into unknowns. Asking to estimate may work in aggregate if your 'gut' is good at assessing the amount of unknown your devs' face (e.g., 2x as much unknown work - multiply estimate by 3), but not in the specific. The specific amount of unknowns in a given task are unknown. To translate a requirement into code will take exactly as long as it takes to discover and bridge the unknowns. You can't do anything about that, other than (a) change the requirement, or (b) change how much is known by the developer.
joshuaswaney 9y ago
The emotional side of management goes so much deeper than what's covered by this list. Develop a vision and a strong sense of purpose in your engineers and they'll develop a mindset of building the future instead of maintaining the present. Foster a "we're all in this together" atmosphere and your engineers will develop a fanatical drive for success - either we all succeed or we all fail, it's not every man for himself. The deep emotional drive is also what causes startups to succeed where big companies fail, despite their massive resources.
jasode 9y ago
This is a fine list and there's nothing too controversial that people would disagree with. That said, I only counted 6 items out of 44 that's specifically "engineering" related. (5, 7, 10, 12, 14, 15) The other 38 bullet points are universal lessons that also apply to non-engineering managers such as a director of a creative team in an ad agency, or project supervisor of a construction crew, or a showrunner in charge of scriptwriters for TV episodes, etc. Empower your team and make decisions when necessary, etc.
biztos 9y ago
Having just spent a couple weeks on a pretty hard engineering problem, after having done more "architecture" stuff for quite a while, I would definitely add one thing to the Do's: * Protect your engineers' attention. As a manager you are the primary firewall between the world of distraction and the world of getting shit done. Most places these days have institutionalized some amount of distraction -- the various recurring "ceremonies" -- but anything beyond that, it's essential that the manager can protect the engineers from being distracted when they're working on hard problems. (I've been pretty lucky in this regard throughout my career, but now that part of my job is to live among the distractions it's really been driven home.) Also: > You’re the one who makes hiring and firing decisions. Everything that happens on your team is your responsibility. This is, to put it gently, not quite true in larger organizations.
- jt2190 9y ago
  > Protect your engineers' attention. Can you elaborate on "attention", and what does "protecting" it look like? (I've seen this reasoning used to keep developers out of requirements gathering, for example.)
  - FLUX-YOU 9y ago
    >I've seen this reasoning used to keep developers out of requirements gathering, for example. That can be fair reasoning if you already have difficult work to do and your customers are noisy, disorganized, or inexperienced with developing requirements (think NYC window-shopping for features on someone else's credit card).
    - drieddust 9y ago
      Correct, butttt "Customer is king." On a serious note, I have seen more projects ending into dumpster because we listened to customer too well and didn't actually infer the meaning which lies between the lines. Most managers I have encountered are just messenger pigeons. Sometimes I wonder how system still works!
  - enraged_camel 9y ago
AlexCoventry 9y ago
I read this recently and found it very insightful because whereas most software management essays seem to have an agenda of advertising the author as a great person to work with, this one seems like a pretty straightforward dump of lessons learned.
exelius 9y ago
It's pretty simple: engineers are professionals. Professionals make mistakes, but are most effective when allowed to own up to them without consequences and learn from them. In a good software team, a single developer's "big mistake" gets fixed by the whole team. I guarantee nobody on that entire team will make that same mistake; nor will they hold anything against the offending developer unless there's a pattern. But in short, empowerment is the most effective leadership style in this environment. It's not appropriate for all employees (specifically newer folks who need a bit more hand-holding at first) but for professional workers like engineers, it's really the only way to go -- especially if you have senior technical employees who have decades more experience than their manager.
tootie 9y ago
I guess it varies by company, but my job is more about managing the team's exposure to outside forces. I work with product and client teams to make sure we're delivering the right solution and we're promising something achievable. That's at least half my job.
boltzmannbrain 9y ago
+ a meta-point: Learn these through experience, not in a classroom. Having managed engineers in industry and also gone through a masters program in engineering management, 90% of what makes me a decent manager/leader/coach today can be attributed to the former.
- douche 9y ago
  The dirty secret is that 90% of all formal education is a waste of time, and is just signalling hoop-jumping.
  - mcginleyr1 9y ago
    I thought it was helpful when I was doing it the first time. I saw things it made the human capital and self assessment courses much more useful to everyone when I could ask meaningful questions. So really I see leadership masters being helpful when you're first attempting to manage not later or before.
  - loco5niner 9y ago
    Overall, my CompSci degree certainly wasn't. Some classes were though.
guilt 9y ago
Big Companies have management who cash in at the expense of young exploitable engineers. Personally I'd like to see the top management get fired.
theprop 9y ago
The single most important thing in engineering management is hiring only the best. The best have two key characteristics: strong technical skills primarily in aptitude but also in technical knowledge, and a great ego-less attitude. It's at least as important to test for ego than for technical skills. Most of our "engineering disasters" were related to lowering our bar for hiring. Some "engineering disasters", though, i should note were related to inexperienced product development - so if you're a first-time product leader, get an experienced mentor.
- jalayir 9y ago
  > lowering our bar for hiring Let me guess, Amazon?
  - elliotec 9y ago
    Why would that be your guess?
    - imajoo 9y ago
      Amazon has a thing about "bar raisers" across the organization.
      - khazhoux 9y ago
        It's very common concept.
- humanrebar 9y ago
  > The single most important thing in engineering management is hiring only the best. I agree. It's easier said than done, though. Many engineering managers aren't really involved in the code in any real way. I can't imagine running a restaurant and not inspecting the kitchen, seeing hosts greet patrons, seeing how well tables stay cleared of dirty dishes, and so on. I find that a lot of "hire the best" ends up boiling down to knowing which engineers are popular with "technical" folks and haven't obviously messed up (at least to someone who hasn't really looked at code or deployments). I'm not sure how to keep this from coming down, again, to politics and popularity.
kator 9y ago
I always say management is they easiest job because you only have four things to do, and I'm sure your team has more than that to do: 1) Provide Air Cover 2) Provide resources 3) Provide direction 4) Get the F* out of the way Don't over think it. Empower your teams, trust them. They'll make mistakes just like you do. It's not how bad you F* Up it's how well you recover. Originality in mistakes is the best I can ask for. Let's learn, progress and do better together. I've been in tech for 35 years, if you think you've seen it all, you haven't and neither have I, so let's figure it out together and get some S*t done.
- tetrep 9y ago
  I think a lot of the difficulty of management is not in the description of you duties, but rather the difficulty in finding the "right" thing to do, which is very difficult when it comes to soft skills, which almost always lack any quantitative way to measure directly, and must be inferred from secondary and indirect metrics.
- khazhoux 9y ago
  Wow, that sounds like a lazy shitty manager. Every engineering team has problems they can't deal with on their own, either because it's out of scope, it's high-level organization, or whatever. A GOOD manager spends a significant chunk of their week ACTIVELY fixing problems. Not getting-the-fuck-out-of-the-way!! They should help clear the way. They should help fill gaps in the team, plan, or execution. Talk to other teams and see if everyone's on the same page. Make sure everyone agrees on priorities. Make sure your team's work integrates with what everyone else is doing. Be aware of everything going on around you (esp with other orgs, etc) so you know how it all fits together and your team doesn't waste time. Don't just listen and nod during 1:1s and then give some off-the-cuff suggestions. Don't just "get out of the way". And you don't need nearly that much Air Cover when you're team is aligned with the rest of the company, so make sure THAT happens instead of trying to "protect" the folks that happen to report to you. If a great team's manager can't point to what they ACTIVELY DID to get the team to success, they're disposable.
  - OpenDrapery 9y ago
pacaro 9y ago
Did I miss something? I see nothing on this list that touches on mentoring or growing. I do see a line about firing underperformers. I've heard a metric that it costs between 2.5-5 time annual salary to replace someone. Sometimes an under performer is just in the wrong role, or on the wrong team; when this is the case they probably know it. Ask them!
Bahamut 9y ago
I am learning a lot about engineering management through turmoil, and I think the most important lesson for me is to avoid doing too much. There are many things that can often use improving, especially at smaller companies. Process, architecture, deployment system, reduced meetings of team, optimizing the SLM software...it's easy to get overwhelmed, especially if you have a large team, or in my case, doing the job of a tech lead and engineering manager. It is a lot to swallow. Prioritizing the most important points on what is being tackled and communicating why is very important.
kuharich 9y ago
Prior discussion: https://news.ycombinator.com/item?id=8406507 https://news.ycombinator.com/item?id=8406507
siliconc0w 9y ago
Managers should get good at RTS games. A lot of the same principles apply - * production vs process - you can spend resources on improving process(usually tooling) to improve production but this isn't always an easy knob to tune and can have diminishing returns. "Automate all the things" is how I know you don't know what you're talking about. * DOTs - damage over time can be brutal, question every meeting and email that hits your team. Similarly- Engineers need large blocks of time to find flow and be effective(aka void rays). That 15 minute 2pm weekly check-in may seem trivial but you're pretty much nuking an afternoon's worth of productivity. * macro vs micro - you generally need to spend time on both. Even Sr. engineers can benefit from occasional guidance because you should know more than them(see below). (knowledge != intelligence) * bottlenecks/'stage III' production - you can have too many resources on something. * Some resources are much better at certain tasks than others. * situational awareness - know the executive roadmap, your roadmap, your internal customer's roadmaps, know 'the theory of how engineers are working in your org' and the reality. Know every project in your code repository. Know about most other possibly relevant open source technologies. Mostly this is just a lot of listening and reading. Be Omniscient * 'strats/build-orders' - similar to the above, know how the industry/competitors solve the same problems your org has (but don't necessarily seek to copy them) That said, treating people like RTS units is also a good way be disliked and ultimately be ineffective so you have to do the whole empathetic human thing.
tempz 9y ago
Sadly, exactly 50% of engineers are below average, so hiring the best all the time is unsustainable. Thinking that you hired the best, however, is sustainable. The art of managing relies on the capability to get work done by all kinds of engineers. The talent is rarely universally allocated. Some very 'bright' ones will never properly finish the work. Some 'slow' engineers may have remarkable attention to details.
- rileymat2 9y ago
  50% are below the median. I am not sure 50% are below average.
mratzloff 9y ago
"When you do X, it makes me feel Y." I saw this phrase several times in this article and the linked article on "non-violent communication," but I don't think it's a particularly productive phrase. Consider the possibility that no one can "make you" feel anything, and that you are ultimately responsible for your own emotional state. For example, you can't command me to feel happy or sad. My emotional response is something I'm a party to, in combination with my own unresolved fears and insecurities. Instead, I suggest phrasing it in the present tense: "When you do X, I feel Y." That is observational and avoids any accusation or blame, so you can focus on the core issue at hand.

517 points by mzehrer 9y ago

Strongly disagree that an engineering manager shouldn't code; that is the shortest way to lose the respect of the team. Don't get me wrong; you need not be the "best" or the expert in all areas, but you do need to stay on top of technical developments both within and outside your organisation.

manojlds 9y ago
Where does it tell to not code?
- mpweiher 9y ago
  In fact: "You have to write code to remain an effective tiebreaker, but that’s where your coding responsibilities end." Just not "Personally fix bugs and ship features."
endymi0n 9y ago
There's an easy way to accomplish this: Commit yourself to 95% reading of code and 5% writing. Through great code reviews, spread your knowledge through the company and make others as good as you. Has the added benefit of making the stack more homogenous. (I still code review 50% of all commits relating to the data model - SQL & API interfaces myself) Then about the 5% - this is high prio, high visibility fixes where you bring in your extraordinary expertise in some domain. Believe me, that's enough to stay respected. Your time is much better spent at sparring systems architecture & high level design, hiring and building well-oiled teams and discussing the business needs with the rest of the company. Isn't as fun, Doesn't feel as good, but it helps most the long run. The alternative is a high performance coding monkey that gets a tiny area of the company right - and the rest of IT goes wild and rewrites core APIs in the latest three hype language because "we needed to get rid of technical debt". The 44 lessons of the OP are distilled gold from years of experience, I rehearse them every year and can recommend them to any aspiring tech lead.
- watwut 9y ago
  Code reviews by a dude who codes only a little and has formal power are pure hell. It is tricky when he is wrong, he can force you to do things that cause trouble and so on and so forth - all that because writing and reviewing code are much different and he is gradually out of touch.
  - valuearb 9y ago
    Why did you code it that way? How hard is it to answer that question?
    - NortySpock 9y ago
      "It will cause performance problems if you don't" , with only a gut feeling to back it up, and no actual testing. I just ran into this response yesterday, and I ended up going over his head (unfortunately) and asked our DBAs for a recommendation. DBA solution worked faster than either of the previous two solutions. I still need to apologise for that one.
      - mncharity 9y ago
        > I still need to apologise for that one. Curious. Running an idea by people to get their thoughts, because it's currently leaving you short on warm fuzzies... is something to apologize for? The initial solution was low on warm fuzzies for him. Your second solution was low on warm fuzzies for you. So you explored further. Where's the problem?
  - sanderjd 9y ago
    It sounds like you've run into some bad apples, likely due to "promoted too early" syndrome, which is unfortunately pretty common. In my experience, code review by senior engineers is extremely valuable whether or not they're currently writing much code.
    - Spooky23 9y ago
didibus 9y ago
I'd rather a manager who seems to care about me. Someone who is fair to the team, and shields us from the executive pressure. Someone that gives me challenging work which I could fail at, and recognises that I can fail and that it's ok if I do. Most of all, someone who dispays real appreciation for the value I add to the team. I honestly don't care if they code or not.
- freekh 9y ago
  Second this a lot. In fact I am gonna steel exactly this and feed it back to my org
kayoone 9y ago
Engineering managers that also code a lot usually fall short on the managing part, at least in my experience. Imo it's better if they focus on building a great team, guiding the team in the right direction by doing code reviews and making the hard decisions and be somewhat of a shield between the devs and other internal or external stake holders. Sounds boring, but provides more value as a whole imo. It's also why i opted to not be a manager right now so that i can still code full time. This does not apply if you are a <10 people company though.
- kochthesecond 9y ago
  I recently quit a job where I was in practice the tech lead. I did probably 60% code reviews, and made sure the architecture as a whole kept moving towards a coherent view and quality. But it was boring as I don't particularly enjoy teaching new developers basics of coding production ready systems every few months, especially when tied down as a consultant for a government organization. I ultimately had very little to say in what tech we could deploy. I therefore decided to go somewhere I might get more freedom to build quality with a bit less politics.
- TH3R3LL1K 9y ago
  I'm currently working for a company where the our manager holds a tight grip against the code we write, but he doesn't seem to guide us in the correct direction.
samlittlewood 9y ago
A recipe for disaster is for a manager's code to wind up on the critical path, then become a blocker - bad code & bad management. A possibly better approach is for managers to have a few side proejcts, scouting out potential risk reducing things, at a higher temperature, away from the main project. Great if one of them lands - no added problems if not. Also, if they land in the project, they are no longer the responsibility of the manager.
pjmlp 9y ago
I have about 30 years coding experience, never had a manager that was still writing code after earning the position, other than a few Office macros. It was never an issue to us and they were always respected by the team, except for the few ones that never should have been managers to start with. Any manager that wants respect from the team needs to support them, specially against stupid decisions from upper layers. Have good social skills and specially important, how to raise morale in darker times. Knowing to code is irrelevant.
- kochthesecond 9y ago
  I agree, having good social skills and being good at moving things forward (often in a political landscape) is more important than coding skills.
- hoschicz 9y ago
  Where have you worked during your 30 years of experience? Big/small companies? What sector?
  - pjmlp 9y ago
    Education, Research (CERN), Shipping (Harbour IT), Telecommunications (CRM, Mobile Operators, OEMs), Life Sciences, Manufacturing. Mostly enterprise size companies.
watwut 9y ago
I had great managers who did not coded and had respect. They managed politics out of department, managed to find good trade off between autonomy and controll, made decisions where the team could not.
tootie 9y ago
I'm currently managing projects on tech stacks I have no experience with. It's definitely a handicap but I can still do 90% of my job pretty effectively. I just felt on my team more. One big thing I've learned is the manager should never take on big pieces of development. The other demands on your time mean that every task will take longer and you'll end up being a bottleneck.
xborns 9y ago
Actually I somewhat disagree with that. I think they should code to some extent, but it doesn't scale in my experience. I lean to say #7 is a good point. If the manager is required to complete the feature their "free" time is't the same as an engineer - read meetings/discussions. I manage two teams and when I first became a manager my instinct was to take tickets along with the team. Yet my other responsibilities came in play and made it harder for me to finish tickets I assigned to myself and others on the team waited. I still code review and partake in high level design and some scripts here or there etc. but not mainline code that another engineer will depend on to be completed by xyz date. The goal of a manager is to ensure the work pipeline and project trajectory are on path with the company needs while still taking time to learn new tech and skill-sets of the team. Of course most importantly protecting their time from distractions. To move from manager upwards, building a great team that trusts each other and follows and ensures the team standards is crucial. If I am required for every decision or code review, then I become the bottleneck. Empowering other people and trusting their judgement was one of the harder leanings growing from manager upward.
ransom1538 9y ago
Couldn't agree more. Engineering managers that have removed themselves from the ability to contribute will also lose touch with: design, build systems, architecture, qa, etc. At that point they are just a bad PM. When I was a vp eng. what helped me the most was having ONE feature that I owned. I was forced to use the build system, go through qa, fight with design. It was never something massive, or hindered other groups, but if someone on the team bitched: "this framework sucks because.." -- I was able to jump in.
curun1r 9y ago
It's not that you don't code...you need to code to stay relevant. It's that you shouldn't code serious production features/issues. As a manager, you're context switching constantly and it's very difficult to achieve the necessary quality. You'll never get the uninterrupted time necessary to do anything big. 5-10 min fixes are good targets for a manager, as are projects that would otherwise distract the team, like spikes on potential new technology. You should use your coding to further your overall goal of keeping your team focused and you should limit your coding so that all the major accomplishments of the team belong to the team members and not the manager.

deleted 9y ago

[deleted]

gcatalfamo 9y ago

Number 11: you are probably talking about authoritativeness and not authority

bmsleight_ 9y ago

"Don’t make decisions unless you have to. Whenever possible, allow the team to explore ideas and make decisions on its own." Spot on, a good leader does not make all the decisions. It is counter-intuitive to popular culture, but this is stop on. I would go on to say minimising your decisions, also helps to spend more time on a key decision when it is really necessary.

samlittlewood 9y ago
A variation on this is not swoop in and make discoveries that the team is very close to finding - let them enjoy the thrill (even if you have to nudge them a bit in the right direction).

jkovacs 9y ago

Question: It says at point 8: > Don't supervise the quality and volume of people’s work. And I agree with the argument following that sentence. On the other hand, 2 points above that it says: > Do enforce behavioral and performance standards. Fire bullies and underperformers. So how else do I recognize underperformers without taking note of quantity and quality of people's output? Surely I can't just take someone else's word for it (and by the point a peer complains about this it's probably too late already anyway?).

pweissbrod 9y ago
Measure timeliness with respect to estimates. Measure the transparency in which they communicate the progress and focus of their work. Measure the clarity in their design and scoping. Measure what other developers say about their work in peer reviews. Measure how well their work runs in production, how many escalations and emergency bug fixes are needed?
- afarrell 9y ago
  > Measure timeliness with respect to estimates What if you have an employee who doesn't know how to do software estimation? Do you know of ways to teach people how to do estimates or resources/habits they can follow to learn how to estimate how long tasks will take? I ask this as someone who has only received the advice "go with your gut and triple it." There is a book by Steve McConnell on estimating larger projects but nothing out there on estimating things within a week.
  - Terretta 9y ago
    You can only estimate what's known. If the problem is in fact known, your estimate will be the time to pull in a library from GitHub. If it's not to pull in a library, you're into unknowns. Asking to estimate may work in aggregate if your 'gut' is good at assessing the amount of unknown your devs' face (e.g., 2x as much unknown work - multiply estimate by 3), but not in the specific. The specific amount of unknowns in a given task are unknown. To translate a requirement into code will take exactly as long as it takes to discover and bridge the unknowns. You can't do anything about that, other than (a) change the requirement, or (b) change how much is known by the developer.

joshuaswaney 9y ago

The emotional side of management goes so much deeper than what's covered by this list. Develop a vision and a strong sense of purpose in your engineers and they'll develop a mindset of building the future instead of maintaining the present. Foster a "we're all in this together" atmosphere and your engineers will develop a fanatical drive for success - either we all succeed or we all fail, it's not every man for himself. The deep emotional drive is also what causes startups to succeed where big companies fail, despite their massive resources.

jasode 9y ago

This is a fine list and there's nothing too controversial that people would disagree with. That said, I only counted 6 items out of 44 that's specifically "engineering" related. (5, 7, 10, 12, 14, 15) The other 38 bullet points are universal lessons that also apply to non-engineering managers such as a director of a creative team in an ad agency, or project supervisor of a construction crew, or a showrunner in charge of scriptwriters for TV episodes, etc. Empower your team and make decisions when necessary, etc.

biztos 9y ago

Having just spent a couple weeks on a pretty hard engineering problem, after having done more "architecture" stuff for quite a while, I would definitely add one thing to the Do's: * Protect your engineers' attention. As a manager you are the primary firewall between the world of distraction and the world of getting shit done. Most places these days have institutionalized some amount of distraction -- the various recurring "ceremonies" -- but anything beyond that, it's essential that the manager can protect the engineers from being distracted when they're working on hard problems. (I've been pretty lucky in this regard throughout my career, but now that part of my job is to live among the distractions it's really been driven home.) Also: > You’re the one who makes hiring and firing decisions. Everything that happens on your team is your responsibility. This is, to put it gently, not quite true in larger organizations.

jt2190 9y ago
> Protect your engineers' attention. Can you elaborate on "attention", and what does "protecting" it look like? (I've seen this reasoning used to keep developers out of requirements gathering, for example.)
- FLUX-YOU 9y ago
  >I've seen this reasoning used to keep developers out of requirements gathering, for example. That can be fair reasoning if you already have difficult work to do and your customers are noisy, disorganized, or inexperienced with developing requirements (think NYC window-shopping for features on someone else's credit card).
  - drieddust 9y ago
    Correct, butttt "Customer is king." On a serious note, I have seen more projects ending into dumpster because we listened to customer too well and didn't actually infer the meaning which lies between the lines. Most managers I have encountered are just messenger pigeons. Sometimes I wonder how system still works!
- enraged_camel 9y ago

AlexCoventry 9y ago

I read this recently and found it very insightful because whereas most software management essays seem to have an agenda of advertising the author as a great person to work with, this one seems like a pretty straightforward dump of lessons learned.

exelius 9y ago

It's pretty simple: engineers are professionals. Professionals make mistakes, but are most effective when allowed to own up to them without consequences and learn from them. In a good software team, a single developer's "big mistake" gets fixed by the whole team. I guarantee nobody on that entire team will make that same mistake; nor will they hold anything against the offending developer unless there's a pattern. But in short, empowerment is the most effective leadership style in this environment. It's not appropriate for all employees (specifically newer folks who need a bit more hand-holding at first) but for professional workers like engineers, it's really the only way to go -- especially if you have senior technical employees who have decades more experience than their manager.

tootie 9y ago

I guess it varies by company, but my job is more about managing the team's exposure to outside forces. I work with product and client teams to make sure we're delivering the right solution and we're promising something achievable. That's at least half my job.

boltzmannbrain 9y ago

+ a meta-point: Learn these through experience, not in a classroom. Having managed engineers in industry and also gone through a masters program in engineering management, 90% of what makes me a decent manager/leader/coach today can be attributed to the former.

douche 9y ago
The dirty secret is that 90% of all formal education is a waste of time, and is just signalling hoop-jumping.
- mcginleyr1 9y ago
  I thought it was helpful when I was doing it the first time. I saw things it made the human capital and self assessment courses much more useful to everyone when I could ask meaningful questions. So really I see leadership masters being helpful when you're first attempting to manage not later or before.
- loco5niner 9y ago
  Overall, my CompSci degree certainly wasn't. Some classes were though.

guilt 9y ago

Big Companies have management who cash in at the expense of young exploitable engineers. Personally I'd like to see the top management get fired.

theprop 9y ago

The single most important thing in engineering management is hiring only the best. The best have two key characteristics: strong technical skills primarily in aptitude but also in technical knowledge, and a great ego-less attitude. It's at least as important to test for ego than for technical skills. Most of our "engineering disasters" were related to lowering our bar for hiring. Some "engineering disasters", though, i should note were related to inexperienced product development - so if you're a first-time product leader, get an experienced mentor.

jalayir 9y ago
> lowering our bar for hiring Let me guess, Amazon?
- elliotec 9y ago
  Why would that be your guess?
  - imajoo 9y ago
    Amazon has a thing about "bar raisers" across the organization.
    - khazhoux 9y ago
      It's very common concept.
humanrebar 9y ago
> The single most important thing in engineering management is hiring only the best. I agree. It's easier said than done, though. Many engineering managers aren't really involved in the code in any real way. I can't imagine running a restaurant and not inspecting the kitchen, seeing hosts greet patrons, seeing how well tables stay cleared of dirty dishes, and so on. I find that a lot of "hire the best" ends up boiling down to knowing which engineers are popular with "technical" folks and haven't obviously messed up (at least to someone who hasn't really looked at code or deployments). I'm not sure how to keep this from coming down, again, to politics and popularity.

kator 9y ago

I always say management is they easiest job because you only have four things to do, and I'm sure your team has more than that to do: 1) Provide Air Cover 2) Provide resources 3) Provide direction 4) Get the F* out of the way Don't over think it. Empower your teams, trust them. They'll make mistakes just like you do. It's not how bad you F* Up it's how well you recover. Originality in mistakes is the best I can ask for. Let's learn, progress and do better together. I've been in tech for 35 years, if you think you've seen it all, you haven't and neither have I, so let's figure it out together and get some S*t done.

tetrep 9y ago
I think a lot of the difficulty of management is not in the description of you duties, but rather the difficulty in finding the "right" thing to do, which is very difficult when it comes to soft skills, which almost always lack any quantitative way to measure directly, and must be inferred from secondary and indirect metrics.
khazhoux 9y ago
Wow, that sounds like a lazy shitty manager. Every engineering team has problems they can't deal with on their own, either because it's out of scope, it's high-level organization, or whatever. A GOOD manager spends a significant chunk of their week ACTIVELY fixing problems. Not getting-the-fuck-out-of-the-way!! They should help clear the way. They should help fill gaps in the team, plan, or execution. Talk to other teams and see if everyone's on the same page. Make sure everyone agrees on priorities. Make sure your team's work integrates with what everyone else is doing. Be aware of everything going on around you (esp with other orgs, etc) so you know how it all fits together and your team doesn't waste time. Don't just listen and nod during 1:1s and then give some off-the-cuff suggestions. Don't just "get out of the way". And you don't need nearly that much Air Cover when you're team is aligned with the rest of the company, so make sure THAT happens instead of trying to "protect" the folks that happen to report to you. If a great team's manager can't point to what they ACTIVELY DID to get the team to success, they're disposable.
- OpenDrapery 9y ago

pacaro 9y ago

Did I miss something? I see nothing on this list that touches on mentoring or growing. I do see a line about firing underperformers. I've heard a metric that it costs between 2.5-5 time annual salary to replace someone. Sometimes an under performer is just in the wrong role, or on the wrong team; when this is the case they probably know it. Ask them!

Bahamut 9y ago

I am learning a lot about engineering management through turmoil, and I think the most important lesson for me is to avoid doing too much. There are many things that can often use improving, especially at smaller companies. Process, architecture, deployment system, reduced meetings of team, optimizing the SLM software...it's easy to get overwhelmed, especially if you have a large team, or in my case, doing the job of a tech lead and engineering manager. It is a lot to swallow. Prioritizing the most important points on what is being tackled and communicating why is very important.

kuharich 9y ago

Prior discussion: https://news.ycombinator.com/item?id=8406507 https://news.ycombinator.com/item?id=8406507

siliconc0w 9y ago

Managers should get good at RTS games. A lot of the same principles apply - * production vs process - you can spend resources on improving process(usually tooling) to improve production but this isn't always an easy knob to tune and can have diminishing returns. "Automate all the things" is how I know you don't know what you're talking about. * DOTs - damage over time can be brutal, question every meeting and email that hits your team. Similarly- Engineers need large blocks of time to find flow and be effective(aka void rays). That 15 minute 2pm weekly check-in may seem trivial but you're pretty much nuking an afternoon's worth of productivity. * macro vs micro - you generally need to spend time on both. Even Sr. engineers can benefit from occasional guidance because you should know more than them(see below). (knowledge != intelligence) * bottlenecks/'stage III' production - you can have too many resources on something. * Some resources are much better at certain tasks than others. * situational awareness - know the executive roadmap, your roadmap, your internal customer's roadmaps, know 'the theory of how engineers are working in your org' and the reality. Know every project in your code repository. Know about most other possibly relevant open source technologies. Mostly this is just a lot of listening and reading. Be Omniscient * 'strats/build-orders' - similar to the above, know how the industry/competitors solve the same problems your org has (but don't necessarily seek to copy them) That said, treating people like RTS units is also a good way be disliked and ultimately be ineffective so you have to do the whole empathetic human thing.

tempz 9y ago

Sadly, exactly 50% of engineers are below average, so hiring the best all the time is unsustainable. Thinking that you hired the best, however, is sustainable. The art of managing relies on the capability to get work done by all kinds of engineers. The talent is rarely universally allocated. Some very 'bright' ones will never properly finish the work. Some 'slow' engineers may have remarkable attention to details.

rileymat2 9y ago
50% are below the median. I am not sure 50% are below average.

mratzloff 9y ago

"When you do X, it makes me feel Y." I saw this phrase several times in this article and the linked article on "non-violent communication," but I don't think it's a particularly productive phrase. Consider the possibility that no one can "make you" feel anything, and that you are ultimately responsible for your own emotional state. For example, you can't command me to feel happy or sad. My emotional response is something I'm a party to, in combination with my own unresolved fears and insecurities. Instead, I suggest phrasing it in the present tense: "When you do X, I feel Y." That is observational and avoids any accusation or blame, so you can focus on the core issue at hand.