7 ms·

With modern team structures it’s difficult to have ownership all the way to prod. My team consists of: one product manager, one staff engineer, one or more lead

by dakiol 2y ago

With modern team structures it’s difficult to have ownership all the way to prod. My team consists of: one product manager, one staff engineer, one or more lead engineers, one or more senior engineers, one engineering manager. The PM wants his share of the cake, so any big feature needs to go through his approval (“does this feature delivers value?”, “how many users will use the feature?”, etc.) The staff engineer needs to validate any design (that’s his job), and provide feedback if he thinks your design “sucks”. So if the feature ends up being successful, he gets points. The senior and lead engineers need to own the design and implementation details. The leads would probably want to cover a good chunk of the solution so that it appears in their performance review. It’s gonna be though for senior engineers to get a good share if the leads are already one step ahead. The engineering manager will own the timeline. He will ask you about estimates, but most likely you’ll feel the pressure of whatever imaginary deadline is set. So there you are in the middle of all those people wanting their share. If you don’t manage to own a good chunk of that work, you won’t be able to show it in your perf. review. Owning is hard. I have to say, though, that I only have experienced this in tech companies that are around 5-7 years (old enough to have well established processes, young enough to still hire like there’s no tomorrow) and that are obsessed with FAANGs: they will hire faang engineers only if they could. This mix ends up badly, because suddenly every team needs to be a high performing team, everyone is raising the bar and speed is number one prio. When working with companies that hire no faang engineers, everything feels better.

bibabaloo 2y ago
I feel this so much. I feel like most of my job is playing politics to make sure people are happy and let them feel like they're adding value. Rather than shipping things to users to improve the product. It's honestly so depressing. Strongly considering going back to work at a small startup, to avoid having to work with these layers of middlemen that really add little to no value.
- agumonkey 2y ago
  the one who solves this problem will flood the world with a neverending wave of light.. every day I wonder how come I do so few now that I'm paid compared to when I was jobless and hacking prototypes for $0 finding the recipe for creating goal driven, high speed, high quality, frictionless teams is a difficult quest
  - Micoloth 2y ago
    A difficult quest indeed, but not impossible. Sometimes teams like this do exist. You know the ones. They founded the trillion-dollar companies you hear about and became billionaires themselves
    - Vilian 2y ago
      Nah, it's usually luck and robbing someone else work, windows apple Facebook etc
      - bryanrasmussen 2y ago
        I'm going to say it is efficiency and the ability to implement ideas well, even if they are stolen ideas, that account for more of the success for anything else. I also bet they did come up with some small things here and there themselves, in the process of implementing stolen ideas, because often things become apparent at the moment of implementation.
        agumonkey 2y ago
        yeah there's always something a bit special in success, even if they took the idea, you can't just copy paste or you just produce shallow shiny stuff
  - travisgriggs 2y ago
    Lobby your government to tax management hours. That’ll fix things. I often wonder how some open source projects manage to be so successful/productive with so little of what looks like corporate management.
    - pineaux 2y ago
      How would you implement this though? Wouldn't things just be renamed?
  - Aeolun 2y ago
- motorest 2y ago
  > I feel this so much. I feel like most of my job is playing politics to make sure people are happy and let them feel like they're adding value. Rather than shipping things to users to improve the product. Why do you feel your way of shipping things to users to improve the product is something that makes your team members unhappy and not able to add value?
  - rizky05 2y ago
    [dead]
- sensanaty 2y ago
  I remember in a prior job that I had just joined when I was still new to the field, they had a bug board where they collected all the most common bugs users were experiencing. I decided to, in the middle of the sprint when I was done with the sprint work and had some small downtime, take care of some of the smaller bugs that were easy to fixup in a day's notice. My PM at the time immediately questioned why I'm working on "irrelevant" tickets and not focusing on the wider project we were working on, the senior I was working under had the same stance, and the PR never ended up being merged. It was like 20 lines of very easy to comprehend code that was fixing one of the most reported bugs our users had, like 6 figure number of reports since the bug card was created. When I left that company a year and a half later, that bug card was still open, with my now-rotting PR sitting there with a "closed" status. It really jaded me on all of these bullshit processes, sprints, AGILE, whatever you want to call it. It was obvious that nobody gave a shit about what we were building and how, it's all just a game to pad yourself up and to look good to the higher ups who control if you get a raise or not. If someone above you can't somehow gain a lot by boasting about the work done, then you might as well not do it. I fucking despise the mindset and how prevalent it is in the industry.
  - seadan83 2y ago
    I feel this. The zero-sum pendulum of time is a bitch. I wonder, are you under 35? This story reminds me of my experience. When I was younger, all the problems could be solved - all at once. I'd throw time at just about everything - cleaner code, fewer bugs, features delivered. Later, the scope of what I was working on grew. No amount of time could be thrown at all the problems - it was zero sum. I had mentors try to guide me, to focus on solving what you need to, to focus on areas of impact and let the other things slide. If you don't, then the areas of impact never get done. On the other side of the coin, the really frustrating part - is the bullshit processes you speak of. Time is zero sum. Yet, here was the team wasting time on another status meeting and time estimation; not getting the things done. Small quick wins, which do have impact, are not small quick wins because - did you fill out the TPS report regarding user impact? Did that get approval and story pointing? Is it a strategic initiative? No, then why are you working on it? Those are unhealthy orgs. Places like that I think are filled with folks that can't do the job and ride the coat tails of those that get shit done. These are also places where people want to go, clock in, and just not think that hard about their job - just do it and get home to their families. Though, I've come to also appreciate that mentality too. I've never been a true owner at any place I've worked at. I've cared, I've been tricked into caring - but the long hours only went to enriching the person that had 1M shares, while I had just 2000. They were an owner, I was pawn.
spuds 2y ago
Yeah I completely agree that a lot of structures work actively against this. Lot easier for me to write a bullet point about it than actually implement it at a company with an existing way of doing things. And I think it's almost impossible to implement from the bottom up, as it often requires some real process (and culture) changes.
Dansvidania 2y ago
this really must be common. I myself could have written a similar (less well put) summary of my last two jobs.
worksonmymach 2y ago
It needs a culture change. The magic words: "Our customers prefer the product works over getting a new feature, so let's ensure that at any cost" Number of features is a dial. You turn that down. You turn the operations (devops) dial up. There is nothing modern about releasing half arsed shit... we been doing it since the dawn of civilization.
- bjornsing 2y ago
  I agree. First step I think is to start measuring what’s important at the top of the organization. When you have weekly progress meetings with the CTO and CPO and only look at lists of new features, then new features will be what people think about. “What gets measured gets done”, as they say.
- motorest 2y ago
  > "Our customers prefer the product works over getting a new feature, so let's ensure that at any cost" Do they, though? If a competitor launches a feature that all your customers want and start to switch to benefit from it, what are you going to do? Show burn-down charts of your bug backlog?
  - worksonmymach 2y ago
    > If a competitor launches a feature that all your customers want and start to switch to benefit from it, what are you going to do? I would say this is not that common in SaaS. In that features are important but PMF is key. A feature that drags people over is really a new product. I can't think of an example of the bolt-on killer feature. And by the time you are big enough to run multiple distinct products youd better have good uptime. If you are a startup of course you need features but again finding PMF so you ain't worried about competitors. As a startup you are choosing boring tech and maybe a PaaS to help you do less productioning. Notice the popularity of k8s, splunk, CI/CD, testing, multi region and so on? Yeah there is big money in being available.
    - motorest 2y ago
motorest 2y ago
> The PM wants his share of the cake, so any big feature needs to go through his approval (“does this feature delivers value?”, “how many users will use the feature?”, etc.) That's literally the Product Manager's job. That's why your employer felt the need to pay a hefty salary to have that role played by a single person whose man responsibility is being held accountable for features being delivered. I mean, do you expect on releasing features in a product without the Product Manager's say? That makes as much sense as the PM expecting to single-handedly pushing software architecture changes without consulting with staff and senior engineers. > So there you are in the middle of all those people wanting their share. If you don’t manage to own a good chunk of that work, you won’t be able to show it in your perf. review. Owning is hard. Isn't this concern shared by everyone in your example?
Kinrany 2y ago
This sounds like the team is straightforwardly too big for the task. Especially the EM and the staff, lead and senior engineers all wanting the same one thing of a certain scope when they should be working at two different levels at a minimum
mihaaly 2y ago
> 'modern team structures' This kind of argumentation somehow never settles with me and blocks me from reading on. 'modern', 'new', 'trendy', 'state of the art', 'industry practice' and alike all resonate with 'I do not know so I mimic how others do' in my mind. Weird, but do. Are 'modern' team structures a desirable reference? How about saying 'today's problematic team formations'? I'll try to understand so and read on. --- Edit: it turns out we are on the same page, I jumped at ghost.
safety1st 2y ago
If you were the benevolent dictator of a small engineering with no stakeholders to answer to how would you fix this? How would you make ownership all the way to prod a reality and who would the owner be?
- julik 2y ago
  There should not necessarily be an owner, but a responsible individual - which would then be "you", the benevolent dictator. Ownership "in and of itself" creates incentives to gatekeep.
  - safety1st 2y ago
    Why did I hire these people if I cannot delegate responsibility to them?
- munksbeer 2y ago
  We have this. It's a culture thing. It's not actually possible to force someone to own something till production, but we encourage it and most people follow that. One of the keys though, is a very easy process from development to code being in production. The more obstacles you put in the way, the less inspired a developer is to own the whole thing. Not everyone is great at this, and people get frustrated when others don't own their stuff, but typically things are cordial and encouraging, rather than aggressive. But we're still a relatively small place (150 staff, about 40 developers), and inevitably, and sadly, this will change.
  - Cpoll 2y ago
    > t's not actually possible to force someone to own something till production Only in the same way that it's not possible to force someone to complete their work? Put their name on the ticket and clearly communicate what it means to "own" a ticket (an oft-missed step). It's just another task, like writing the ticket, testing the ticket, doing security review, etc.
julik 2y ago
This is what makes creating these performing structures so hard - once the incentives to "show ownership to demonstrate performance and get promoted" is permitted in the organization, people have to "play to stay at the table" and the actual necessary work ethic gets displaced. There should be a clear realisation that creating a moral maze is a taboo, and it is very hard for leaders to stick to that throughout the growth of an org.
HL33tibCe7 2y ago
> one staff engineer, one or more lead engineers An engineer isn't really a "lead" if there are multiple, or if they are outranked by a "staff engineer".
ariosto 2y ago
Interesting how you described the scenario quite accurately that is currently playing out and the current tech company of 5-8 years I am at.

by dakiol 2y ago

bibabaloo 2y ago

I feel this so much. I feel like most of my job is playing politics to make sure people are happy and let them feel like they're adding value. Rather than shipping things to users to improve the product. It's honestly so depressing. Strongly considering going back to work at a small startup, to avoid having to work with these layers of middlemen that really add little to no value.

agumonkey 2y ago
the one who solves this problem will flood the world with a neverending wave of light.. every day I wonder how come I do so few now that I'm paid compared to when I was jobless and hacking prototypes for $0 finding the recipe for creating goal driven, high speed, high quality, frictionless teams is a difficult quest
- Micoloth 2y ago
  A difficult quest indeed, but not impossible. Sometimes teams like this do exist. You know the ones. They founded the trillion-dollar companies you hear about and became billionaires themselves
  - Vilian 2y ago
    Nah, it's usually luck and robbing someone else work, windows apple Facebook etc
    - bryanrasmussen 2y ago
      I'm going to say it is efficiency and the ability to implement ideas well, even if they are stolen ideas, that account for more of the success for anything else. I also bet they did come up with some small things here and there themselves, in the process of implementing stolen ideas, because often things become apparent at the moment of implementation.
      - agumonkey 2y ago
        yeah there's always something a bit special in success, even if they took the idea, you can't just copy paste or you just produce shallow shiny stuff
- travisgriggs 2y ago
  Lobby your government to tax management hours. That’ll fix things. I often wonder how some open source projects manage to be so successful/productive with so little of what looks like corporate management.
  - pineaux 2y ago
    How would you implement this though? Wouldn't things just be renamed?
- Aeolun 2y ago
motorest 2y ago
> I feel this so much. I feel like most of my job is playing politics to make sure people are happy and let them feel like they're adding value. Rather than shipping things to users to improve the product. Why do you feel your way of shipping things to users to improve the product is something that makes your team members unhappy and not able to add value?
- rizky05 2y ago
  [dead]
sensanaty 2y ago
I remember in a prior job that I had just joined when I was still new to the field, they had a bug board where they collected all the most common bugs users were experiencing. I decided to, in the middle of the sprint when I was done with the sprint work and had some small downtime, take care of some of the smaller bugs that were easy to fixup in a day's notice. My PM at the time immediately questioned why I'm working on "irrelevant" tickets and not focusing on the wider project we were working on, the senior I was working under had the same stance, and the PR never ended up being merged. It was like 20 lines of very easy to comprehend code that was fixing one of the most reported bugs our users had, like 6 figure number of reports since the bug card was created. When I left that company a year and a half later, that bug card was still open, with my now-rotting PR sitting there with a "closed" status. It really jaded me on all of these bullshit processes, sprints, AGILE, whatever you want to call it. It was obvious that nobody gave a shit about what we were building and how, it's all just a game to pad yourself up and to look good to the higher ups who control if you get a raise or not. If someone above you can't somehow gain a lot by boasting about the work done, then you might as well not do it. I fucking despise the mindset and how prevalent it is in the industry.
- seadan83 2y ago
  I feel this. The zero-sum pendulum of time is a bitch. I wonder, are you under 35? This story reminds me of my experience. When I was younger, all the problems could be solved - all at once. I'd throw time at just about everything - cleaner code, fewer bugs, features delivered. Later, the scope of what I was working on grew. No amount of time could be thrown at all the problems - it was zero sum. I had mentors try to guide me, to focus on solving what you need to, to focus on areas of impact and let the other things slide. If you don't, then the areas of impact never get done. On the other side of the coin, the really frustrating part - is the bullshit processes you speak of. Time is zero sum. Yet, here was the team wasting time on another status meeting and time estimation; not getting the things done. Small quick wins, which do have impact, are not small quick wins because - did you fill out the TPS report regarding user impact? Did that get approval and story pointing? Is it a strategic initiative? No, then why are you working on it? Those are unhealthy orgs. Places like that I think are filled with folks that can't do the job and ride the coat tails of those that get shit done. These are also places where people want to go, clock in, and just not think that hard about their job - just do it and get home to their families. Though, I've come to also appreciate that mentality too. I've never been a true owner at any place I've worked at. I've cared, I've been tricked into caring - but the long hours only went to enriching the person that had 1M shares, while I had just 2000. They were an owner, I was pawn.

spuds 2y ago

Yeah I completely agree that a lot of structures work actively against this. Lot easier for me to write a bullet point about it than actually implement it at a company with an existing way of doing things. And I think it's almost impossible to implement from the bottom up, as it often requires some real process (and culture) changes.

Dansvidania 2y ago

this really must be common. I myself could have written a similar (less well put) summary of my last two jobs.

worksonmymach 2y ago

It needs a culture change. The magic words: "Our customers prefer the product works over getting a new feature, so let's ensure that at any cost" Number of features is a dial. You turn that down. You turn the operations (devops) dial up. There is nothing modern about releasing half arsed shit... we been doing it since the dawn of civilization.

bjornsing 2y ago
I agree. First step I think is to start measuring what’s important at the top of the organization. When you have weekly progress meetings with the CTO and CPO and only look at lists of new features, then new features will be what people think about. “What gets measured gets done”, as they say.
motorest 2y ago
> "Our customers prefer the product works over getting a new feature, so let's ensure that at any cost" Do they, though? If a competitor launches a feature that all your customers want and start to switch to benefit from it, what are you going to do? Show burn-down charts of your bug backlog?
- worksonmymach 2y ago
  > If a competitor launches a feature that all your customers want and start to switch to benefit from it, what are you going to do? I would say this is not that common in SaaS. In that features are important but PMF is key. A feature that drags people over is really a new product. I can't think of an example of the bolt-on killer feature. And by the time you are big enough to run multiple distinct products youd better have good uptime. If you are a startup of course you need features but again finding PMF so you ain't worried about competitors. As a startup you are choosing boring tech and maybe a PaaS to help you do less productioning. Notice the popularity of k8s, splunk, CI/CD, testing, multi region and so on? Yeah there is big money in being available.
  - motorest 2y ago

motorest 2y ago

> The PM wants his share of the cake, so any big feature needs to go through his approval (“does this feature delivers value?”, “how many users will use the feature?”, etc.) That's literally the Product Manager's job. That's why your employer felt the need to pay a hefty salary to have that role played by a single person whose man responsibility is being held accountable for features being delivered. I mean, do you expect on releasing features in a product without the Product Manager's say? That makes as much sense as the PM expecting to single-handedly pushing software architecture changes without consulting with staff and senior engineers. > So there you are in the middle of all those people wanting their share. If you don’t manage to own a good chunk of that work, you won’t be able to show it in your perf. review. Owning is hard. Isn't this concern shared by everyone in your example?

Kinrany 2y ago

This sounds like the team is straightforwardly too big for the task. Especially the EM and the staff, lead and senior engineers all wanting the same one thing of a certain scope when they should be working at two different levels at a minimum

mihaaly 2y ago

> 'modern team structures' This kind of argumentation somehow never settles with me and blocks me from reading on. 'modern', 'new', 'trendy', 'state of the art', 'industry practice' and alike all resonate with 'I do not know so I mimic how others do' in my mind. Weird, but do. Are 'modern' team structures a desirable reference? How about saying 'today's problematic team formations'? I'll try to understand so and read on. --- Edit: it turns out we are on the same page, I jumped at ghost.

safety1st 2y ago

If you were the benevolent dictator of a small engineering with no stakeholders to answer to how would you fix this? How would you make ownership all the way to prod a reality and who would the owner be?

julik 2y ago
There should not necessarily be an owner, but a responsible individual - which would then be "you", the benevolent dictator. Ownership "in and of itself" creates incentives to gatekeep.
- safety1st 2y ago
  Why did I hire these people if I cannot delegate responsibility to them?
munksbeer 2y ago
We have this. It's a culture thing. It's not actually possible to force someone to own something till production, but we encourage it and most people follow that. One of the keys though, is a very easy process from development to code being in production. The more obstacles you put in the way, the less inspired a developer is to own the whole thing. Not everyone is great at this, and people get frustrated when others don't own their stuff, but typically things are cordial and encouraging, rather than aggressive. But we're still a relatively small place (150 staff, about 40 developers), and inevitably, and sadly, this will change.
- Cpoll 2y ago
  > t's not actually possible to force someone to own something till production Only in the same way that it's not possible to force someone to complete their work? Put their name on the ticket and clearly communicate what it means to "own" a ticket (an oft-missed step). It's just another task, like writing the ticket, testing the ticket, doing security review, etc.

julik 2y ago

This is what makes creating these performing structures so hard - once the incentives to "show ownership to demonstrate performance and get promoted" is permitted in the organization, people have to "play to stay at the table" and the actual necessary work ethic gets displaced. There should be a clear realisation that creating a moral maze is a taboo, and it is very hard for leaders to stick to that throughout the growth of an org.

HL33tibCe7 2y ago

> one staff engineer, one or more lead engineers An engineer isn't really a "lead" if there are multiple, or if they are outranked by a "staff engineer".

ariosto 2y ago

Interesting how you described the scenario quite accurately that is currently playing out and the current tech company of 5-8 years I am at.