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.
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.
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.
Healthy orgs must have slack in the system and allow teams and individuals to do a little chasing of fun or meaningful things that give them intrinsic pride and motivation.
Teams must advocate for projects, but, for individuals, one solution that I've seen help is that the week long oncall developer handles sprint interruptions, slack questions, and bugs. No sprint commitments. If something is not on fire, they get to work on whatever they think will add value at their discretion. New tooling, proof of concepts, pet-peeve bugs that can't get prioritized, etc.
After lots of stabilization work, devs looked forward to oncall.
> Healthy orgs must have slack in the system and allow teams and individuals to do a little chasing of fun or meaningful things that give them intrinsic pride and motivation.
As an Engineering leader, I try my hardest to make sure this Slack exists for the exact reasons you listed.
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.
I've worked in mid-sized companies where my job wasn't just one thing, and where I was not owned by a project manager. Other concerns existed. Even back at the ancient bank I worked at, our implementation of ITIL recognised this, and put incident and problem managers on equal footing with project managers. If a frequent issue is caused by some underlying problem, that problem needs to be fixed. Working on it was absolutely legitimate. During sprint planning a team could take work from the new features like or the bugs pile without interference from a project manager. If they complained that you worked on a bug, you could lean on the problem manager to talk to the project manager. If the project manager's timelines drift, part of their job is to deal with that, inform stakeholders and extend the deadlines. If they continually fail to factor in the possibility of conflicting work then they suck at their job. If their boss gives them shit for a slipping deadline that was out of their control, then they also suck. In your example the company allocate 100% of your time to working on new features and none of it to maintaining the product or keeping customers happy. There's no point in putting a brand new engine into a rusty car with bald tyres. This a bad organisation.
> 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?
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.
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.
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
Quality can also become it's own trap as the entire org chases metrics aimed at quality. Soon you have loads of brittle tests that likely aren't adding great assertions but you have code coverage.
Because that doesn't work soon you keep adding layers upon layers to reduce the risk and your time to delivery suffers.
All knobs have consequences and long term they can really compound. The balance of picking quality over features isn't something I've seen done amazing. I'd like to work somewhere that could pull it off.
You are right and the biggest asset here are executives and management that can:
1. Think
2. Know what is going on.
3. Effectively get the best from their people.
You want the whole org to engineer the right solution
Any metric that gets abused needs to be found and replaced. Companies should use metrics and be very respectful, curious and also suspicious of them. Even revenue!
I know companies that leave revenue on the table for strategy.
Finally quality is about probabilities. That test you wrote that takes 12s to run and flakes 0.1% adding 10 hours of build time a year ... what is the probability of it detecting a bug and what would the cost of that bug be. You need every engineer to think of that stuff. It is hard stuff to get right or even good.
I worked at places where a religion almost builds. People are hired to maintain those slow expensive unreliable tests! You want to improve that you now have politics!
How do you build 1 and 2? It seems so simple: talk relentlessly about what you’re trying to do as a company, and then figure out how to assign your people most effectively to do that. I’ve seen a number of leaders figure out the messaging and then flat out fail on execution. Once they’ve worked out the vision, they fail to give middle management enough latitude to accomplish it, and the lack of trust flows downhill.
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.
I have never seen positive impact from turning the devops dial up. Most of the times, we just keep on adding checklist items for quality and engineering practices. Devops keeps pushing things like observability and standardization through complex things like service mesh which creates all of its own problems.
> "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?
> 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.
> A feature that drags people over is really a new product.
But isn't that a post-facto observation? I mean, any project can work on a complex feature that's a flop, but sometimes a simple feature can go a long way and just tilt the scale. That's not a new product.
Not really. This is the fact of real world software development: your resources are limited, and either you invest them creating value for customers so that they choose your product over your competitor's or they choose your competitor's instead.
If you spend your resources on technical debt and clearing bug backlogs even of obscure nonblocking bugs, you're just spending your resources to offer your users more of the same. If you instead use your resources to deliver new features that might have a nonblocking bug here or there, you're improving your position over the competitor's.
Time to market matters. A lot. There is no such thing as time to empty backlog.
> If you instead use your resources to deliver new features that might have a nonblocking bug here or there, you're improving your position over the competitor's.
In the short term. Features can attract new customers but software that is frustrating to use due to a lot of low level bugs will repel existing customers towards competitors over the long term. If you've simultaneously decided tech debt isn't worth addressing then your competitor can easily overtake you. Furthermore adding feature after feature eventually leads to a kitchen sink product where potential customers are put off by the learning curve. This is really just a variation on the quantitative fallacy that ignores qualitative aspects.
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?
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.
> 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.
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.
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.
> 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?
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.
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.