Let’s have no managers, instead of managers with no engineering experience

But of course, what says "Sunday Night" like a good fisking?

> I'd say that's the real "just ignore the cycle of failure in the industry and keep writing the same stale think pieces" approach. We've had decades of talking about how vital good management is and how better training for management is a great idea, and to what avail?

Well it wasn't terribly actionable advice before, say, 2008, now was it? The number of people who could get a strong foundational education with industry focus in CS was quite low until the early 2000's, and most folks want at least 5 years experience.

So really, the only supply of technically proficient managers was folks who were unusually talented AND escaped the orbit of organizations that provided quality experience. So like, Apple? Sun maybe. NeXT? Early Intel was boss, and I knew some amazing folks from SGI.

I had a very negative experience of tech managers too, until I met Bruce Horn from Apple. My earlier experiences were a complete train wreck. I met him in 2006.

We've actually seen a really great wave of folks tackling the idea. Folks like Camille Fournier or Dave Smith producing really great material for consumption. I'm grateful to both.

> I was thinking about technically-vertical rather than organizationally-vertical. Cases where the implementation of a single customer-facing feature - the response to a single customer request - is handled by components that are the responsibilities of several different teams with their own management... That's how you'd end up needing to coordinate roadmaps between different teams, and I see that as indicating poor structuring of responsibilities, usually a result of a team taking exclusive control of an area that should be shared, which is usually a management phenomenon.

Pardon me, so you're suggesting you hire folks who can both implement the API and the distributed systems AND build the mobile client apps, and also the website?

That's how you get mediocre outputs.

> It's an appealing thought, but it just doesn't match my experience of how it works out in practice.

That much is clear.

> Or one manager brings a particular API under their control to expand their own importance, and prioritizes their own needs - or worse, deprioritizes work on it because they're not actually using that API for anything important but won't allow others to improve it. Or it emerges that what was initially assumed to be a single common feature actually has use cases that are so different that they should be implemented separately, but any team that proposed to fork off their own variant would be assumed to be empire-building (or, equally and oppositely, would be given insufficient support in their work), so everyone keeps muddling through with an awkward compromise.

I'm not sure if you fully understand the nuance of this conversation though. I'm not objecting to the notion that bad non-technical management exists. Or even that bad technical management has existed. I cannot deny you've experienced this nor am I interested in doing so.

I'm saying: we need to do better. It's important to do better. And it's worth noting that the really amazing companies we see out there that do huge, good work? Netflix, Google, Mozilla, even Amazon (who I don't think very highly of) etc? They don't do that holocracy thing or that flat organizational structure. Heck, they've even gone so far is to separate site reliability from product engineering entirely. And most folks who I respect as engineer say this separation is the right call.

Our industry has a history of improvement. Not just in terms of technical accomplishment, but in terms of organizational success. Once even small software projects were complete nightmares, now most things ship and we're used to seeing a slew of somewhat functional software products that are lacking not for features but for product-market fit! Now, a previously unimaginably complex baggage checking system that was a famous failure is actually a 1 semester college product for upper-division software engineering and DAMN if they don't do a credible job of it (even though Kids These Days(tm) still don't learn enough about how SLAs are met in industry).

Engineering management and planning has had a similar curve of improvement.

> (people say that you'll get stuck in a local optimum that fits the first use case but can't possibly be adapted to the second, but I just haven't seen that happen in practice; code that was written for a single use case inherently tends to be simple and malleable)

Aside: I've certainly had that happen! At Level we originally based the system around a primary spending account and secondary asset accounts because the staff and everyone who we interviewed had that configuration. We quickly learned that we had a biased sample and many people have multiple spending accounts. It took a very clever engineer to unkink our system to solve for that problem. Wish I had listened to our advisor, it would have saved us 3 months!

> I don't think good technical architects/technical planners exist - I've just never encountered anyone who was able to produce better results by making technical decisions ahead of time (across a wide variety of management styles and techniques) than leaving them to implementation.

I think you have a curiously warped view of architecture. That it spans quarters or even months into the future. It doesn't. Often times, it's as much about auditing the existing babel of engineer rodeo projects to find out what's closest to meeting the requirements and helping those engineers sketch out how to take it the remaining agonizing 20%.

> and that those that succeed often do so by doing things that don't scale; in any case a startup CTO is rarely doing all the activities you listed earlier.

I know several post-exit CTOs because we hang out and we all have similar stories about doing this. I also know a lot of would-have-beens who said they didn't care about things like hiring and "just wanted to code" or functioned more like VPs of engineering (which are a pure management function).

> Often startups don't have multiple distinct technical teams

Usually it's "teams" of 1. You have the mobile specialist, the API owner (often the CTO), the website specialist. This is a very simple version of the larger exercise, but it's often even more important to keep track of how things are progressing because you have so little tolerance of wasted time.

I'd recommend looking into why the ramp up time is so long.

Especially if you only assign tasks you know how to do, you are likely hampering your systems ability to become simpler.

For example, recently we took away 1000s of lines of nuanced code by using an out of the box cloud service (which none of us knew how to use). It offers a similar interface, and it's cheaper and easier to use. Took a week to play around and research if something else was more appropriate, took another three weeks, and we deleted 10% of our code.