[spuds]

Really resonated with this, reminded me of the journey I went on over the course of my dev career. By the end, my advice for every manager was roughly:

* Don't add process just for the sake of it. Only add it if seriously needed.

* Require ownership all the way to prod and beyond, no matter the role. (Turns out people tend to really like that.)

* Stop making reactive decisions. If something bad happened on a total, extremely unlikely lark, don't act like it's going to happen again next week.

* Resist the urge to build walls between people/teams/departments. Instead, build a culture of collaboration (Hard and squishy and difficult to scale? Yup. Worth it? Absolutely.)

* Never forget your team is full of actual humans.

[dakiol]

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]

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.

[julik]

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.

[Kinrany]

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

[worksonmymach]

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.

[HL33tibCe7]

> 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".

[safety1st]

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?

[ariosto]

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.

[spuds]

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]

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

[motorest]

> 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?

[mihaaly]

> '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.

[miki123211]

> * Stop making reactive decisions. If something bad happened on a total, extremely unlikely lark, don't act like it's going to happen again next week.

I feel like everybody needs to internalize this one (and that notably includes governments and politicians), but it's a really hard problem to solve.

If something bad happened, people (whether that be higher-ups, journalists, lawyers or your constituents) expect you to do something about it. "yeah, a child just got raped on our property but we don't have to do anything about it, it probably won't happen again" is not an acceptable answer in most circumstances, even if it's the right answer.

[lysecret]

Yea Germany quitting all nuclear comes to mind…

[wkrsz]

> Resist the urge to build walls between people/teams/departments

Do you often have to deal with support staff reaching out directly to developers on Slack to investigate some problem – without going through "normal" process of creating a ticket that gets assigned? Or even asking for features.

Developers generally want to be helpful, but also small requests often turn out to be rabbit holes. And even in best case it distracts from work that was explicitly assigned and scheduled.

I noticed I experience a bit of anxiety every time I'm doing some work that came through backchannels. The way I try to alleviate is create the ticket myself, mention its source and assign it to myself. This way switching context is visible and I can tell myself that "if manager doesn't want me to spend time debugging this now, they can react".

[9rx]

In fairness, it seems the problem in your case is that the "manager" has built up walls between people, trying to own the work, and in that not allowing you the full context that would allow you to make informed decisions around such asks. "The manager not wanting you to spend time debugging this now" should be a false premise. Knock down the walls and you will know yourself that you shouldn't spend time debugging it now.

[aylmao]

Recently, I was thinking plenty about trust within organizations, and it resonated with me too.

I've worked at a few startups and have seen high-trust environments lead to a lot of productivity, comfort and success— and the opposite for low-trust startups. In general, I think startups tend to lean towards high-trust, especially when they're small and early, but I was part of a 15-person one that was quite the opposite, and it was terrible.

The hiring process wasn't great. Long take-home task, and that was the only technical interview. A lot of talking, but not much noteworthy signal on the rest. Very long wait times. Now I know this is a red flag for low-trust companies. If they're not building trust at the hiring-stage, it means even after joining the organization it'll take time to acutally "be part of the team".

Once at the company, I had no permission to poke around— everything was hidden by default. There was no space for discussion, I was expected to learn, not to comment. There was plenty of micro-management; after all, if they don't trust you, they need to keep an eye on you at all times. You're probably doing something wrong.

The chasms were deep too; the company was building a web team to spin a contractor's project into a full web product, and I was supposed to lead it. We were disjointed from the rest of the company though, and would only hear about requirements through the founders. The team had interest on being more involved with the main product, but management just wasn't interested in making it happen, and just had us loiter around for a few months until they gathered requirements, and then implement some rather disjoint features.

The project failed. I'm working somewhere else now.

tldr; low-trust environments kill projects

[spuds]

Yeah, I think there's almost always a point where a company decides they need to stop generally trusting their employees. Then all the trustworthy ones start getting more and more frustrated, or just start checking out. Agreed that most startups lean towards trust. Need to keep that going as long as possible, and stay away from hiring managers who think their primary job is "protecting" the company from anyone who might make a mistake.

[theropost]

I completely agree. I’ve had the privilege of working with a very small team of engineers—a team with diverse life experiences and unique areas of expertise but a shared work ethic: the willingness to try. We always said that most of our time was spent failing, and that’s what made the moments of success so rewarding. When we finally succeeded, it wasn’t just about the victory; it was the culmination of relentless effort that allowed us to push forward, improve our product, and refine our ideas.

Our approach was unique. We engaged directly with the people who did the work, learning from their insights and challenges, and built tools specifically for them. It wasn’t an Agile team or a Waterfall approach, or any other rigid corporate framework. It was an ad hoc team that came together organically to solve problems—and solved them faster than large corporations, consultants, or armies of workers ever could.

With just four people, we scaled applications, built automation systems, and tackled complex problems that delivered multi-million-dollar savings across the board. The process was simple: no micromanagement, no unnecessary oversight. Everyone contributed based on what made sense, and we all collaborated freely to solve problems as they arose, moving seamlessly from one challenge to the next. It was innovation through cohesion—a kind of synergy that can’t be forced or replicated through standard processes. It’s the magic of the right people, in the right place, at the right time.

Over the years, the tools we developed have grown into critical applications used by professional organizations, with over 3,000 users relying on them daily to make their work hundreds of percent faster. Yet, when these tools are handed over to large organizations for "modernization" or "corporatization," they often end up spending exorbitant amounts of money, adding no meaningful features, and making the tools less effective. Teams of 30 people fail to replicate what our small team accomplished. It’s a strange and frustrating reality.

I’ve tried to find ways to replicate this success, but I think it comes down to that intangible element—a “ragtag team” dynamic where the right people come together with a shared drive and passion. It’s rare, and perhaps it doesn’t exist as it once did. Maybe it’s out there, but we need to find ways to enable and foster it.

[RHSman2]

I think there are ways of philosophy not process. And the philosophy has to be agile to those in it.

[motorest]

> * Stop making reactive decisions. If something bad happened on a total, extremely unlikely lark, don't act like it's going to happen again next week.

I don't think this item was well thought through. Taking proactive decisions means allocating work for tasks that do not solve a concrete problem but bear the risk of introducing regressions. On the absolute best scenario, things continue to work as always. On the absolute worst scenario, you introduce a critical regression that brings down the service. There is literally no upside and all downsides.

There are many reasons why "if it ain't broke don't fix it" is tried and true.

> * Resist the urge to build walls between people/teams/departments. Instead, build a culture of collaboration (Hard and squishy and difficult to scale? Yup. Worth it? Absolutely.)

That really depends on what you mean by "walls". The reason Conway's law is a thing is that in order to have functioning teams you also need functional independence. If you need to book a meeting with anyone to justify pushing a change to a service you do not own, that's already a wall. No matter how easy it is to get through that wall, it's still easier to not have to go through it.

I can tell you an example of how independence always beats collaboration. Once I worked on a project where QAs were a separate team entirely, and made it their point to be the sole owners and maintainers of all automated test suites beyond unit and integration tests. We experienced a major regression that the regression test suite wasn't caught. I went right to the head of QAs and asked if I could push a commit to add a couple of regression tests. He politely declined by saying that they were already working on it and I wouldn't need to bother with that. Great, a victory for not building walls I guess? Except that his "we are working on it" ended up being "we added a ticket to our backlog and we might pick it up two months from now". Literally. And they never did, by the way, and the same regression was eventually introduced without anyone noticing.

In case you wonder how I solved that problem, I created my own regression test suite. Conway's law always wins.

[khafra]

The context of "stop making reactive decisions" isn't "start making proactive decisions." It's to just make fewer decisions.

The specific example is of a rare event which, while regrettable, does not justify the cost of policy changes to prevent it.

[kookamamie]

> Require ownership all the way to prod and beyond

Ideally this sounds great, practically it rarely happens in modern organizations.

Companies, and corporations especially, do not like the idea of engineers having personal ownership over things, as that makes them harder to replace, i.e. reduces the redundancy of the organization.

[Lanolderen]

Redundancy is honestly a good thing. Some smaller companies not in IT have their entire software/hardware infrastucture dependant on a single person who's been there for 20 years and it's objectively dangerous.

Is ownership incompatible with redundancy though? The way I understand it ownership is more so about keeping the app in the specific teams hands to avoid having secretaries running from team to team trying to keep teams from unintentionally sabotaging each other and handling suggestions in a constructive way so everyone is involved in the architecture and general direction of the product and they don't feel like code monkeys. You can still have 20 people on a single project each owning it to an extent. You probably even get more redundancy that way since people are incentivized to look at the bigger picture if they can impact it.

PS: Stupid question but is there an actual definition for ownership? I think I might be talking out of my ass here.

[tayo42]

> Stop making reactive decisions. If something bad happened on a total, extremely unlikely lark, don't act like it's going to happen again next week

I hate this, like when there's an outage and the outcome is 100 half baked ideas that must be implemented, that just make things worse to work with

[spuds]

Yeah. And all the time spent on those 100 half baked ideas take away from time that could be spent working on the most likely cause of the next outage. (Real forward-looking risk reduction work.)

[beryilma]

I really believe in the ownership model, which is why I hate the Jira ticket-based development model so much.

There was a time in my company where a single developer, who owned the product, would ship an entire app in a year. Now we have a "cross-team" where you have to constantly manage all feedback and try to shut down stupid ideas from getting into the product. I really hate design by committee: all talk and no ownership.

[steelframe]

> Stop making reactive decisions. If something bad happened on a total, extremely unlikely lark, don't act like it's going to happen again next week.

This is a central theme in Bruce Schneier's 2003 book Beyond Fear, which I continue to recommend 20 years after I first read it.

[Aloisius]

> Require ownership all the way to prod and beyond, no matter the role. (Turns out people tend to really like that.)

Depends on what you mean.

Individual ownership over code/feature/module/etc would seem to run counter to the article - it's just another fiefdom.

Collective ownership? Sure.

[T-Winsnes]

I think the right balance here is to have ownership of the outcome rather than the thing. E.g. you have ownership of making sure the feature you’re working on makes it to production and works properly

With that ownership comes there responsibility and accountability of making sure it happens. The level of responsibility and autonomy that comes with that is what I’ve found people react positively to

[layer8]

* Separate bullet points by blank lines on HN. ;)

[spuds]

Yeah, I'm facepalming on that one. Thanks!

[kazinator]

The Process Person who wants to build a Mature software organization will say, process is seriously needed.

[kubanczyk]

That dork can only become factory manager when there are factory workers, see? "Process" is just a word for a production line of some kind - narrower or broader, but still a life-sucking endeavor.

[agumonkey]

talking about ownership, I ran into some git repo with a "declaration of non ownership"

an economy of giving in a way

[munksbeer]

In my humble opinion, this is excellent advice. Honestly, so on point.

[mihaaly]

Excellent points!

I wonder why these almost never considered.

[aylmao]

I've worked at FAANG. Actual humans too.

[nox101]

Can you unpack your comment?