3 ms·
>Ship code more consistently. Speaking generally, for a CTO to personally ship more (non trivial code) code ... I think is such a double edged sword and even
by duxup 2y ago
>Ship code more consistently.
Speaking generally, for a CTO to personally ship more (non trivial code) code ... I think is such a double edged sword and even potentially dangerous.
His point 1 hits close to home, not for me personally, I'm not a CTO, but for the CTOs I worked with. CTOs shipping code that is important seems like constant pressure for the CTO to work outside the system or put off organization that the CTO should be doing. I see it time and again with heavily "involved" CTOs where they take that important task and now some other changes are held up or they just have to get it out the door so we'll try this ... oh and they're heads down this week because they took that important task so other important organizational things don't happen. Or they do the organizational thing, and the important task, AND miss the mark with the code / feature.
Personally I'm in a situation now where a great guy who was the CTO left abruptly and the rest of us are in a situation where we're picking up the pieces from all the exceptions he as CTO was empowered to allow. Things aren't documented, unexpected things show up like this code uses a weird auth pattern that seemed like a great idea and maybe was going to be used elsewhere if they just were around longer and so on. And at the time each event wasn't that bad maybe ... except it is now.
And really whose job is it to prevent that from happening? The CTO ... oh noes.
That's not everyone of course, but that level of CTO with his hand in the bits just seems constantly dangerous.
- zerkten 2y ago>> Speaking generally, for a CTO to personally ship more (non trivial code) code ... I think is such a double edged sword and even potentially dangerous. It is dangerous and is likely to cause a range of problems. The challenge is stepping away from that part of the work. It would seem the best way to do this is to progressively give up this direct work and mentor your replacement(s) possibly reviewing changes before quitting entirely. It seems to be a personality thing with some people being unable to take those steps before being forced by circumstances. I love leaders to have curiosity about details and want to create the environment for great technical work, but that is a very different type of work that doesn't drive the same rewards (or dopamine hits.)
- sponaugle 2y ago"That's not everyone of course, but that level of CTO with his hand in the bits just seems constantly dangerous." The biggest danger of a CTO being too deeply involved at a technical level is it does not scale. Knowledge and deep understanding helps you scale, but actually writing production code that has to be maintained puts a burden on scale. Of course at a startup that might be different, especially in the beginning, but the faster you get someone working for you that is even better than you at the job the faster you will be better at your future job.