[carlisle_]

Great insight, my key takeaway is this:

> The fewer people you need to make decisions, the faster you can make them.

This is the only way I’ve seen a “rockstar” or “10x” get stuff done as fast as they do. They only have to talk to a couple of people at most to start making big changes. The more large and stable a company gets, the more they seem to want to spread decision making power around the org. This appears to be very counterproductive, and it’s nice to see the simple truth called out.

[nickjj]

This is really it.

There's a world of a difference in what you can do if you have free reign to make most technical decisions with full autonomy (self guided R&D, picking stuff, spiking it out, doing it for real, etc.), perhaps only reporting back weekly outcomes to a CTO and also asking their advice as needed to align on big picture goals while nothing is ever blocked.

vs.

Most decisions needs to go through someone else, which then turns into an adhoc request for another department which then has to ticket it out and implement things on their schedule. They could be a great team and do everything in the best way you can realistically hope for but before you know it, things that were literally 1 or 2 hours of dev time end up taking 3-4 weeks simply because they have other things going on too. You keep repeating this pattern and it's how something ends up taking 6 months instead of 2 weeks. It's also one of the most frustrating things to be blocked. It forces you to context switch between many things to keep yourself busy. You spend all of your time reacting to eventually getting unblocked in an uncontrolled way instead of just sitting down and cranking it out. That means you might have to jump back into something you worked on 2 weeks ago and re-get all of that context back in your head.

I know in an Agile sense every team should be self sustained and can own their work from beginning to end but from an infrastructure perspective you may run into scenarios where you need resources created by another team because in a bigger org it's company policy. The blockers could be a combo of waiting on that other team or waiting until multiple people sign off on moving forward with XYZ tech.

[altacc]

One of the reasons enterprise organisations are so slow to adapt and release new products is the number of people needed to make a decision. I've seen large companies try to implement agile and it generally fails because they can't shift to quick & effective decision making processes. Greenfield projects that get developed quickly due to independence and have great promise for the future get the hug of death as soon as management decides to bring the project into the same decision making as the rest of the org.

[salmonfalls]

This is the exact case that I have been in the last two years or so. As a greenfield project being one of the first in the newly implemented Agile work. Everything was amazing in the beginnig with quick decision making. However as soon as we 'went live' and were forced into the established change control workflow development grinded to a halt. We now implement features at a snails pace compared to before.

[azemetre]

I feel this in my soul, I'm not even allowed to update internal documentation in our repo without linking it to a JIRA ticket.

[mr-ron]

I mean, thats pretty normal for any stage tech organization.

The question is, who gets the right to create a jira ticket? Maybe you can do it, or just one other person. Thats not a big limitation at all to moving quick.

Edit because this is causing a stir:

Engineers within teams should have the right to create tickets themselves. Tickets should be minimal depending on the task. Creating a ticket that says 'update documentation' may take 10 seconds. Updating documentation may require a pull request. Controls (SOC compliance) may require that work is tracked to tickets.

The core questions I have is, who can create the tickets, and how detailed do they need to be?

[lifeplusplus]

In my past job, I volunteered and pushed to get the whole project, then I asked to be exempted from all scrum stuff, then got really close to PM and Designer, launched the whole thing without a single bug in 3 months and with more features than planned, and had 2 more months left.

The reason there were no bugs was because any question I had, I slacked messaged PM, and got replied in less than a minute. She was on the project full time too, and was technical so was able to test out things and apis, document correct relevant data like console log errors, browser version, json response, curl ... etc.

My takeaway was similar to yours but in more concrete terms:

- have experts available in team which can be consulted asap - give whole projects - start with minimal project - create small informal groups, POC for each area: sr eng for legacy code, designer to get artifacts, PM to clarify tickets and address new bugs, main dev to do the whole thing - have team informally occasionally input on tech decisions.

[rco8786]

> I t’s nice to see the simple truth called out.

It’s not as though it’s a secret or anything. It’s a common point of discussion. The simple matter is that big co’s naturally have more inputs into the same types of decisions and thus need more people involved.

[jeffbee]

I don't think it's about largeness, and the autonomy of "rockstars" is of dubious value. Google is the largest company where I've worked, and also the most productive. For code that an IC owns, they only need the sign-off of literally anyone else in the company to land changes, and all that is expected is those changes are generally consistent with team goals. For code an IC does not own, they only need the approval of one owner. Pretty straight-forward.

A medium-sized company where I worked had a "rockstar" who was really just an early employee with a high title and no idea what he was doing, so every week he committed a thousand lines of brand-new unreviewed tech debt. Much of the rest of the company was unwittingly dedicated to overcoming his tech debt. Said company currently trades at about 1/3rd below its IPO valuation.

The experience of these two companies led me to the belief that hiring practices and review culture are more important than project management culture. You can get a lot done with good talent, code and design review, and vaguely disorganized project leadership, and you can run in place achieving nothing with formal project management hamstrung by bozo engineers.

[carlisle_]

> and the autonomy of "rockstars" is of dubious value.

I agree, but with your example, I wouldn’t call somebody committing massive amounts of tech debt a “rock star”. I used the term fairly facetiously anyway, because I think we all know the 10x engineer is a myth.

[duxup]

“Jim is so productive!”

-by design Jim is the only one allowed to be productive-

:P

[sanderjd]

Yeah this is exactly it. But I think it's a good thing. It's a tradeoff between productivity and risk. It is productive but risky for "rockstars" to make big changes with very little consensus-seeking. Big changes are double edged, they have outsize impact, but it may be either positive or negative. So organizations rationally hedge that. The trick is to strike a good balance, giving up as little productivity as possible for the greatest reduction in risk. It's hard! Sometimes the right answer is just "empower one or a few people to do whatever they think best without ever seeking any buy in from anyone else", but not often. And "never let anyone do anything without a big slow sprawling committee giving permission" is essentially never the right answer. But there is lots of space in between these extremes!

[tgv]

Such is the nature of organisations. E.g., X is the boss of a group, the group becomes a department, X hires people to manage the groups in the department, and now all these people have to be informed as well, and of course they have an opinion, too. And they are rarely good managers. Then X leaves and politics kick in because everyone covets the position, and then someone's simple task becomes the focus of someone who wants to place your manager in a bad light. And it never stops, because there's no incentive to make it stop.

[lupire]

Your 10x rockstar is my cowboy coder 0.1xing the team.

[carlisle_]

The use of the term was supposed to be illustrative and mostly facetious, hence the quotes.