Only Debate The Non-Linear

No matter who you are in a company, there is, with probability one, someone who has specific context on something that is non-linear... that you, from your context, think is just linear. (If you're in leadership, this is even more important to understand!)

And if you're arguing that something else is non-linear and thus more important, you're de facto arguing on whether the thing you want to deprioritize is linear.

As CTO at a relatively-early-stage startup, one of my most important jobs is to give both technical and non-technical colleagues the benefit of the doubt that they've spotted something that I didn't know was a critical non-linear opportunity, and juggle expectations so that the non-linear thing they discovered can be addressed before it becomes either a problem or a missed opportunity.

For instance, "customer X filed a ticket that they will need Y" can be easy to dismiss as a linear improvement-per-unit-work that's out of scope... but I need to keep my door open to hearing from our Customer X quarterback that Customer X is the nexus for an entire consortium of partners who all need Y and will adore us for it, in ways that might outrun the incremental improvements we'd already had planned. And, similarly, if an engineer discovers that Z is a non-linear drag of technical debt, that could be equally vital to our ability to move in an agile manner in the near future.

But I do hope each person allocates their advocacy-time (or prickliness-allocation, or communications bandwidth, depending on who you ask) towards the things they believe are the most non-linear, so we can make the right decisions as a team without getting bogged down in meetings and debates. And they know I'll try to do the same. So the mental model, "only debate the non-linear," is very useful up and down the stack.

This kind of anti-intellectualism is extremely harmful. In reality engineers generally are smarter than average and that’s a good thing if you like things like safe aviation.

From personal experience sitting with higher management I can assure you that they are one of the dumbest, most ignorant people I have ever met.

I know more about business and their products than they do. Their only qualifications are high self-confidence and social connections. I wouldn't trust them to do even simple manual labor.

I've been out of big-name marquee tech for several years now, but as recently as late last decade it was in fact possible to achieve meaningful seniority as an engineering manager on the back of serious engagement with the subject matter. I at one time managed a team of roughly ~35 serious engineers and several managers in a critical path and was considered senior enough to be called an L7 because I read at least and usually commented on one or more diffs a day, and worked on and usually landed a diff or two a week.

I don't know where the meme started that managing technical work was orthogonal to understanding technical work, but CTOs like Carmack disagree (FWIW little old me does as well). In almost any other field from fabrication in a shop full of machines to a law firm, the top person is the most expert person, and I think it's a weird path-dependent aberration that software got off that proven paved path.

YMMV but this stuff is IMHO getting so complicated that I think managers will be trending more rather than less technical for the foreseeable future.

There's is a continuum in how well you can perform as a software developer and this is a non-linear phenomena. That said the "title" is definitely often a made up thing.

It's not like politics don't come into play. Politics are always at play. But doing an obviously poor job with great politics won't work in most organizations and you can be a good engineer and still understand the politics and advance your abilities and advance in the organization.

I've had 2 managers who were better than this, and they were prior programmers who still understood the code but had moved up.

The best managers are good coders who realize that by directing they can actually accomplish more across many areas than they could have as a individual contributed.

But 4/5 are disconnected paycheck collectors who need to be told stories

Actually doing what the author describes is often impossible except in an intuitive way. How could you know a priori which decisions might have big impacts? On a project of any complexity you need either deep specific experience or a very accurate working model of the entire project. You aren’t likely to have either.

This has been previously covered in depth, even in software, although of course it could possibly be improved.

Painting the bikeshed is one example: http://phk.freebsd.dk/sagas/bikeshed/

And yet, many people might agree with it but still debate trivial matters

Years later I read that he really regretted it because he realized that project shouldn't be even started unless they're too important to be micromanaged...

It is, don't start linear return projects...