A CTO should be technical

This comment may have been the tipping point into seriously considering quitting. Deep down I already felt it coming on but seeing it laid out like this hit home. The person currently in that leadership position fits every one of these bullet points and somehow remains in that position.

All their direct reports just seem to accept this lot in life, everyone else does their best to avoid drawing their ire. I imagine that maybe something will happen and they will get the picture and actually grow as a leader. It's growing old though and I miss being on a team wherein this wasn't the day to day morale.

Maybe they'll read this. Maybe it's you. Please take this seriously. You could do better.

Some CTOs who have seen their companies going from 10-1000 don't seem to grow up in their role. They don't learn delegation or trusting others with making decisions. They end up becoming a glorified architect instead of an actual leader. Meanwhile since no one takes the lead in setting up processes and keeping an ear to the ground on quality, velocity etc and things go bad quickly.

This article reads like something a startup CTO would do or expected to do. Frankly companies below 100 shouldn't have this role. Someone leading a 10 person tech team isn't really a CTO because the work and decisions involved are totally different from someone leading a larger tech organisation. They should just mark such roles as what it is: a senior architect.

Sure, if we talk about something he didn't say, it could be better. But even then I think it's a big mistake.

The point of coding is to make things for people. If we stop making things for people and do something else, however virtuous that something else might seem, I think we aren't moving in the direction of long-term improvement.

One of the biggest roots of low quality is high time pressure. So I'm fine throttling back feature to 80%, 50%, maybe even 20% of the long-term capacity so that everybody can start learning to work in ways where technical debt decreases and quality practices get properly established.

But I think it's vital that we keep that x% of forward motion. For all sorts of reasons, but the biggest being that everybody, techies and product people most definitely included, need to learn to work together such that quality stays high. If the product people just wander off for a few months while the devs do mop and bucket work, what people generally learn is to repeat the cycle of making such a big mess that another big cleanup is needed down the road.

The CTO doesnt have to be technical. But they have to have a technical council that folks can go to to hash things out with.

Ideally the CTO or council shouldnt even have to make the decisions most of the time. But every company should have intensive hard debates, struggles, long and hard, about what technically to build and how. Most companies take a hands off approach, and leave folks to hash it out among themselves & figure out in structureless ways what to do. This rarely results in real feedback, in better options being picked; the tyranny of structureless happens, grows amid the absence of there being considered seasoned wise people about who can ask sharp insightful pointed questions at everyone, who can make plainer what the tradeoffs & real costs really will be.

Without sharp technical competency high up in the chain, discussions turn into a formulaic sad debate: the people who dont tech argue for lower estimates (or when they dont like hearing about hard work they force a change in direction), the knowledge workers get sadder and sadder that no one can see what the problems & situation really is or that there is no one around to fave & tackle the obvious/real challenges.

A technical executive team can argue with team the opposite: your plans arent comprehensive enough. You arent accounting for enough cases, seeing enough of the problems. Your scope isnt ambitous enough. The tools & libraries you are picking will have issues here & there that you havent seen.

Very few corps seem able to understand their own hierarchical ignorance & stupidity. They trust in their chain of command as people leaders, with ultimately teams in charge of making good decisions. I tell you: this is not enough. Teams want buy in in a real sense from above. They want senior staff who understand in a real way & can provide some real guidance & advice. Few companies have this at all.

Earlier today there was a 2011 piece on Jobs (a man I'm mixed on, but) his advice on saying no, on cutting out cruft[1], is something that is at least as much technical as it is product. And few orgs know how to keep & retain technical talent, technical council, that isnt people managers, but tech managers. Those companies that can actually take ownership of their product from the top, that know what they are really doing, have a much greater potential to cut the cruft, to steer toward better. Few do.

Technical know-how doesnt have to be the CTO's role, but it really should be a function high up in the org that is visible, respected, & active. Too many orgs are technical only at the bottom, and there need to be more active chains of understanding & respect within an org than that for real positive growth to happen. This is, for sure, one of the hardest least addressed issues in tech, & a key to doing better. But tech is often left out of the room, & closing the gap is hard.

[1] https://www.forbes.com/sites/carminegallo/2011/05/16/steve-j... https://news.ycombinator.com/item?id=32985952 (2 points, 9 hr ago, 4 comments)

That would be a Chief Liaise Officer.