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

[sensanaty]

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.

[sethammons]

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.

[fatnoah]

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

[seadan83]

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.

[raffraffraff]

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.

[motorest]

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

[agumonkey]

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

[Aeolun]

> 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

Salary is inversely proportional to how much you actually (need to) do.

[travisgriggs]

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]

How would you implement this though? Wouldn't things just be renamed?

[Micoloth]

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]

Nah, it's usually luck and robbing someone else work, windows apple Facebook etc

[bryanrasmussen]

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.

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

[cereal_cable]

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.

[worksonmymach]

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!

[sevensor]

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.

[bjornsing]

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.

[YetAnotherNick]

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.

[motorest]

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

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

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

[whstl]

False dichotomy. The point of the quote is to worry about not breaking the product. It's still possible to deliver features while keeping it working.

[motorest]

> False dichotomy.

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.

[jack_h]

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

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

[munksbeer]

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]

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

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]

Why did I hire these people if I cannot delegate responsibility to them?

[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…

[yard2010]

Bad example in my honest opinion: Merkel made me believe it's the "worst case scenario" kind of thing - same reason there shouldn't be capital punishment. If you can't afford to pay the price in the worst case scenario you shouldn't take the risk.

That being said, I believe failures and mistakes are simply part of our lives. I would turn the other way and run when someone says that he found the perfect system, in which there are no losses failures and problems. You are always limited by what you don't know you don't know.

[Cpoll]

> If you can't afford to pay the price in the worst case scenario you shouldn't take the risk.

Which probably precludes leaving your house (or staying in it, for that matter).

[Timwi]

I thought of that too, but also the US banning Kinder Surprise eggs.

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

[wkrsz]

That makes sense. Either knock down the walls all the way and empower developers to make decisions, or keep the walls and let all requests go through the pipeline.

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

[geophile]

Yes, and at the same time, companies start hiring employees that shouldn’t be trusted.

Neither one causes the other, both occur as companies mature. I’ve seen this as startups mature. One very vivid recollection: we had a very strong and tiny dev team. Each dev owned a huge piece of the product. Definitely not egoless. We brought in trusted junior devs to grow. That was fine.

Then the very talented VP Eng. wanted a promotion and brought in a hack to replace him, who hadn’t coded in years, and was obviously more concerned with his career than our product. A real mediocrity. But the VP wanted to move on, so this mediocrity was hired, over vigorous objections.

That was the end. This new VP brought in mediocre devs, rewarding loyalty and “being a team player” more than productivity, or competence. He brought in employees who couldn’t be trusted.

As this was happening, we were acquired, and our new bosses from the parent company were used to employees who couldn’t be trusted, and acted that way.

HR knew that to keep the good engineers they had to do something, so they showered us with bonuses. That worked for a while. I finally got so bored and fed up that I left (for another startup).

[aylmao]

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

On that note, a quick shot-out because I've been lucky enough to see the opposite happen at a big company too. Performance cycles at the company very much disincentivized big bets. Some engineers really thought project "X" was important, but it was risky— if it didn't pay off by the end of the cycle, per the way the bureaucracy worked, it wouldn't be great.

The manager very much tried his best to protect them against this. In fact I don't think it paid that cycle, but the project remained active until it did eventually pay off. Shoutout to managers like this. The easy route is to act like a messenger for higher-ups, and never put your own skin in the game— but there's some out there that want to do what's best, not what's easy.

[RHSman2]

This. This is what ‘higher’ ups should be aiming for. I try and do it with all my attention. The good fight.

[kridsdale1]

> there's almost always a point where a company decides they need to stop generally trusting their employees

I recall exactly when this happened at Facebook.

[tbrownaw]

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

$employer has formal separation of duties between development and build/release for some things, which deal with other people's money. I'm pretty sure it's mandated by customer contracts.

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

[motorest]

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

You don't get the luxury of not making decisions. You always have to make decisions.

[khafra]

If you do not consider the problem at all, you have not made a decision on it; any more than you have to make a decision about, say, the most aesthetically pleasing perspective of Olympus Mons for prospective Martian colonists.

The actual point stands, either way: Whether you do not make a decision, or you decide not to act, the outcome is the same--and it is often a better outcome than the result of reactive or proactive decision-making.

[munksbeer]

What if the decision is to not do anything because the event is so unlikely to happen again that it isn't worth the cost to fix.

[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

[Aeolun]

Ownership to ‘make sure it happens’ is entirely different from being able to ‘make’ it happen. The first is absolutely toxic.

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