I worked for a small very well oiled company, not really a "startup" but similar energy. We got gobbled up by a big company a number of years ago. The culture shock has been wild.
We've largely managed to, in the face of corporates wishes, maintain our speed and agility. With recent rounds of layoffs, we'll see if we can keep that up I guess.
I have come out of this experience genuinely wondering how large companies manage to stay in business. I frankly think it's down to resting on laurels.
For instance, if another department needs something fixed in an API we manage, assuming the work is simple, we can usually have it fixed and live within the day. We have had issues with APIs from other teams where an API we depend on has been offline for literal months because "there is no time on the roadmap" and it took six months for, from my understanding, a service to get restarted. This happens all the time.
Every single piece of work needs to be "planned". It needs to be fit into this imaginary schedule. God forbid you turn on the lights without a plan. The number of "planning meetings", sometimes multiple days long, that should have been an async slack thread is absolutely insane.
Almost always we could have everything being "planned" done inside the time of these meetings.
> Increasing legibility thus often actually lowers efficiency - but the other benefits are high enough that organizations are typically willing to do so regardless.
I dispute the second half of this entirely. Planning the unknown has so few real actual benefits in building software as to be nil. Perceived benefits, sure. Actual? Nil. The road before you literally unfolds as you build and sticking strictly to a map drawn by the blind is literally insane.
We give this imaginary "map" of what is supposed to be happening to managers and investors. Does this result in better software? God no. The results take far longer and are far worse in quality because we stuck to a map drawn by someone without impossible knowledge of the full scope of the problem because the only way to get that knowledge is to actually work through it, and if you do that you have the product. It's literally The Halting Problem. You cannot know the scope of a problem without doing the problem.
All it does is provide management and investors warm fuzzies that they think they know what's going on when they don't.
I was drawn to tech as a young man for its logic, reason and provability. As an older man, I find it so full of cults. Cults of process, cults of personality, cargo cults. It's all the junk I wanted to get away from.
I've been thinking about this a lot recently, I think it's a mixture of the effects of power laws we see in larger orgs having more revenue and their biggest concern is not having any issues that risks the reputation etc they've built.
Smaller more nimble orgs that are still finding their feet have an uphill climb, but the cost of mistakes is lower
We've largely managed to, in the face of corporates wishes, maintain our speed and agility. With recent rounds of layoffs, we'll see if we can keep that up I guess.
I have come out of this experience genuinely wondering how large companies manage to stay in business. I frankly think it's down to resting on laurels.
For instance, if another department needs something fixed in an API we manage, assuming the work is simple, we can usually have it fixed and live within the day. We have had issues with APIs from other teams where an API we depend on has been offline for literal months because "there is no time on the roadmap" and it took six months for, from my understanding, a service to get restarted. This happens all the time.
Every single piece of work needs to be "planned". It needs to be fit into this imaginary schedule. God forbid you turn on the lights without a plan. The number of "planning meetings", sometimes multiple days long, that should have been an async slack thread is absolutely insane.
Almost always we could have everything being "planned" done inside the time of these meetings.
> Increasing legibility thus often actually lowers efficiency - but the other benefits are high enough that organizations are typically willing to do so regardless.
I dispute the second half of this entirely. Planning the unknown has so few real actual benefits in building software as to be nil. Perceived benefits, sure. Actual? Nil. The road before you literally unfolds as you build and sticking strictly to a map drawn by the blind is literally insane.
We give this imaginary "map" of what is supposed to be happening to managers and investors. Does this result in better software? God no. The results take far longer and are far worse in quality because we stuck to a map drawn by someone without impossible knowledge of the full scope of the problem because the only way to get that knowledge is to actually work through it, and if you do that you have the product. It's literally The Halting Problem. You cannot know the scope of a problem without doing the problem.
All it does is provide management and investors warm fuzzies that they think they know what's going on when they don't.
I was drawn to tech as a young man for its logic, reason and provability. As an older man, I find it so full of cults. Cults of process, cults of personality, cargo cults. It's all the junk I wanted to get away from.