8 ms·

On Being an Engineering Manager

304 points by boyter 8y ago

misingnoglic 8y ago
Thanks for sharing :)
fizx 8y ago
I don't know if you're looking for advice, but: It seems like you aren't a manager, but rather a junior director who doesn't know it yet. 13 people across 4 initiatives is too much to directly manage effectively. Find someone to lead each one, and make them team leads. Meet twice weekly with your leads, once to plan, once to problem-solve. Move your HR/career-oriented 1:1s to every-other-week. If any of your team leads are good with people, delegate your 1:1s. You only need a half hour for recurring meetings. Delegate more.
- mk89 8y ago
  I am just a developer and I really like your advice. In my experience, though, I see managers and therefore companies struggling exactly because they do the opposite. They are unable to delegate, to trust and to think "he or she doesn't have the right experience to do it". Sometimes this stems from pride and arrogance - you are unable to admit that someone else can do what you are doing and you should maybe focus on something else. It can go as bad as a power play: if I grow people, eventually they want more and more. Other times it comes simply from ignorance: I have always done it this way, and I am not sure how to move forward, because nobody in the team is ready to lead.
  - McRask 8y ago
    Fwiw, there _are_ also times that there are no other people on the team who can do a thing.
    - mixmastamyk 8y ago
      Aka, a “teaching moment.”
    - mk89 8y ago
      I wonder how that can be, though. Either you are constantly surrounded by junior people, or...? I am sorry, but I can't believe that out of 10-15 people there is not a 20% of people who can do part of your job.
      - ianwalter 8y ago
        Yea more likely, I think, is that management is hesitant to give people a shot. They’re probably worried they’ll ask for more money or something.
      - Aeolun 8y ago
        I can tell you, out of 10-15 people, there are none that can do my job. This is obviously untrue, they can definitely do it, and there are people I’d be happy to see in those roles, but the quality of work would suffer in the short term, and we have a ton of deadlines/projects to complete.
        Swizec 8y ago
        And without delegating the quality of work will suffer in the long term. Which is better? Long term failure or short term hiccups?
        Aeolun 8y ago
        Depends on whether you ask management.
        rootusrootus 8y ago
        That's the trap. If you don't let people jump in and fail just because you know you can do it better right now, they will never be good enough.
        marcinzm 8y ago
        The problem is that at some point you'll become the bottleneck and projects will be delayed as a result. Or you'll get sick, a loved on gets sick, etc, etc. Either way productivity will suffer and things generally start to spiral downwards then (people get bored, leave the company, putting more work on you, etc.). In many places there is always something urgent and there will never be a good time to slow down. Then you end up in my first point eventually. So part of your job is to create that breathing room, push back on projects, get people trained, etc. Think long term and not just moment to moment. edit: And if you think training people now is painful, doing so when you're actually past the breaking point will be be a lot harder and cause a lot more disruption.
    - marcinzm 8y ago
      Then you should train them so they can do the thing. Having a bus factor of 1 is a bad thing even if you have room on your plate.
- btilly 8y ago
  In general I support the idea of delegating more. Which is inherently scary because you're of necessity delegating tasks to people who are less competent at it than you are. And there are lessons you need to learn, such as the fact that it is dangerous to have real decisions made in a 3-level meeting (employee, manager, manager's manager) because it is too easy to accidentally undermine the manager. That said, it is extremely important to distinguish between a technical lead and a people manager. They require different skillsets and mentalities. It is more likely that a competent developer will make a good tech lead than a happy manager. "Promoting" a developer who doesn't actively want it is too often a mistake that the developer solves by finding a more suitable job. Don't lose sight of the fact that when you promote your best developer to manager, the only things that are guaranteed are that you've lost a good developer and gained an inexperienced manager. This is why many tech companies have established parallel promotion tracks for tech and people management. With neither being inherently superior to the other. In fact Google's top employee, Jeff Dean, manages nobody. See https://ai.google/research/people/jeff https://ai.google/research/people/jeff for more on him.
  - skj 8y ago
    > In fact Google's top employee, Jeff Dean, manages nobody. Not true. He has VPs as his direct reports and thousands of indirects. Maybe it was true at one time, even in recent years. But not now.
    - btilly 8y ago
      Thanks for the correction. I am pretty sure it was true in 2010. I wonder when it changed, and why.
      - tomnipotent 8y ago
        In 2011, when he started the Google Brain initiative.
  - antognini 8y ago
    Jeff Dean manages a lot of people. He's currently the head of the RMI division if I remember correctly and has at least a few thousand employees under him. Sanjay on the other hand has remained an individual contributor.
- onlyrealcuzzo 8y ago
  As an engineering manager, this sounds like almost every startup I interview at. It's almost always the CTO directly managing ~15 engineers. The CTO is always a man. He's always hiring a manager only because he doesn't have time for the 1:1s anymore. He never believes in hierarchies. The engineering team is flat, he tells me. They don't need teams, no siree. He's only interviewing me, he assures, because 1:1s aren't a good use of his time anymore. Don't worry, he assures me, he'll still take care of all the architectural decisions. And he might even manage half of the team still, he hasn't decided. That's usually about the time I nope right out of the interview.
  - hitekker 8y ago
    Superb insight about 1:1s. They are an essential team process, which the manager alone is responsible for. They can't be delegated; a manager cannot establish and maintain a direct, personal relationship through a proxy. That's just not how human beings work. In my experience, the desire to "delegate" 1:1s typically signals that team is raising truthful (and deeply troubling) problems, which the executive does not want to think about. Rather than think, they rationalize: claiming that consistently and privately listening to their subordinates is "not a good use of my time", "drama-filled", "not relevant to the tech", "isn't that what HR is for?" or some easy excuse. Whatever helps them coast until they jump ship next year. Good on you for avoiding that mess, and for not playing along with their softheaded pretense.
    - apple4ever 8y ago
      I cannot stand weekly or less than monthly 1:1s and I dispute they are an essential team process. They often waste time and I do not find them useful for my team.
    - cosmie 8y ago
      It's also commonly a signal of an executive-by-default vs. an executive-by-experience. The traditional path to leadership roles generally involve a stepped process from a role that's fully an individual contributor to one that has virtually no IC component. It's progressive enough that by the time you've stepped up to another level of management you've already grown accustomed to what you needed to let go of and what you needed to shift focus to, while having someone above you to essentially provide integration and regression testing as you acclimate to your new role. A CTO-by-default skips that and goes from IC to "executive level authority and autonomy". They're not only managing people all of a sudden, but architecting teams and org structures. With little or no prior experience to lean on. So they nope out of it - avoid org structure planning (and ensuing uncomfortable decisions) by keeping it all flat, bring in a people manager as a short term solution to the problem they created with keeping up with everyone, while also avoiding some of the messier side of people management. And seek comfort in the familiar work of system architecture and (maybe) keep directly managing the parts of the team that are the most capable of self-management and aren't as uncomfortable to manage. Still a mess to be avoided, just as you said. But a mess that's rooted more in inexperience and discomfort than in arrogance and hubris.
- acconrad 8y ago
  It sounds like from the blog post that the OP opted out of EM in favor of solutions architect but this is still great advice and an accurate portrayal of who this person is (i.e. a junior director not an EM). The only thing I would push back on is the 1:1s - evidence shows it's most effective to meet weekly[1]. Delegate the 1:1s to your team leads (effectively making them the real EMs) and then have your problem-solving meetings become your 1:1s. Now you're managing managers, which is what makes you a director in the traditional sense. [1] https://www.manager-tools.com/2019/01/manager-tools-data-one-ones-part-1 https://www.manager-tools.com/2019/01/manager-tools-data-one...
paxys 8y ago
Great read. More people need to realize that moving into a people manager role is NOT a requirement for career advancement. If you feel that is the case at your company, and you are more passionate about coding or architecture, you should really consider switching jobs. There are a ton of companies out there that will value a great IC over an average manager. If you are at a smaller company, push for them to formalize a career ladder which has parallel tracks for manager and IC roles going all the way up till C-level execs.
- bradleyjg 8y ago
  > More people need to realize that moving into a people manager role is NOT a requirement for career advancement. It kinda is though. At any reasonably level of comp you care to name there's someone playing sports making that amount of money. Nonetheless it is entirely reasonable to say that playing sports isn't a great path for career advancement. Same thing with tech IC. Sure, there's someone, somewhere making $1MM/year as an IC, but there's a heck of lot more people with reports at making that. Same thing is true at $750k and $500k. Maybe at $300k it isn't? And yes, to be sure, that's a ton of money. But given how hard it is to advance from there, can you really expect to sit there for 20+ years? How many organizations are there around that don't have some kind (possibly unofficial) up or out rule?
  - humanrebar 8y ago
    > How many organizations are there around that don't have some kind (possibly unofficial) up or out rule? They don't push out the person that wrote all that business critical COBOL spaghetti. It's not all that hard to code yourself into job security. Digging into someone else's technical debt and stewarding it along for years 13-28 of its life is easy too.
    - bitwize 8y ago
      "I'm gonna code me a minivan."
ppod 8y ago
I manage a team that do what could broadly be described as data science, here is one thing I feel unsure about and I'd like others' opinion on: How much should I tell my team about what's going on above me? If my manager tells me about a customer meeting where they request a demo with certain broad requirements by a certain deadline. Should I go into the details of the overall business goal of the client and the exact deadline for the final demo? Or should I just delegate specific subtasks and keep the information structure within my team somewhat modular/encapsualted?
- ansy 8y ago
  IMO the manager’s job is never to subtask. That’s micromanagement. If you set a clear context for the team they will be best able to deliver the results you want. I’d go so far to say they can’t deliver the results you want without clear context. You may have recently been a successful individual contributor at your company. So it may seem like you know more than your employees about how to do the work. But even in this scenario you need to let go and realize your job is completely different now. You have had a tech lobotomy and are now a manger. A different species with no expectations of expertise.
- iaresee 8y ago
  I have, over the years, gravitated towards telling everyone in my teams as much as I possibly can at all times. I use top-down information sharing like your scenarios as a chance to connect my teams (which tend to be infrastructure and futher from the core business) to the business and their needs. Any system of information sharing that requires me to remember what and with whom I shared specific bits of compartmentalized information is ultimately doomed to fail. You'll forget who knows what and eventually screw up and then you look like a manipulative middle-manager for withholding information. Unless there's a clear reason not to share (layoffs, acquisitions, etc.), I share.
  - ro_sharp 8y ago
    Amen. Work without context is demoralising and can lead to micro decisions that don't align with the macro context of the business you're in.
painful 8y ago
Hopefully you won't subject your workers to scrum; it is evil. Refer to https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/ https://michaelochurch.wordpress.com/2015/06/06/why-agile-an...
- shemnon42 8y ago
  I would take everything that mchurch says with a grain of salt.
  - Aeolun 8y ago
    Grain of salt taken, but I don’t think these points are invalid.
  - painful 8y ago
    Granted it's an opinion, but if you've been through as much scrum as I have, especially if you're a senior developer, you'd know it's a true article.
- skj 8y ago
  I love reading his articles. Always good for a laugh!
  - painful 8y ago
    It's an extremely serious article. If you think it's good for a laugh, the joke's on you.
    - skj 8y ago
      It's not the article that is the joke.
jarjoura 8y ago
I actually think for most of us, after some point, switching to engineering manager track is often far easier to continue leveling up in. Most good companies have an equivalent tech track, but unless the stars are aligned and you're blessed with a supportive manager AND the right project that align with your talents, its going to take a much longer time progressing. Of course in both tracks, it's no longer only about your own contributions and impact to the team, but that your contributions and impact now translate to everyone else you work with so that they're able to improve their own contributions and impact. Or in another way, is what you're doing helping everyone else do better?! So even though that sounds straight forward, showing that at performance review time can actually be really challenging if you're in a tech role vs. a people management role. I've heard the complaint that some of us shouldn't be EMs, but I'm a firm believer that if it's something you enjoy, you can absolutely learn how to be a great EM. I would only consider sticking with the tech track if you enjoy the tech work more.
- maxxxxx 8y ago
  "I actually think for most of us, after some point, switching to engineering manager track is often far easier to continue leveling up in. Most good companies have an equivalent tech track, but unless the stars are aligned and you're blessed with a supportive manager AND the right project that align with your talents, its going to take a much longer time progressing. " That's a really important point. In theory my company has a technical track but it's freakishly difficult to move up on it. On the other hand I see a lot of mediocre managers moving up higher on the pay scale all the time.
  - silveroriole 8y ago
    My company has a tech track but NO developers are on it. It’s basically designed so that nobody can ever qualify for it. As far as I can see it’s purely there to entice developers and then push the blame back on them when they inevitably have to turn into managers - “look, you COULD have been on the tech track if you tried harder, you made the choice to progress on the management track.”
    - 8y ago
RickJWagner 8y ago
When I was a junior programmer (about 25 years ago), I thought it would be great to be a programming manager. One day, a senior programmer told me he'd been a manager for a while. I was surprised-- I figured it was a step down to go back to coding. I asked him why he went back to programming. His reply: "When you are a programmer, you have a boss above you that gives you tasks. When you are a manager, there is a boss above you and several people below you that bring you tasks. They nip at you from the top, and they nip at you from the bottom." It made sense to me.
ascotan 8y ago
There are some trade offs when you go into management (from experience): Upsides: + Your reports will treat you with respect + You will get more opportunities to travel + You will likely get much more visibility in the organization + You will get the opportunity to engage in team building activities and have fun + You can set the standards and direction of the group Downsides: - You will have to learn the art of politics to deal with your peers - You need to be much more cautious about your communication and actions - You have a target on your back and so you need to learn how to block - You will likely have to spend more money on corporate travel & activities than your used to - You have to have the maturity to deal with 'wasteful' activities that are part of management One of the biggest problems with people being asked to be a manager is whether or not the organization is asking for a real "manager" or a "leader". This is a particular problem with technical staff being promoted to management. Managers by definition are there to set everyone straight. Define the rules. Make the process repeatable. Make sure no one is out of line. However, many companies are not really seeking this from technical staff. What they really want are "leaders". If people are asking you as a manager to set the technical direction or lead and train the engineers or give presentations at conferences, they're not asking for a traditional "manager". Ultimately, if you seek to be a traditional manager (in this type of environment) you're doomed to fail. Great people managers are really a type of coach. They give pep talks, they throw events, they motivate, recruit the best talent, etc. Think of your high school football coach. In this style of management you're going to be graded on retention, motivation, drive, energy, etc. etc. If this isn't you, you better think twice about moving from engineering. If this organization is really looking for an Architect or Principal Engineer that will dive the direction and strategy for their technology, they let them know that.
- muratsu 8y ago
  Are there any good books or resources that comes to your mind for better understanding what you've described?
  - e-_pusher 8y ago
    I have found The Manager's Path useful about this. She goes into good detail about what it means to be a manager vs a tech lead, for example. https://www.amazon.com/Managers-Path-Leaders-Navigating-Growth/dp/1491973897/ref=sr_1_3?ie=UTF8&qid=1550465859&sr=8-3&keywords=the+manager%27s+path https://www.amazon.com/Managers-Path-Leaders-Navigating-Grow...
infinii 8y ago
If you're having 1:1s each fortnight, you probably won't even need 30mins. In practice, schedule for 30mins but in reality it rarely takes that much time so don't fret about losing so much time.
austincheney 8y ago
Managing developers is weird. I have a unique perspective on this matter as I am a senior developer at one company and a managing principle at another. As a senior developer I am deeply introverted and I am skilled at my craft because I can go into these fugue states of deep focus blocking out everything else. I don't need to be concerned with the world outside my team, and often not so concerned with my teammates. As an individual contributor your success is largely determined by the quality and frequency of your contributions. As a manager you need to be more concerned with what is going on outside the team than within. You are the interface and diplomat between the team and everything else. You are interfacing externally outside the team so that your team doesn't have to and so that you are the single funnel of priority and direction. As a manager you are largely done writing code. Use your experience writing code to set the proper tone and direction when your developers hit a wall. Guide them into the proper direction for resolution and provide them with resources they likely aren't even aware of. That is you, the manager, providing a vague solution to a code problem without having to write any code. Your coding experience allows you to set business standards (not code standards) that determines acceptable contributions and enforce those standards. Code standards tend to be highly subjective and are often completely vane or superfluous. By ensuring the standards exist outside of code, such as execution speed or statement count, the standards are likely to be objective and uniformly applied. You should automate this enforcement as much as possible and grant exceptions only with careful deliberate consideration. Setting high standards is a defensive action against future stupidity. Even as a manager there is still much in the world you do not control. Strong leaders are proactive in shielding their team from stupidity as much as possible. Perhaps the strongest and most enduring form of stupidity defense is CYA (cover your ass). High standards of deliverables is proactive CYA. If standards are set high members of your team will complain. It will happen. Accept it and own it. Managers without a strong development background or weak soft skills may find it easier to keep the team happy. That is bad. Remember who your team works for. They work for you, not the other way around. If you are quick to cave on product quality its like sharks smelling the blood in the water. Smart managers will spin this as the company's product is merely a tool to advance the team members personal development and competence of their craft. If after sufficient time, patience, and training are exhausted and a teammate still cannot accept the high standards transfer them off the team. Incompetence is a drag on everybody. The most common reason why product quality slips is because either the business is setting unreasonable delivery timelines or because your team lacks confidence. The second is far more common than the former since, as the manager, you can often negotiate more realistic external delivery terms. An inexperienced team is not a reason to release shit back to the business. That is the opposite of CYA. Fortunately your team will make this foolishness clear to you by advocating for easy. If you ever hear your team advocating solutions or alternatives because of easy or hard take a long hard pause and reevaluate what they are really saying. When they advocate for easy it might sound something like: "We should use framework X because it makes things easy and then we can deliver twice as fast!" What that really says is something like: "We are slow to make decisions and our jobs are challenging!" In that case the problem is insecurity/anxiety and the framework is a bandage over a much larger wound. Always remember the name of the game is high quality output so that you put your CYA immediately up front. The easy option your team advocates is likely to shred every ounce of CYA both now and in the future. One way think of your place in the world, as a manager, is that the group is worth more than an individual but the product your team supports is worth more than you or your team. Your entire team can be laid off and that product will continue to live.
azmany 8y ago
nice write up. Thanks!

304 points by boyter 8y ago

Thanks for sharing :)

fizx 8y ago

I don't know if you're looking for advice, but: It seems like you aren't a manager, but rather a junior director who doesn't know it yet. 13 people across 4 initiatives is too much to directly manage effectively. Find someone to lead each one, and make them team leads. Meet twice weekly with your leads, once to plan, once to problem-solve. Move your HR/career-oriented 1:1s to every-other-week. If any of your team leads are good with people, delegate your 1:1s. You only need a half hour for recurring meetings. Delegate more.

mk89 8y ago
I am just a developer and I really like your advice. In my experience, though, I see managers and therefore companies struggling exactly because they do the opposite. They are unable to delegate, to trust and to think "he or she doesn't have the right experience to do it". Sometimes this stems from pride and arrogance - you are unable to admit that someone else can do what you are doing and you should maybe focus on something else. It can go as bad as a power play: if I grow people, eventually they want more and more. Other times it comes simply from ignorance: I have always done it this way, and I am not sure how to move forward, because nobody in the team is ready to lead.
- McRask 8y ago
  Fwiw, there _are_ also times that there are no other people on the team who can do a thing.
  - mixmastamyk 8y ago
    Aka, a “teaching moment.”
  - mk89 8y ago
    I wonder how that can be, though. Either you are constantly surrounded by junior people, or...? I am sorry, but I can't believe that out of 10-15 people there is not a 20% of people who can do part of your job.
    - ianwalter 8y ago
      Yea more likely, I think, is that management is hesitant to give people a shot. They’re probably worried they’ll ask for more money or something.
    - Aeolun 8y ago
      I can tell you, out of 10-15 people, there are none that can do my job. This is obviously untrue, they can definitely do it, and there are people I’d be happy to see in those roles, but the quality of work would suffer in the short term, and we have a ton of deadlines/projects to complete.
      - Swizec 8y ago
        And without delegating the quality of work will suffer in the long term. Which is better? Long term failure or short term hiccups?
        Aeolun 8y ago
        Depends on whether you ask management.
      - rootusrootus 8y ago
        That's the trap. If you don't let people jump in and fail just because you know you can do it better right now, they will never be good enough.
      - marcinzm 8y ago
        The problem is that at some point you'll become the bottleneck and projects will be delayed as a result. Or you'll get sick, a loved on gets sick, etc, etc. Either way productivity will suffer and things generally start to spiral downwards then (people get bored, leave the company, putting more work on you, etc.). In many places there is always something urgent and there will never be a good time to slow down. Then you end up in my first point eventually. So part of your job is to create that breathing room, push back on projects, get people trained, etc. Think long term and not just moment to moment. edit: And if you think training people now is painful, doing so when you're actually past the breaking point will be be a lot harder and cause a lot more disruption.
  - marcinzm 8y ago
    Then you should train them so they can do the thing. Having a bus factor of 1 is a bad thing even if you have room on your plate.
btilly 8y ago
In general I support the idea of delegating more. Which is inherently scary because you're of necessity delegating tasks to people who are less competent at it than you are. And there are lessons you need to learn, such as the fact that it is dangerous to have real decisions made in a 3-level meeting (employee, manager, manager's manager) because it is too easy to accidentally undermine the manager. That said, it is extremely important to distinguish between a technical lead and a people manager. They require different skillsets and mentalities. It is more likely that a competent developer will make a good tech lead than a happy manager. "Promoting" a developer who doesn't actively want it is too often a mistake that the developer solves by finding a more suitable job. Don't lose sight of the fact that when you promote your best developer to manager, the only things that are guaranteed are that you've lost a good developer and gained an inexperienced manager. This is why many tech companies have established parallel promotion tracks for tech and people management. With neither being inherently superior to the other. In fact Google's top employee, Jeff Dean, manages nobody. See https://ai.google/research/people/jeff https://ai.google/research/people/jeff for more on him.
- skj 8y ago
  > In fact Google's top employee, Jeff Dean, manages nobody. Not true. He has VPs as his direct reports and thousands of indirects. Maybe it was true at one time, even in recent years. But not now.
  - btilly 8y ago
    Thanks for the correction. I am pretty sure it was true in 2010. I wonder when it changed, and why.
    - tomnipotent 8y ago
      In 2011, when he started the Google Brain initiative.
- antognini 8y ago
  Jeff Dean manages a lot of people. He's currently the head of the RMI division if I remember correctly and has at least a few thousand employees under him. Sanjay on the other hand has remained an individual contributor.
onlyrealcuzzo 8y ago
As an engineering manager, this sounds like almost every startup I interview at. It's almost always the CTO directly managing ~15 engineers. The CTO is always a man. He's always hiring a manager only because he doesn't have time for the 1:1s anymore. He never believes in hierarchies. The engineering team is flat, he tells me. They don't need teams, no siree. He's only interviewing me, he assures, because 1:1s aren't a good use of his time anymore. Don't worry, he assures me, he'll still take care of all the architectural decisions. And he might even manage half of the team still, he hasn't decided. That's usually about the time I nope right out of the interview.
- hitekker 8y ago
  Superb insight about 1:1s. They are an essential team process, which the manager alone is responsible for. They can't be delegated; a manager cannot establish and maintain a direct, personal relationship through a proxy. That's just not how human beings work. In my experience, the desire to "delegate" 1:1s typically signals that team is raising truthful (and deeply troubling) problems, which the executive does not want to think about. Rather than think, they rationalize: claiming that consistently and privately listening to their subordinates is "not a good use of my time", "drama-filled", "not relevant to the tech", "isn't that what HR is for?" or some easy excuse. Whatever helps them coast until they jump ship next year. Good on you for avoiding that mess, and for not playing along with their softheaded pretense.
  - apple4ever 8y ago
    I cannot stand weekly or less than monthly 1:1s and I dispute they are an essential team process. They often waste time and I do not find them useful for my team.
  - cosmie 8y ago
    It's also commonly a signal of an executive-by-default vs. an executive-by-experience. The traditional path to leadership roles generally involve a stepped process from a role that's fully an individual contributor to one that has virtually no IC component. It's progressive enough that by the time you've stepped up to another level of management you've already grown accustomed to what you needed to let go of and what you needed to shift focus to, while having someone above you to essentially provide integration and regression testing as you acclimate to your new role. A CTO-by-default skips that and goes from IC to "executive level authority and autonomy". They're not only managing people all of a sudden, but architecting teams and org structures. With little or no prior experience to lean on. So they nope out of it - avoid org structure planning (and ensuing uncomfortable decisions) by keeping it all flat, bring in a people manager as a short term solution to the problem they created with keeping up with everyone, while also avoiding some of the messier side of people management. And seek comfort in the familiar work of system architecture and (maybe) keep directly managing the parts of the team that are the most capable of self-management and aren't as uncomfortable to manage. Still a mess to be avoided, just as you said. But a mess that's rooted more in inexperience and discomfort than in arrogance and hubris.
acconrad 8y ago
It sounds like from the blog post that the OP opted out of EM in favor of solutions architect but this is still great advice and an accurate portrayal of who this person is (i.e. a junior director not an EM). The only thing I would push back on is the 1:1s - evidence shows it's most effective to meet weekly[1]. Delegate the 1:1s to your team leads (effectively making them the real EMs) and then have your problem-solving meetings become your 1:1s. Now you're managing managers, which is what makes you a director in the traditional sense. [1] https://www.manager-tools.com/2019/01/manager-tools-data-one-ones-part-1 https://www.manager-tools.com/2019/01/manager-tools-data-one...

paxys 8y ago

Great read. More people need to realize that moving into a people manager role is NOT a requirement for career advancement. If you feel that is the case at your company, and you are more passionate about coding or architecture, you should really consider switching jobs. There are a ton of companies out there that will value a great IC over an average manager. If you are at a smaller company, push for them to formalize a career ladder which has parallel tracks for manager and IC roles going all the way up till C-level execs.

bradleyjg 8y ago
> More people need to realize that moving into a people manager role is NOT a requirement for career advancement. It kinda is though. At any reasonably level of comp you care to name there's someone playing sports making that amount of money. Nonetheless it is entirely reasonable to say that playing sports isn't a great path for career advancement. Same thing with tech IC. Sure, there's someone, somewhere making $1MM/year as an IC, but there's a heck of lot more people with reports at making that. Same thing is true at $750k and $500k. Maybe at $300k it isn't? And yes, to be sure, that's a ton of money. But given how hard it is to advance from there, can you really expect to sit there for 20+ years? How many organizations are there around that don't have some kind (possibly unofficial) up or out rule?
- humanrebar 8y ago
  > How many organizations are there around that don't have some kind (possibly unofficial) up or out rule? They don't push out the person that wrote all that business critical COBOL spaghetti. It's not all that hard to code yourself into job security. Digging into someone else's technical debt and stewarding it along for years 13-28 of its life is easy too.
  - bitwize 8y ago
    "I'm gonna code me a minivan."

ppod 8y ago

I manage a team that do what could broadly be described as data science, here is one thing I feel unsure about and I'd like others' opinion on: How much should I tell my team about what's going on above me? If my manager tells me about a customer meeting where they request a demo with certain broad requirements by a certain deadline. Should I go into the details of the overall business goal of the client and the exact deadline for the final demo? Or should I just delegate specific subtasks and keep the information structure within my team somewhat modular/encapsualted?

ansy 8y ago
IMO the manager’s job is never to subtask. That’s micromanagement. If you set a clear context for the team they will be best able to deliver the results you want. I’d go so far to say they can’t deliver the results you want without clear context. You may have recently been a successful individual contributor at your company. So it may seem like you know more than your employees about how to do the work. But even in this scenario you need to let go and realize your job is completely different now. You have had a tech lobotomy and are now a manger. A different species with no expectations of expertise.
iaresee 8y ago
I have, over the years, gravitated towards telling everyone in my teams as much as I possibly can at all times. I use top-down information sharing like your scenarios as a chance to connect my teams (which tend to be infrastructure and futher from the core business) to the business and their needs. Any system of information sharing that requires me to remember what and with whom I shared specific bits of compartmentalized information is ultimately doomed to fail. You'll forget who knows what and eventually screw up and then you look like a manipulative middle-manager for withholding information. Unless there's a clear reason not to share (layoffs, acquisitions, etc.), I share.
- ro_sharp 8y ago
  Amen. Work without context is demoralising and can lead to micro decisions that don't align with the macro context of the business you're in.

painful 8y ago

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

shemnon42 8y ago
I would take everything that mchurch says with a grain of salt.
- Aeolun 8y ago
  Grain of salt taken, but I don’t think these points are invalid.
- painful 8y ago
  Granted it's an opinion, but if you've been through as much scrum as I have, especially if you're a senior developer, you'd know it's a true article.
skj 8y ago
I love reading his articles. Always good for a laugh!
- painful 8y ago
  It's an extremely serious article. If you think it's good for a laugh, the joke's on you.
  - skj 8y ago
    It's not the article that is the joke.

jarjoura 8y ago

I actually think for most of us, after some point, switching to engineering manager track is often far easier to continue leveling up in. Most good companies have an equivalent tech track, but unless the stars are aligned and you're blessed with a supportive manager AND the right project that align with your talents, its going to take a much longer time progressing. Of course in both tracks, it's no longer only about your own contributions and impact to the team, but that your contributions and impact now translate to everyone else you work with so that they're able to improve their own contributions and impact. Or in another way, is what you're doing helping everyone else do better?! So even though that sounds straight forward, showing that at performance review time can actually be really challenging if you're in a tech role vs. a people management role. I've heard the complaint that some of us shouldn't be EMs, but I'm a firm believer that if it's something you enjoy, you can absolutely learn how to be a great EM. I would only consider sticking with the tech track if you enjoy the tech work more.

maxxxxx 8y ago
"I actually think for most of us, after some point, switching to engineering manager track is often far easier to continue leveling up in. Most good companies have an equivalent tech track, but unless the stars are aligned and you're blessed with a supportive manager AND the right project that align with your talents, its going to take a much longer time progressing. " That's a really important point. In theory my company has a technical track but it's freakishly difficult to move up on it. On the other hand I see a lot of mediocre managers moving up higher on the pay scale all the time.
- silveroriole 8y ago
  My company has a tech track but NO developers are on it. It’s basically designed so that nobody can ever qualify for it. As far as I can see it’s purely there to entice developers and then push the blame back on them when they inevitably have to turn into managers - “look, you COULD have been on the tech track if you tried harder, you made the choice to progress on the management track.”
  - 8y ago

RickJWagner 8y ago

When I was a junior programmer (about 25 years ago), I thought it would be great to be a programming manager. One day, a senior programmer told me he'd been a manager for a while. I was surprised-- I figured it was a step down to go back to coding. I asked him why he went back to programming. His reply: "When you are a programmer, you have a boss above you that gives you tasks. When you are a manager, there is a boss above you and several people below you that bring you tasks. They nip at you from the top, and they nip at you from the bottom." It made sense to me.

ascotan 8y ago

There are some trade offs when you go into management (from experience): Upsides: + Your reports will treat you with respect + You will get more opportunities to travel + You will likely get much more visibility in the organization + You will get the opportunity to engage in team building activities and have fun + You can set the standards and direction of the group Downsides: - You will have to learn the art of politics to deal with your peers - You need to be much more cautious about your communication and actions - You have a target on your back and so you need to learn how to block - You will likely have to spend more money on corporate travel & activities than your used to - You have to have the maturity to deal with 'wasteful' activities that are part of management One of the biggest problems with people being asked to be a manager is whether or not the organization is asking for a real "manager" or a "leader". This is a particular problem with technical staff being promoted to management. Managers by definition are there to set everyone straight. Define the rules. Make the process repeatable. Make sure no one is out of line. However, many companies are not really seeking this from technical staff. What they really want are "leaders". If people are asking you as a manager to set the technical direction or lead and train the engineers or give presentations at conferences, they're not asking for a traditional "manager". Ultimately, if you seek to be a traditional manager (in this type of environment) you're doomed to fail. Great people managers are really a type of coach. They give pep talks, they throw events, they motivate, recruit the best talent, etc. Think of your high school football coach. In this style of management you're going to be graded on retention, motivation, drive, energy, etc. etc. If this isn't you, you better think twice about moving from engineering. If this organization is really looking for an Architect or Principal Engineer that will dive the direction and strategy for their technology, they let them know that.

muratsu 8y ago
Are there any good books or resources that comes to your mind for better understanding what you've described?
- e-_pusher 8y ago
  I have found The Manager's Path useful about this. She goes into good detail about what it means to be a manager vs a tech lead, for example. https://www.amazon.com/Managers-Path-Leaders-Navigating-Growth/dp/1491973897/ref=sr_1_3?ie=UTF8&qid=1550465859&sr=8-3&keywords=the+manager%27s+path https://www.amazon.com/Managers-Path-Leaders-Navigating-Grow...

infinii 8y ago

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

austincheney 8y ago

Managing developers is weird. I have a unique perspective on this matter as I am a senior developer at one company and a managing principle at another. As a senior developer I am deeply introverted and I am skilled at my craft because I can go into these fugue states of deep focus blocking out everything else. I don't need to be concerned with the world outside my team, and often not so concerned with my teammates. As an individual contributor your success is largely determined by the quality and frequency of your contributions. As a manager you need to be more concerned with what is going on outside the team than within. You are the interface and diplomat between the team and everything else. You are interfacing externally outside the team so that your team doesn't have to and so that you are the single funnel of priority and direction. As a manager you are largely done writing code. Use your experience writing code to set the proper tone and direction when your developers hit a wall. Guide them into the proper direction for resolution and provide them with resources they likely aren't even aware of. That is you, the manager, providing a vague solution to a code problem without having to write any code. Your coding experience allows you to set business standards (not code standards) that determines acceptable contributions and enforce those standards. Code standards tend to be highly subjective and are often completely vane or superfluous. By ensuring the standards exist outside of code, such as execution speed or statement count, the standards are likely to be objective and uniformly applied. You should automate this enforcement as much as possible and grant exceptions only with careful deliberate consideration. Setting high standards is a defensive action against future stupidity. Even as a manager there is still much in the world you do not control. Strong leaders are proactive in shielding their team from stupidity as much as possible. Perhaps the strongest and most enduring form of stupidity defense is CYA (cover your ass). High standards of deliverables is proactive CYA. If standards are set high members of your team will complain. It will happen. Accept it and own it. Managers without a strong development background or weak soft skills may find it easier to keep the team happy. That is bad. Remember who your team works for. They work for you, not the other way around. If you are quick to cave on product quality its like sharks smelling the blood in the water. Smart managers will spin this as the company's product is merely a tool to advance the team members personal development and competence of their craft. If after sufficient time, patience, and training are exhausted and a teammate still cannot accept the high standards transfer them off the team. Incompetence is a drag on everybody. The most common reason why product quality slips is because either the business is setting unreasonable delivery timelines or because your team lacks confidence. The second is far more common than the former since, as the manager, you can often negotiate more realistic external delivery terms. An inexperienced team is not a reason to release shit back to the business. That is the opposite of CYA. Fortunately your team will make this foolishness clear to you by advocating for easy. If you ever hear your team advocating solutions or alternatives because of easy or hard take a long hard pause and reevaluate what they are really saying. When they advocate for easy it might sound something like: "We should use framework X because it makes things easy and then we can deliver twice as fast!" What that really says is something like: "We are slow to make decisions and our jobs are challenging!" In that case the problem is insecurity/anxiety and the framework is a bandage over a much larger wound. Always remember the name of the game is high quality output so that you put your CYA immediately up front. The easy option your team advocates is likely to shred every ounce of CYA both now and in the future. One way think of your place in the world, as a manager, is that the group is worth more than an individual but the product your team supports is worth more than you or your team. Your entire team can be laid off and that product will continue to live.

azmany 8y ago

nice write up. Thanks!