Engineering management lessons
defmacro.org
defmacro.org
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.
Step 1 is asking what your subordinate's next position will be. Are the looking to stay technical? Are they looking to transition to a more managerial role? Do they not know? If they don't know or are uncertain, take a step back and ask them about what they enjoy doing, present them with options and then let them decide what their goal state is.
Step 2 is figuring out what you and they need to do in order to move to that goal.
Also, like the original article states, a lot of engineers are really bad at selling themselves. They won't ask for a promotion. They won't ask, "Okay, what am I missing that's preventing me from getting an acknowledgement for my skills and experience." If they're anything like me, they'll just look around after a while and jump ship when they find a position somewhere else that does give them what they want.
Finally, I should note that I am not a manager, nor do I have any desire to be one. But I've dealt with a fair number of managers, and the ones I've been most comfortable with have been the ones who've been direct about asking me (after 4-6 months) where I want to go in the organization. The worst feeling is going to one-on-ones week after week, and just rehashing the same points you go over in your daily stand-ups. Weekly one-on-ones should be about the developer and the manager figuring out where the developer wants to go in the organization and what needs to be done to get them there.
Know what your people want, and put them in a place where they have the chance to achieve it. That's what I want out of a manager.
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.
How do you write code without fixing bugs and shipping features? What do you mean by tiebreaker?
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.
Is "crunch time" a good thing in software development? It's certainly possible to deliver software without crunch times.
This day could be called "crunch time" even if no external deadline is handed down.
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.
"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.
> [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.
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.
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.
But my objection to the advice that management should not contribute technically is actually deeper than technical conflict resolution. Software is so hard that it becomes like child birth in that we have an overwhelming bias to forget the pain: the second you stop writing software, you start rewriting your own history. So as far as you can remember, it was all pretty straightforward, you always hit your deadlines, etc. And with this, you have started down the primrose path in which you just can't understand why this is taking so long and can't you guys just get all of the bugs fixed?! I (like many -- if not most -- software engineers) have seen this first hand: one of the most technical people I've ever worked with ventured into management, stopped writing software entirely, and -- with astonishingly short latency -- forgot over a decade of experience of pain. He forgot the inifinite complexity of software, and instead assumed that bugs were due to a lack of urgency, laziness, or worse. At one point, we were getting crushed by a very nasty issue, and he called a meeting to spend an hour telling us how important it was (oh, thanks!) and that he "didn't want to hear details; just get it fixed". If he had only asked "what I can do to help?", I was ready with: "You are -- or at least were -- a damned good engineer; you can help us debug it."
This brings me to a slightly broader point: as technical leadership, I believe that direct contribution is essential, but you do need to be very careful about how you contribute. The last thing you want is to be on the critical path of some feature and have the team blocked because you've been called into a board meeting (or a customer visit or an off-site or a planning meeting or any of the other of zillions of ways in which organizational leadership must spend some portion of their time). For me personally, the answer this is particularly easy because it dovetails with what I love to do anyway: my way of directly contributing to my team is to debug. By picking up bugs that no one else is looking at, you're out of the critical path, but you are helping the team, staying technically current, and reminding yourself -- constantly! -- of the brutal complexity of software engineering.
[1] http://www.slideshare.net/bcantrill/surge2013 video: http://www.youtube.com/watch?v=bGkVM1B5NuI
So I agree with never stop writing software - but it is also important that management learns to "let go". The article will never read as well as the one you imagined Ou would write. And somewhere there is a difficult balance between code that is not to your taste but still good enough and code that is not to your taste and not good enough.
I still have not worked that one out.
In the case where there is not enough data to make a reliable decision, the proper management move is to instruct both teams to collect more data, through load testing, user research, beta trials, etc. A well-known example of this was the early iPhone software development, in which one team built off the iPod OS and another off the Mac OS, until the best way forward became clear.
If the disagreement is not likely to be decidable with data, then it's probably a matter of opinion anyway, and a quick decision that sticks is better than agonizing.
[1] If you think your staff is lying to you, there are bigger problems than technical competence.
The reason for this is that life is a personnel problem, and as the team gets larger than 5 you just don't have that much room in your brain to accommodate the different modes of thinking required for dealing with people and code (or maybe you do: I don't, but my brain is particularly small, or so I've been told.)
With regard to the manager you described: they are simply a bad manager. Good managers are always working to facilitate their team's progress. Doing things like calling a meeting to harass over-worked people into working harder is bad management, and no amount of technical hands-on will change that. So my prediction is getting a person like that into the code won't help.
All different types of managers can be good or bad, my personal experience has just been that managers who dive into technical tasks, even just bug fixing and devopsy stuff, tend to neglect their managerial responsibilities just enough to be a chronic frustration to everyone below them.
Having only been in the industry a few years, it's also extremely frustration when a manager does not delegate responsibilities you're interested in taking on. So my view now is that if you're a manager taking on technical tasks, you're denying your employees opportunities to grow professionally. It certainly depends on mood at the time, but in a negative cycle, this can feel like a vote of no confidence from your manager.
When a dev team manager doesn't understand the architecture of the systems and exactly how everything works, they cannot be in full control of the team.
Businesses need crossover people. People who can code AND who "get it" at a commercial boardroom level.
If you're managing a team of 40, being involved directly in code/execution is likely impractical and perhaps even detrimental, but at any scale up to 15 people or so, direct involvement seems both practical and necessary to retain the respect of your team, and assure a quality product in the end.
The role that's being described above is one I would consider a "lead engineer", not a manager. The healthiest role division I've seen so far is when a team has a full time manager, and also a lead engineer or two who are ultimately responsible for making sure the needs of the business are being fulfilled by the engineering team.
Even worse if you use your position to cherry-pick projects away from your team because they "sound fun". Talk about a morale buster.
Managers should empower teams to do their best work, not get in the way or do their work for them.
The other thing is the role is very rarely leadership and more service. Leaders usually blossom from within your teams naturally.
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.
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).
What does this mean?
This is I think a very good piece of advice to consider carefully. It is common with engineers I've worked with to see people cringe when emotions are brought up. Surely, the ideal state for an engineer is to be devoid of strong emotion while assessing information and writing code? I'm sure we'd all like to believe in the consistency of our own performance and our ability to remain rational despite varying circumstances.
The truth is that without the powerful emotional signals in your brain, you would be mentally crippled in practically all decision making tasks. There's a good deal of science on this. A single paper can be found here: http://www.ncbi.nlm.nih.gov/pubmed/15134841
If you can key in to the emotional state of team members, you may be able to navigate arguments by understanding/anticipating their angles and communicating in a way that is more likely to be heard/well-received.
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.
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.
- 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.
By that you mean... you're not a manager of engineers?
Yes but "saying what no one dares to" needs a pre-requisite of having sufficient authority that no one can fire you for pointing out the emperor has no clothes.
If a manager can say out loud what no one else will, I bet you they all whisper it in the kitchen.
Well, most people do. They're biological organisms and all full of emotions and quirks. For instance, did you know that if you laugh at people's jokes, they tend to be more open to your ideas? True story. Does that make any sense at all? No.
In the same way, leadership isn't just about your position on an organizational chart. Sometimes you need to be stern when someone is out of line. You need to be assertive with your ideas, not just express them and expect people to understand their merit. It gets complicated.
It's not enough to be technically right or "in charge." You have to recognize that we're a bunch of apes building computer software. It's been an evolutionary blink of an eye since our intelligence and social structures became sufficient to farm and live in large groups. We're pack animals.
If you could summarize good engineering management in a sentence, I think it would be, "Treat people like people." The engineering part doesn't even factor into it until you've got everyone acting like decent human beings.
As a manager, I absolutely hate: "Your team looks to you for leadership." The disturbing thing is, mine kinda does. :) I hope it's because they're untrained in the arts of conflict resolution and "Imagine yourself as more than 1 person". Society relentlessly drills people as hyper-individualized followers. (If it's not just training, may god have mercy on their souls...)
Instead of "emotional", better terms might be societal and psychological? For example, part of my training in the male gender is obnoxious use of abstractions unsupported by the particular situation. When people do this, my thoughts turn savage. (Naturally, I try not to do it except when preceded by, "Don't know if it applies, but please let's consider...")
Breaking ties & whatnot reinforces your position as boss. This can contradict goals like promoting others as leaders. (Say, in proportion to their disempowerment in society. Because overall they need to be more observant than the more aristocratic types on top.)
On firing, is it so hard to help them find a job elsewhere?
On rough edges... the more assholish your team, the more rough edges you'll need to show. But ideally, one should escalate from more discreet routes.
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.