7 ms·

First-level manager here. That’s after a very-long (nearly three decade) career as an IC in “big tech”. I think my take on this is not surprisingly different

First-level manager here. That’s after a very-long (nearly three decade) career as an IC in “big tech”. I think my take on this is not surprisingly different than yours. As a first-level manager my job is all about execution and getting things done. Being in 20+ hours of meetings a week gives me a lot more perspective on the big picture than the ICs on my team. They often think certain work is important because they have a very myopic view of what we do. I am always looking for the ICs to drive our work, and expect the more senior people to come to the table with ideas. Sometimes those ideas are great, and they have a low-level perspective that I am missing because my nose isn’t in the code as much as it once was (it still is, and I still commit code, but it’s opportunistic and not that frequent). But often they get stuck on fixing whatever the most recent thing that bothered them about our code rather than on what actually impacts customers in the long or short term. There is a lot of management above first-level that doesn’t seem to add a lot of value, but I’m not sure how much of that is inherent versus the specifics of who is in those roles. I expect my manager to be focused on strategy, long-term direction, team composition, building relationships with other orgs, etc. Up a level from that, again an even broader perspective. Depending on who is filling those roles I may or may not see those behaviors. It’s very common and convenient to focus on personal productivity as an IC, but if 25% or 50% or 90% of that effort is going towards things that ultimately don’t have impact for customers, it’s not very productive after all.

andrei_says_ 4y ago
If I’m reading this correctly, you’re saying that there needs to be someone on a higher level to ensure that the correct work gets done. How do you balance the additional work needed to provide the necessary transparency to this decision-maker? Providing this additional reporting often becomes an unreasonably (I think) large part of the job, creates friction, and unexpected changes of direction interrupt flow. As a manager with experience and sensibility for both the importance of doing the right thing and productivity, satisfaction and flow - what are some ways you lower the cost of managing?
- IMTDb 4y ago
  One way to lower the cost of managing is to promote transparency within the organisation: allow and encourage manager to read the PR and the discussion around them, this will give them some sense of the progress of the projects. Provide KPI/OKR about the state of the company on a very regular basis, allow and encourage IC to take a look at them. Announce good and bad news on dedicated channels, allow and encourage employees to read them. Because information is freely accessible, there is less need for dedicated "reporting" processes every time a manager is added into the system.
  - presentation 4y ago
    Agreed for small companies in certain business contexts, but just “reading through the PRs” doesn’t scale or may not be that valuable to decision makers at different levels of the hierarchy, and not all ICs want to be involved in the decision making. I don’t think there’s a one size fits all option besides having smart people who know what they’re talking about and not going too heavy on process and hierarchy too fast.
- Haga 4y ago
  [dead]
- zingar 4y ago
  Spectacular question, thank you. I’ve had this concept rattling around in my head but not had the words. Cost of managing is really succinct.
pm90 4y ago
> As a first-level manager my job is all about execution and getting things done. Being in 20+ hours of meetings a week gives me a lot more perspective on the big picture than the ICs on my team. > They often think certain work is important because they have a very myopic view of what we do. I am always looking for the ICs to drive our work, and expect the more senior people to come to the table with ideas. Sometimes those ideas are great, and they have a low-level perspective that I am missing because my nose isn’t in the code as much as it once was (it still is, and I still commit code, but it’s opportunistic and not that frequent). But often they get stuck on fixing whatever the most recent thing that bothered them about our code rather than on what actually impacts customers in the long or short term. I would love to hear your perspective (or pointers to other resources that might explain this better) on how one can effectively communicate this kinda of context with ICs. I've worked with managers who have been from "fully transparent about org dynamics" to "Ill shield you from shit (i.e. politics)". Personally, I prefer the former approach as an IC since I respect honesty and the truth, so e.g. if its a political decision I can simply stop trying to push for another direction. However, I understand that this kind of radical transparency might come at a cost and might only work with certain kinds of ICs.
- taneq 4y ago
  There’s “shield you from shit” as in “don’t let upper management abuse you” and then there’s “treat you like a mushroom.” Some managers conflate the two.
  - thunkshift1 4y ago
    Mushrooms translated - “keep them in the dark, feed them shit, watch them grow”
  - brazzledazzle 4y ago
    Some managers don't conflate them and straight up use it as an excuse to keep you in the dark.
    - taneq 4y ago
zug_zug 4y ago
Well it's my experience that managers almost never think about the product or the customer, and almost never feel the need to justify their focus to the engineers who are (at least sometimes) thinking about the product and the customer. I've never once had a manager say anything along the lines of "I just think we're building a bad experience if we release this early." I have heard them say all sorts of politics like "If we get this out now, then that'll prove massive impact that will free us up politically down the line" Or for example I worked at a known location-sharing startup, and managers gave 0% thought to concerns like "hey is battery life impact worth measuring?" and kept pushing random integrations (like with Italian telecom company) hoping to get some huge amount of customers (which never payed off in my experience). When I picture managers and directors I think of the idiots at Yahoo managing to fail to understand I need more than 15megs of storage or a spam filter (can't imagine what those managers were wasting their time ona), while a company of mostly engineers with scarcely any management builds gmail and eats their whole market.
- karmelapple 4y ago
  > I've never once had a manager say anything along the lines of "I just think we're building a bad experience if we release this early." Then perhaps you had less-than-great managers, and I could think of a variety of reasons for that. Maybe it was as simple as you claim: no consideration was made to introducing an undercooked user experience. But if a software development manager is green lighting that, likely causing more work for customer service and perhaps sales, I would hope there’s more to the story than that. Maybe this manager didn’t communicate why releasing a bad experience by a specific date was, perhaps, mandatory to fulfill a contractual obligation. Or maybe you were not able to sort that out from the limited amount of information they gave you. Maybe they didn’t see the bad UX as truly as bad as you, and perhaps your team, thought it was. Maybe where you thought the feature’s UX passed the 80/20 rule was different than many customers. I’ve had (product and project, not as often people) managers who have pushed to hold on delivering a half-baked implementation. And I’ve been a manager who has done that. Those better managers exist Did you ever get feedback or do something to reevaluate why the bad experience was shipped? The experiences you describe do sound like clueless folks making calls, but know that there are folks in management positions not just wildly flailing about.
deleted 4y ago
[deleted]
raincom 4y ago
What your comment, in other words, boils down to this: managers, directors, VPs, etc, just build their empires by hiring more and people. That's why it is possible that "25% or 50% or 90% of that effort [personal productivity] is going towards things that ultimately don’t have impact for customers, it’s not very productive after all." Maybe, time to trim the fat from the top: get rid of these empires by downsizing. Also, companies at very high level should look at the bad effects of empire building, which happens in every large organization. Now one can ask "who gonna bell the cat"? If executive vice presidents start empire building, who gonna stop that? After all, CEO should give free reigns to his underling EVPs. Maybe, the majority stock holders should bell that cat; however, they have delegated that to the board of directors, who are different set of cats.
- zingar 4y ago
  Could you clarify what you mean by the expression “bell the cat”?
  - subharmonicon 4y ago
    https://en.m.wikipedia.org/wiki/Belling_the_Cat https://en.m.wikipedia.org/wiki/Belling_the_Cat
  - bstpierre 4y ago
    https://en.wikipedia.org/wiki/Belling_the_Cat https://en.wikipedia.org/wiki/Belling_the_Cat The mice have a solution for the murderous cat: simply put a bell on the cat’s collar and then they will know when it’s coming. But… who’s going to “bell the cat”? i.e. who is going to perform this unpleasant and possibly fatal job?
- subharmonicon 4y ago
  > What your comment, in other words, boils down to this: managers, directors, VPs, etc, just build their empires by hiring more and people. No, my comment doesn't boil down to that. It boils down to many (not all) ICs, especially ones without a lot of experience, are more interested in focusing on problems that interest them than actual issues that customers want solved. So they go off and start working on interesting problems rather than important ones.
moralestapia 4y ago
>Being in 20+ hours of meetings a week LOL, my current team does 2 hours of meetings per week (at most!) and we are incredibly productive. I hope we never work together!
- subharmonicon 4y ago
  ICs on my team have 1-3 hours a week of meetings. I have 20+ hours because I work cross-functionally across a huge company that is both designing hardware and writing software for it. The complexity of what we build and ship is many times that of anything I've worked on during most of my career. As a result, there are a large number of moving parts and a lot of coordination that needs to happen across teams.
  - moralestapia 4y ago
    I guess no one size fits all, but here is not 2 hours per IC, its two hours total with all ICs involved. We have a very async nature and mostly keep track of each other through tools, so maybe that helps. I'm sure that 90% of the current team would quit if we suddenly had to attend 10X more meetings per week :P.
phkahler 4y ago
>> But often they get stuck on fixing whatever the most recent thing that bothered them about our code rather than on what actually impacts customers in the long or short term. One company had a homegrown debug protocol and tool to interface with it. I needed to add some custom info screens for development, but it was very hard to add because the code was $h!t. So I started fixing it just to be able to add my new data. Not only was I told that Work should be "managed" and prioritized, it was later discarded even though I had done it. When programmers do things to "make the code better", it may not have an impact on today's customer demands, but it is meant to make the programmers more efficient in the future. This is stuff that will - by definition - Never be a priority in management's eyes.
- subharmonicon 4y ago
  > This is stuff that will - by definition - Never be a priority in management's eyes. I'm not sure why you think that is "by definition" not a priority. Of course it is if it's impacting being able to do new work that adds value. The question is, is that a priority at the moment it's noticed, or something that should be added to a backlog to be addressed later? If it's a small amount of code clean-up, it's usually easy to squeeze into current work without disruption. We always try to refactor as we go along. If it's "This 3000 lines needs to be redesigned and rewritten", it really amounts to feature work and should be added to a backlog and prioritized along with all the other work. The phenomenon I'm talking about is ICs seeing something for the first time, and then deciding that must be the priority because it's so bad, and dropping everything else to fix that thing even if it's weeks worth of work. They see what's in front of them as the thing that's most important.
  - phkahler 4y ago
    >> The phenomenon I'm talking about is ICs seeing something for the first time, and then deciding that must be the priority because it's so bad, and dropping everything else to fix that thing even if it's weeks worth of work. They see what's in front of them as the thing that's most important. Sometimes that new person is wrong, buy often there is truth in their assessment. If they're right that they've walked onto a bunch of garbage then their desire to fix it immediately is IMHO the correct thing to do with the exception of making critical (meaning contractual) deadlines for a customer. The time to fix a disaster is when someone has that intrinsic motivation to do it.
Salgat 4y ago
What you're describing is a role fulfilled by a product manager, rather than a traditional people manager.
dekleinewolf 4y ago
Completely agree. A managers task isn't so much to make sure 'more work gets done'. They are there to make sure 'the right work gets done'. And that the right people are there (and stay there), that the right tools are there (which does increase efficiency), that no work gets left behind, etcetera, etcetera.

andrei_says_ 4y ago

If I’m reading this correctly, you’re saying that there needs to be someone on a higher level to ensure that the correct work gets done. How do you balance the additional work needed to provide the necessary transparency to this decision-maker? Providing this additional reporting often becomes an unreasonably (I think) large part of the job, creates friction, and unexpected changes of direction interrupt flow. As a manager with experience and sensibility for both the importance of doing the right thing and productivity, satisfaction and flow - what are some ways you lower the cost of managing?

IMTDb 4y ago
One way to lower the cost of managing is to promote transparency within the organisation: allow and encourage manager to read the PR and the discussion around them, this will give them some sense of the progress of the projects. Provide KPI/OKR about the state of the company on a very regular basis, allow and encourage IC to take a look at them. Announce good and bad news on dedicated channels, allow and encourage employees to read them. Because information is freely accessible, there is less need for dedicated "reporting" processes every time a manager is added into the system.
- presentation 4y ago
  Agreed for small companies in certain business contexts, but just “reading through the PRs” doesn’t scale or may not be that valuable to decision makers at different levels of the hierarchy, and not all ICs want to be involved in the decision making. I don’t think there’s a one size fits all option besides having smart people who know what they’re talking about and not going too heavy on process and hierarchy too fast.
Haga 4y ago
[dead]
zingar 4y ago
Spectacular question, thank you. I’ve had this concept rattling around in my head but not had the words. Cost of managing is really succinct.

pm90 4y ago

> As a first-level manager my job is all about execution and getting things done. Being in 20+ hours of meetings a week gives me a lot more perspective on the big picture than the ICs on my team. > They often think certain work is important because they have a very myopic view of what we do. I am always looking for the ICs to drive our work, and expect the more senior people to come to the table with ideas. Sometimes those ideas are great, and they have a low-level perspective that I am missing because my nose isn’t in the code as much as it once was (it still is, and I still commit code, but it’s opportunistic and not that frequent). But often they get stuck on fixing whatever the most recent thing that bothered them about our code rather than on what actually impacts customers in the long or short term. I would love to hear your perspective (or pointers to other resources that might explain this better) on how one can effectively communicate this kinda of context with ICs. I've worked with managers who have been from "fully transparent about org dynamics" to "Ill shield you from shit (i.e. politics)". Personally, I prefer the former approach as an IC since I respect honesty and the truth, so e.g. if its a political decision I can simply stop trying to push for another direction. However, I understand that this kind of radical transparency might come at a cost and might only work with certain kinds of ICs.

taneq 4y ago
There’s “shield you from shit” as in “don’t let upper management abuse you” and then there’s “treat you like a mushroom.” Some managers conflate the two.
- thunkshift1 4y ago
  Mushrooms translated - “keep them in the dark, feed them shit, watch them grow”
- brazzledazzle 4y ago
  Some managers don't conflate them and straight up use it as an excuse to keep you in the dark.
  - taneq 4y ago

zug_zug 4y ago

Well it's my experience that managers almost never think about the product or the customer, and almost never feel the need to justify their focus to the engineers who are (at least sometimes) thinking about the product and the customer. I've never once had a manager say anything along the lines of "I just think we're building a bad experience if we release this early." I have heard them say all sorts of politics like "If we get this out now, then that'll prove massive impact that will free us up politically down the line" Or for example I worked at a known location-sharing startup, and managers gave 0% thought to concerns like "hey is battery life impact worth measuring?" and kept pushing random integrations (like with Italian telecom company) hoping to get some huge amount of customers (which never payed off in my experience). When I picture managers and directors I think of the idiots at Yahoo managing to fail to understand I need more than 15megs of storage or a spam filter (can't imagine what those managers were wasting their time ona), while a company of mostly engineers with scarcely any management builds gmail and eats their whole market.

karmelapple 4y ago
> I've never once had a manager say anything along the lines of "I just think we're building a bad experience if we release this early." Then perhaps you had less-than-great managers, and I could think of a variety of reasons for that. Maybe it was as simple as you claim: no consideration was made to introducing an undercooked user experience. But if a software development manager is green lighting that, likely causing more work for customer service and perhaps sales, I would hope there’s more to the story than that. Maybe this manager didn’t communicate why releasing a bad experience by a specific date was, perhaps, mandatory to fulfill a contractual obligation. Or maybe you were not able to sort that out from the limited amount of information they gave you. Maybe they didn’t see the bad UX as truly as bad as you, and perhaps your team, thought it was. Maybe where you thought the feature’s UX passed the 80/20 rule was different than many customers. I’ve had (product and project, not as often people) managers who have pushed to hold on delivering a half-baked implementation. And I’ve been a manager who has done that. Those better managers exist Did you ever get feedback or do something to reevaluate why the bad experience was shipped? The experiences you describe do sound like clueless folks making calls, but know that there are folks in management positions not just wildly flailing about.

deleted 4y ago

[deleted]

raincom 4y ago

What your comment, in other words, boils down to this: managers, directors, VPs, etc, just build their empires by hiring more and people. That's why it is possible that "25% or 50% or 90% of that effort [personal productivity] is going towards things that ultimately don’t have impact for customers, it’s not very productive after all." Maybe, time to trim the fat from the top: get rid of these empires by downsizing. Also, companies at very high level should look at the bad effects of empire building, which happens in every large organization. Now one can ask "who gonna bell the cat"? If executive vice presidents start empire building, who gonna stop that? After all, CEO should give free reigns to his underling EVPs. Maybe, the majority stock holders should bell that cat; however, they have delegated that to the board of directors, who are different set of cats.

zingar 4y ago
Could you clarify what you mean by the expression “bell the cat”?
- subharmonicon 4y ago
  https://en.m.wikipedia.org/wiki/Belling_the_Cat https://en.m.wikipedia.org/wiki/Belling_the_Cat
- bstpierre 4y ago
  https://en.wikipedia.org/wiki/Belling_the_Cat https://en.wikipedia.org/wiki/Belling_the_Cat The mice have a solution for the murderous cat: simply put a bell on the cat’s collar and then they will know when it’s coming. But… who’s going to “bell the cat”? i.e. who is going to perform this unpleasant and possibly fatal job?
subharmonicon 4y ago
> What your comment, in other words, boils down to this: managers, directors, VPs, etc, just build their empires by hiring more and people. No, my comment doesn't boil down to that. It boils down to many (not all) ICs, especially ones without a lot of experience, are more interested in focusing on problems that interest them than actual issues that customers want solved. So they go off and start working on interesting problems rather than important ones.

moralestapia 4y ago

>Being in 20+ hours of meetings a week LOL, my current team does 2 hours of meetings per week (at most!) and we are incredibly productive. I hope we never work together!

subharmonicon 4y ago
ICs on my team have 1-3 hours a week of meetings. I have 20+ hours because I work cross-functionally across a huge company that is both designing hardware and writing software for it. The complexity of what we build and ship is many times that of anything I've worked on during most of my career. As a result, there are a large number of moving parts and a lot of coordination that needs to happen across teams.
- moralestapia 4y ago
  I guess no one size fits all, but here is not 2 hours per IC, its two hours total with all ICs involved. We have a very async nature and mostly keep track of each other through tools, so maybe that helps. I'm sure that 90% of the current team would quit if we suddenly had to attend 10X more meetings per week :P.

phkahler 4y ago

>> But often they get stuck on fixing whatever the most recent thing that bothered them about our code rather than on what actually impacts customers in the long or short term. One company had a homegrown debug protocol and tool to interface with it. I needed to add some custom info screens for development, but it was very hard to add because the code was $h!t. So I started fixing it just to be able to add my new data. Not only was I told that Work should be "managed" and prioritized, it was later discarded even though I had done it. When programmers do things to "make the code better", it may not have an impact on today's customer demands, but it is meant to make the programmers more efficient in the future. This is stuff that will - by definition - Never be a priority in management's eyes.

subharmonicon 4y ago
> This is stuff that will - by definition - Never be a priority in management's eyes. I'm not sure why you think that is "by definition" not a priority. Of course it is if it's impacting being able to do new work that adds value. The question is, is that a priority at the moment it's noticed, or something that should be added to a backlog to be addressed later? If it's a small amount of code clean-up, it's usually easy to squeeze into current work without disruption. We always try to refactor as we go along. If it's "This 3000 lines needs to be redesigned and rewritten", it really amounts to feature work and should be added to a backlog and prioritized along with all the other work. The phenomenon I'm talking about is ICs seeing something for the first time, and then deciding that must be the priority because it's so bad, and dropping everything else to fix that thing even if it's weeks worth of work. They see what's in front of them as the thing that's most important.
- phkahler 4y ago
  >> The phenomenon I'm talking about is ICs seeing something for the first time, and then deciding that must be the priority because it's so bad, and dropping everything else to fix that thing even if it's weeks worth of work. They see what's in front of them as the thing that's most important. Sometimes that new person is wrong, buy often there is truth in their assessment. If they're right that they've walked onto a bunch of garbage then their desire to fix it immediately is IMHO the correct thing to do with the exception of making critical (meaning contractual) deadlines for a customer. The time to fix a disaster is when someone has that intrinsic motivation to do it.

Salgat 4y ago

What you're describing is a role fulfilled by a product manager, rather than a traditional people manager.

dekleinewolf 4y ago

Completely agree. A managers task isn't so much to make sure 'more work gets done'. They are there to make sure 'the right work gets done'. And that the right people are there (and stay there), that the right tools are there (which does increase efficiency), that no work gets left behind, etcetera, etcetera.