5 ms·

This is a good tale, and one that folks really should take to heart. I have observed when good engineers get an over developed sense of ownership they will move

This is a good tale, and one that folks really should take to heart. I have observed when good engineers get an over developed sense of ownership they will move "heaven and earth" to get things done. If you're managing one of these heroes it is your job to spread the load of what they do across the team so that no individual is so overloaded everything suffers. New managers who had been engineers before management and care about the work always tell me "I feel like I'm not doing anything, I should be helping or something." And I tell them, your job is to look. Look at your team, who is working late nights, who isn't. Who is meeting their commitments, who isn't. Let their actions guide you getting them what they need to be the best they can be, things that you, and only you, as the manager can get for them. That often means blocking incoming requests for more "stuff" (features what not), carving out time for your "doers" to help bring the new people up to speed. As part of an IBM manager training video there was a discussion about how the US Navy trains every person on a submarine to do every job because you never know when the person whose job it is won't be available to do it. That really resonated with me and I tried in future groups to try to overlap skills and cross train folks so that everyone could both appreciate what their peers were doing, but could also help out in a crunch if one part of the work needed more effort briefly.

jeffrallen 4y ago
> Your job is to look A really dramatic way of learning this is to be a volunteer firefighter. After a couple of years of experience where you know all the roles, they have you try out incident commander in an exercise. Now your job is to keep your head up, your eyes open, your hands off the equipment and manage your team. And you fail and fail again until you finally understand the role of a tactical commander (line manager).
- ChuckMcM 4y ago
  I really love that example. Thanks for sharing it.
- bluGill 4y ago
  The problem is you can do any single job better than the people under you, but by doing any job you can't keep track of anything else and so all the other jobs you are not touching get worse by more than the one you do.gets better.
kevin_nisbet 4y ago
I learned a similar lesson outside of tech... with low wage employees. Often people would have problems dealing with our employee's and complain, but if we dug a bit deeper, it was very often an issue with training, manuals, high turnover, or managers not being good at setting expectations.
- scruple 4y ago
  > managers not being good at setting expectations Expectation setting (and all of the things that fall out of it) is such a huge problem in my experience. I'm always trying to get clear expectations out of management. I had a ~decade gap in my career where the expectations were vague, ambiguous, bullshit... And worst of all misaligned. First-time engineering managers, specifically, were all so bad at this. I've walked from jobs where this was the root problem. Recently, I've landed in a company and on a team where the expectations are crystal clear and, as a result, and closing in on 20 years in this industry, I feel like I am able to do some of my best, most impactful work. Work that will likely outlive my tenure with this organization, and it feels fucking amazing!
  - steveBK123 4y ago
    New managers (or bad ones) have a hard time serving the basic functions of - filtering incoming noise, making priority decisions, and allowing some room for ICs to breathe. The last one - allowing ICs to breathe is extremely important. Most of my best / most impactful / bragged-by-others work was completely unplanned/unscoped/side project kind of stuff where I saw a recurring problem that could be addressed. Most of these were really like 1-2 days of focused work to get to 80%, then when management saw what it got them.. periodic planned/scoped/in-sprint tasks for improvements. New/bad managers often have a hard time not planning their ICs time down to the minute.
jdwithit 4y ago
The cross training point is absolutely crucial. I've managed or worked on multiple Ops teams where one person was the "network expert" or the "kubernetes expert" or whatever. If that person left the company for any reason, or even went on vacation, it was a disaster. People on a team can and should have their specialties but you absolutely must document and cross train so that someone can fill in when the expert is unavailable. Anything else is a horrible failure by management.
- mschuster91 4y ago
  > I've managed or worked on multiple Ops teams where one person was the "network expert" or the "kubernetes expert" or whatever. If that person left the company for any reason, or even went on vacation, it was a disaster. The problem is in almost all of these cases the workload doesn't match the financial capacity. Basically, there is an absurd lot of stuff you have to know for each of these fields, which is why domain experts develop in the first place - it's just too much to handle for a generalist unless you happen to run into a person on the autism spectrum with eidetic memory (these are rare and worth their weight in gold). So, assuming at least basic levels of redundancy, you'll need at least two people of each specialty (at least network, storage, virtualization/cloud, Linux, k8s, AD, macOS, Windows) in a company that has IT needs beyond "they're shuffling papers and emails". That's 16 people, but many organizations don't have enough work to justify employing that many people. Most end up with going the "hire a generalist or two and have them do everything", which can work for an incredibly long time but then it collapses in a dumpsterfire (the generalist calls it quits and no sane potential new hire wants that workload for that paycheck, the company gets hacked because the generalist only has rough concepts about client-side IT security, ...). Some end up with outsourcing their IT, either to some local company or to body farms from India. That usually has better capacity to account for vacations, sick days and whatnot, but comes at the price that you don't have someone you can call for a quick firewall change but have to wait days or weeks for the ticket to make its way around, leading to frustration and eventually attrition from the non-IT staff. And a very select few end up hiring a bunch of specialists, which produce very good quality and high amounts of internal satisfaction... but as these few companies usually do that because the CIO pushes for it, some day when the CEO wants to count beans and the CIO can't defend the effort ("preparedness paradoxon"), the department gets slashed, and they end up like the first sort.
scrapheap 4y ago
> who is working late nights, who isn't Add to this who starts work early and who doesn't - just tracking when someone finishes working doesn't give you any information without knowing how long they've actually been working for when they leave.
- ajmurmann 4y ago
  This! I've had to step up for folks in the past who were perceived by someone as "phoning it in" by calling out that the person frequently shows up before 6am
coldtea 4y ago
>And I tell them, your job is to look. Look at your team, who is working late nights, who isn't. Sounds like a toxic environment...
- ianmcgowan 4y ago
  From context (and a charitable reading), it seems obvious that the advice is to identify who is working nights in order to get them some help and spread the load.
ghaff 4y ago
And, of course, there are people working for that manager who don't think they are doing anything and that middle managers are a waste of oxygen--even though, in fact, they're shielding their team from a lot of crap and, as you suggest, they're doing a lot of coordination of a situation that would otherwise end up with a lot of wasted motion.
- steveBK123 4y ago
  I think the challenge is that ICs get "outed" pretty quickly if they underperform. Managers can be more at the whim of whether they have a good team or bad. A bad manager with a good team can take a long time to get "outed" while a good manager with a bad team might get whacked anyway. Upper Management doesn't really know how to measure the effectiveness of line managers. So it can make tech senior ICs pretty cynical about their management, especially if you are in a role as I often am where I am directly engaged by clients (directly receiving new requests), planning sprints, sizing tasks, planning roadmpaps, in hours of meetings per day, etc. At some point you wonder if your line manager is just an empty suit.
PragmaticPulp 4y ago
> New managers who had been engineers before management and care about the work always tell me "I feel like I'm not doing anything, I should be helping or something." Your points about managing (interfacing with the company, translating company’s demands into a reasonable, steady stream of work) are spot on, but I would also note that the expectations for engineering managers are all over the place right now. In my first engineering management job I was severely chastised for writing too much code, even though I had the time and was choosing non-critical tickets for myself. The company insisted that managers should manage/delegate and developers should develop with little to no overlap. I internalized this as the way management was meant to be. Later in my career I took another management role and followed the pure delegation strategy. I was later chastised for not writing enough code. They believed managers should only need to spend about half their time managing and the rest should be spent doing IC work. They never communicated this, but assumed it was just how managers knew they were supposed to operate. Even later in my career I took a “director” role, which was appropriate for my career progression to that point. I was stunned when the VP I reported to informed me that I needed to be spending “at least 2/3” of my time writing code, and that managing shouldn’t take more than an hour or two per day. They then proceeded to book me into 20-25 hours of recurring meetings every week. That company had major problems for other reasons and it didn’t work out, but after that I always made a point to explicitly ask about manager expectations multiple times during an interview. Different companies have wildly different ideas about what engineering managers should do.
- P_I_Staker 4y ago
  Wow, that's an insane request for a director. Even at the management level, unless you have a specific, obvious "dual role", this borders on inappropriate. The company in the first case was the closest to correct. If you really weren't sacrificing your commitments, then they're being unreasonable, but I can say I understand their perspective. So many engineers move to management, yet want to remain "hands on", and won't let go. It's obnoxious and frustrating, when they inevitably have their heads spinning from meeting after meeting, and no time remaining, but still insist on trying to help. Simply looking at code output and calling it a problem to produce too much is hilariously shortsighted, but I can see how someone with some bad experiences could trend in that direction.

jeffrallen 4y ago

> Your job is to look A really dramatic way of learning this is to be a volunteer firefighter. After a couple of years of experience where you know all the roles, they have you try out incident commander in an exercise. Now your job is to keep your head up, your eyes open, your hands off the equipment and manage your team. And you fail and fail again until you finally understand the role of a tactical commander (line manager).

ChuckMcM 4y ago
I really love that example. Thanks for sharing it.
bluGill 4y ago
The problem is you can do any single job better than the people under you, but by doing any job you can't keep track of anything else and so all the other jobs you are not touching get worse by more than the one you do.gets better.

kevin_nisbet 4y ago

I learned a similar lesson outside of tech... with low wage employees. Often people would have problems dealing with our employee's and complain, but if we dug a bit deeper, it was very often an issue with training, manuals, high turnover, or managers not being good at setting expectations.

scruple 4y ago
> managers not being good at setting expectations Expectation setting (and all of the things that fall out of it) is such a huge problem in my experience. I'm always trying to get clear expectations out of management. I had a ~decade gap in my career where the expectations were vague, ambiguous, bullshit... And worst of all misaligned. First-time engineering managers, specifically, were all so bad at this. I've walked from jobs where this was the root problem. Recently, I've landed in a company and on a team where the expectations are crystal clear and, as a result, and closing in on 20 years in this industry, I feel like I am able to do some of my best, most impactful work. Work that will likely outlive my tenure with this organization, and it feels fucking amazing!
- steveBK123 4y ago
  New managers (or bad ones) have a hard time serving the basic functions of - filtering incoming noise, making priority decisions, and allowing some room for ICs to breathe. The last one - allowing ICs to breathe is extremely important. Most of my best / most impactful / bragged-by-others work was completely unplanned/unscoped/side project kind of stuff where I saw a recurring problem that could be addressed. Most of these were really like 1-2 days of focused work to get to 80%, then when management saw what it got them.. periodic planned/scoped/in-sprint tasks for improvements. New/bad managers often have a hard time not planning their ICs time down to the minute.

jdwithit 4y ago

The cross training point is absolutely crucial. I've managed or worked on multiple Ops teams where one person was the "network expert" or the "kubernetes expert" or whatever. If that person left the company for any reason, or even went on vacation, it was a disaster. People on a team can and should have their specialties but you absolutely must document and cross train so that someone can fill in when the expert is unavailable. Anything else is a horrible failure by management.

mschuster91 4y ago
> I've managed or worked on multiple Ops teams where one person was the "network expert" or the "kubernetes expert" or whatever. If that person left the company for any reason, or even went on vacation, it was a disaster. The problem is in almost all of these cases the workload doesn't match the financial capacity. Basically, there is an absurd lot of stuff you have to know for each of these fields, which is why domain experts develop in the first place - it's just too much to handle for a generalist unless you happen to run into a person on the autism spectrum with eidetic memory (these are rare and worth their weight in gold). So, assuming at least basic levels of redundancy, you'll need at least two people of each specialty (at least network, storage, virtualization/cloud, Linux, k8s, AD, macOS, Windows) in a company that has IT needs beyond "they're shuffling papers and emails". That's 16 people, but many organizations don't have enough work to justify employing that many people. Most end up with going the "hire a generalist or two and have them do everything", which can work for an incredibly long time but then it collapses in a dumpsterfire (the generalist calls it quits and no sane potential new hire wants that workload for that paycheck, the company gets hacked because the generalist only has rough concepts about client-side IT security, ...). Some end up with outsourcing their IT, either to some local company or to body farms from India. That usually has better capacity to account for vacations, sick days and whatnot, but comes at the price that you don't have someone you can call for a quick firewall change but have to wait days or weeks for the ticket to make its way around, leading to frustration and eventually attrition from the non-IT staff. And a very select few end up hiring a bunch of specialists, which produce very good quality and high amounts of internal satisfaction... but as these few companies usually do that because the CIO pushes for it, some day when the CEO wants to count beans and the CIO can't defend the effort ("preparedness paradoxon"), the department gets slashed, and they end up like the first sort.

scrapheap 4y ago

> who is working late nights, who isn't Add to this who starts work early and who doesn't - just tracking when someone finishes working doesn't give you any information without knowing how long they've actually been working for when they leave.

ajmurmann 4y ago
This! I've had to step up for folks in the past who were perceived by someone as "phoning it in" by calling out that the person frequently shows up before 6am

coldtea 4y ago

>And I tell them, your job is to look. Look at your team, who is working late nights, who isn't. Sounds like a toxic environment...

ianmcgowan 4y ago
From context (and a charitable reading), it seems obvious that the advice is to identify who is working nights in order to get them some help and spread the load.

ghaff 4y ago

And, of course, there are people working for that manager who don't think they are doing anything and that middle managers are a waste of oxygen--even though, in fact, they're shielding their team from a lot of crap and, as you suggest, they're doing a lot of coordination of a situation that would otherwise end up with a lot of wasted motion.

steveBK123 4y ago
I think the challenge is that ICs get "outed" pretty quickly if they underperform. Managers can be more at the whim of whether they have a good team or bad. A bad manager with a good team can take a long time to get "outed" while a good manager with a bad team might get whacked anyway. Upper Management doesn't really know how to measure the effectiveness of line managers. So it can make tech senior ICs pretty cynical about their management, especially if you are in a role as I often am where I am directly engaged by clients (directly receiving new requests), planning sprints, sizing tasks, planning roadmpaps, in hours of meetings per day, etc. At some point you wonder if your line manager is just an empty suit.

PragmaticPulp 4y ago

> New managers who had been engineers before management and care about the work always tell me "I feel like I'm not doing anything, I should be helping or something." Your points about managing (interfacing with the company, translating company’s demands into a reasonable, steady stream of work) are spot on, but I would also note that the expectations for engineering managers are all over the place right now. In my first engineering management job I was severely chastised for writing too much code, even though I had the time and was choosing non-critical tickets for myself. The company insisted that managers should manage/delegate and developers should develop with little to no overlap. I internalized this as the way management was meant to be. Later in my career I took another management role and followed the pure delegation strategy. I was later chastised for not writing enough code. They believed managers should only need to spend about half their time managing and the rest should be spent doing IC work. They never communicated this, but assumed it was just how managers knew they were supposed to operate. Even later in my career I took a “director” role, which was appropriate for my career progression to that point. I was stunned when the VP I reported to informed me that I needed to be spending “at least 2/3” of my time writing code, and that managing shouldn’t take more than an hour or two per day. They then proceeded to book me into 20-25 hours of recurring meetings every week. That company had major problems for other reasons and it didn’t work out, but after that I always made a point to explicitly ask about manager expectations multiple times during an interview. Different companies have wildly different ideas about what engineering managers should do.

P_I_Staker 4y ago
Wow, that's an insane request for a director. Even at the management level, unless you have a specific, obvious "dual role", this borders on inappropriate. The company in the first case was the closest to correct. If you really weren't sacrificing your commitments, then they're being unreasonable, but I can say I understand their perspective. So many engineers move to management, yet want to remain "hands on", and won't let go. It's obnoxious and frustrating, when they inevitably have their heads spinning from meeting after meeting, and no time remaining, but still insist on trying to help. Simply looking at code output and calling it a problem to produce too much is hilariously shortsighted, but I can see how someone with some bad experiences could trend in that direction.