"CTO in training"

Danger, Will Robinson!

I followed a similar path to the one you now tread. I cofounded, and managed/grew the dev team from me to forty folks.

Three years ago (after seven years of just "tech director"), I took the mantle of CTO.

Error.

CTO is not a technical role. To do it well, you must be technical, but it is in reality a sales and marketing role, both internal and external. I found myself isolated from our tech team in short order, as as CTO one is the public and board level technical face of the company - and that becomes all consuming, and you become the perceived source of all the problems. You become the messenger, who is much shot at, by both clients and your former allies in your technical team. The clients shout at you for bugs. The developers shout at you for pleading that bugs get fixed. You become that which lives between hammer and anvil. You are no longer part of the team. You are the boss.

So - unless you want to get out of technology and want to work as a marketeer/apology bot, don't aim for CTO. I did, it broke me.

I left my company today, as I started it for the love of tech, and making cool stuff - and at the point of organisational development they have reached, that is not something there's any scope for a CTO to do.

Lesson learned.

Sorry to hear this. I've been through a similar transition. 1 of 2 devs 5 years ago, growing a team to 45+ engineers today. I felt a lot of what you describe. I was somewhat aware of the split (as it was happening) between technical creativity and being the face of the team (but not actually building). I realized that building, being creative was something I didn't want to lose. I hired directors and promoted (eventually) one to VP. He and I work very closely, but the clear distinction is he runs the engineering team, and I am responsible for running the architecture group, facilitating engineering culture and leading research.

Thankfully my CEO was supportive of the split I defined, and it has allowed me to not lose my identity. But for a good 2 years there, I was struggling to find the right fit.

And as for getting yelled at about bugs, that's just part of the job. It's hard not to take personally, but when you realize that CSMs get yelled at so much more about bugs than we do in engineering roles, it helps put the pain into perspective.

Yeah, having support within the business probably helps. I was hung out to dry one time too many.

I likewise promoted and hired to try to make the situation tenable, but wasn't allowed to change my role to be less client/organisation focussed - by that point I was truly shut out of the dev team.

It's also very hard not to take personally when nobody else is willing to take any responsibility - everything ends up escalated, usually with clients making death threats and other such fun.

Perhaps I'm just thin skinned, but I reached the point where halving my net worth just to escape was the best option.

I've found dividing up the support among engineers helps this a lot. Lack of empathy is a big factor here. Having engineers understanding customer problems also leads to easy consensus and easier cross collaboration among teams. Would love input contradicting this. I'm still learning a lot myself but this has worked for us.

Nail on head. There was zero empathy from anyone for anyone, except for from me for everyone. Again, part of my problem is that I probably care too damn much. If our teams, our clients, were upset it would upset me, and I spent most of my time feeling like a bloody counsellor rather than a CTO.

We actually did pull development into support on a rota - and after a month of me spending two hours a day dealing with angry toxic engineers who are threatening to walk out because they've been made to look in the support inbox, or placating clients who've been brusquely told their issue isn't seen as a problem, we backed down. It turned into out and out warfare, people were naming their damn factions.

Does say something that the only technical person in the company other than support to do support was me.

Sorry for the tough situation. Hope all has worked out better since.

Well, it's been a day since I left, and all I've managed is to increment my age by a year!

Today I need to go and actually announce my resignation to the team. Only the directors know. Either everyone will cheer, or worse yet, there will be no reaction at all.

I made a rod for my own back - it just took me a decade to realise it. I guess I'm just not cut out for this.

I became CTO quite young and I was running around doing technical stuff when my colleague pointed out that was not what I should be doing. I was co-founder of the company, so after I read what I should be doing (which is more like what you say), I appointed my right hand as CTO and I became head of our small R&D dep. That was excellent. Now i'm CTO again; older and wiser and I fit the role now, however, when we grow more that might change. I really do want to keep coding for fun and business.

Yeah, my colleagues just found entertainment in watching me lose my wits (they're both stoics, very good at business but not big on the giving a damn scale, and I do worry about long term course in my absence, and think they may go steady-state from here in), and after I took some time out because I was on the brink of recklessness, suggested I leave the business. So I did. I'm pretty sure it's the right call for all concerned.

CTO roles at companies vary. Some end up doing "technical stuff" as well as business. How large was your team that this was a problem?

300something. I was too involved in the projects themselves (which is what I like(d)).

Haha yeah, that's why I added that I don't really call myself that but it sounds better for the story.

I'm basically a lead dev. I don't mind getting out of tech but right now, I'm here, and I enjoy the tech and I enjoy trying to get a project back on its rails and get to an MVP.

How long were you doing that and how did you leave the company. Meaning, you probably have a lot invested in them and they in you, how do you make that exit as soft as possible for both parties?

Nearly eleven years, since I started the business. they invited me to leave.

To make it soft for them I'm tied into two years of covenants, and sold my equity back to the business for about a third of its value. For me, that means I have time and money, and no idea what to do with myself just yet. Could be worse - but it feels damn strange to no longer be part of what became my entire identity.

The tracers over prototypes advice is a precious one. Having worked for small and large companies, once you have a functional prototype that has been built quickly, managers tend to be very reluctant to let you rewrite the prototype architecture to make it clean. Using tracers you can demonstrate small but important features to the persons involved in the project and when the project will be given the go sign you can work peacefully on the product's architecture.

Urgh, yeah. I've been burnt by the "prototype looks good enough" for a long time until I finally realized: I have to use assume I'll end up using it.

A fellow developer mentioned to me on slack that he calls it a "probe" which is just so much more fun to say and use in conversation.

I had a friend who worked in product design. He says their analog was to never paint prototypes. For some reason, when they demoed painted versions to clients, they assumed they were basically done. It didn't matter how much actual work the design firm still had to do!

I haven't really experienced this, also having worked at both small and large companies. At the small companies, most of the prototypes failed (which is the whole reason you're prototyping) and then the ones that succeeded usually got rewritten because everything got rewritten multiple times. At the large ones, the prototype exists to convince a VP that this avenue is worth pursuing, and then typically it's handed off to another team to actually do.

Could also be because I've basically always had technical management, and the projects I work on tend to be fairly technical in nature (i.e. "can we do this?", not "the customer wants this by Monday").

That might be the reason but it really depends on company culture, funding, and other aspects. I built an early prototype for our product in the first two months. Losing two months wasn't an option for a rewrite. Even if I could get it done in a month, it just didn't make sense. The prototype was "good enough" to the point where it stuck.

I'm unfamiliar with the "Tracer" concept. Can you provide an example of one of these you've built?

I'm specifically curious how it differs from a prototype... is it just a prototype of 1 feature in isolation with bare-bones design? Or some feature that is only triggered from an arcane terminal command?

Thanks

Just chiming in here: in The Pragmatic Programmer it's called a "tracer bullet", not a "tracer". You'll do a lot better searching for discussions by using "tracer bullet".

Okay, thanks. Just curious to hear some actual examples of this from people who've used the technique.

Nice article. There's one paragraph that exposes a certain bit of web dev mindset that rubs me the wrong way:

"Updating things as you go also means that parts of the application that get less love tend to be written with an older style [...] and using older technology (like indexOf rather than contains or a for loop rather than reduce)."

That's not "older technology"! You're talking about whether to use some helper methods on Array.prototype. Who cares? It's certainly not any kind of technology choice.

It's really no different from whether you prefer to put your opening curly brace on the same line as an if sentence or the next one. Sure, it's slightly annoying when someone does it differently, but you shouldn't spend any time bikeshedding your codebase over stuff like this.

You're completely right! I meant to say that some parts of the application are written in an older style that we don't use anymore. For loops, indexOf, etc. are valid and there's nothing wrong with using them, we just use a more functional approach now and use some of the newer methods for doing the same thing.

I don't think this is necessarily a wrong thing; I feel like really ground breaking/challenging development forces you to understand what you are building the farther you go along.

It's always ideal to have perfect code the first time it's written, my experience is that this is never going to happen unless you have perfected what you are building to the point that you have code generators/boiler plate code to cover most of what you are building.

With that said, very interesting article. Thank you for sharing your experience, it is very eye opening for me.

I like the Tracers concept.

As for "everything is legacy a week later" - why not stick with boring but proven technology and frameworks for software that is crucial and you plan to have around for awhile? That may mean not using most of the JavaScript frameworks that are being pushed today. Sure, play with them for smaller or non business crucial stuff but why risk building a business on that instability?

There are so many other important things that a business or startup has to focus on, spend money on, etc. I guess I prefer to put a lot of resources into those things vs worrying about having to update or re-write my tech stack every few months on the latest shiny framework.

I picked knockout about 3 years ago because it seemed stable then, officially supported IE and had good docs.

3 years later I'm still using code I wrote against it (though now with browserify) with no changes.

The switching cost when you can dump the old framework on every new project is much lower than the "This will be around for 3-7 years".

Now I follow what is happening in the JavaScript community but I don't consider using anything until its been out a year and is still active/growing.

Much of the churn seems to be throwing out everything for an incremental theoretical improvement, that rarely pays off in my domain.

Excellent article! If no one else tells you: i appreciate the time you took out of your business to write this up. This is some really helpful advice. I have a full-time day job, and am trying to get my side business to launch as my only job...and I can certainly learn from experiences like the one you described. Keep on truckin' with these types of posts, and good luck to you!

Thank you!

Some of these things seem so self-evident but they were hard lessons. I've come to understand that there are a lot of business practices that just don't make sense to me until I get bit in the ass by not following them.

"For smaller projects like microservices, isolated applications, even parts of the UI that most users don’t see, experiment."

I agree with this part 100%. We're still rocking BackboneJS that we chose in 2011 or so. Sure it's behind the times as they say, but it's rock solid for our uses. We're in too deep to convert now and the cost doesn't outweigh the benefits. Clients are happy and we're happy.

In other newer areas, we're experimenting, mostly with RabbitMQ for small things on the backend and React Native on Mobile. With UI on new projects not in the core web app, we experiment. Works rather well and keeps us sane with the pace of JS frameworks.

Your account of the state of JavaScript in this decade reminds me of this post from a few days ago: https://hackernoon.com/how-it-feels-to-learn-javascript-in-2...

I'm actually not a big fan of that article :/ or rather, I disagree with it. I've been meaning to write my own piece on it.

But the summary is: you can make it as easy or complicated as you want it to be.

And I mean, every technology has the same issue. Take PHP for instance. Want to learn it? Cool, it's super easy. Want to build an app? Okay, so there these different frameworks. Oh btw, you should know about composer. And autoloading. Did you also hear about DI that Symfony uses? etc. etc.

This strikes me as the type of app that would be fine in Rails/Django and much, much easier to develop, maintain and enhance.

I'd reserve Node/SPAs for 1) realtime or 2) UI/UX intensive. Landdox seems neither.

I was the first engineer hire at a small startup, and have helped our CTO/Co-founder grow the company over the past 3 years.

All I can say, is that almost everything that was said here was the exact experience we had. Even down to the choice of Angular 1.X and rewriting all of the IIFEs in our codebase to use ES6 imports with babel.

I also need to acknowledge that PM is something that you do fine with 2 people, but your processes will fall apart, probably as soon as you even hit 4 or 5 people.

"issues with Javascript today is the idea that we have to keep learning the latest technology and keep using it. "

I don't get it. Why? For ISV it's the product that matters. ESP:s might as well invent filler to charge the client but what does it help in creating a product with JS to run after the bleeding edge?

Usually we pick up a language and toolset, write the product with it, and if there are bugs that absolutely need to rearchitect some foundational things then then, only then is it worthwhile to ponder if some basic technical constructs need a major overhaul.

This "update to latest hot as you go" sounds like velocity is lost in trying to adapt to some new gimmick for no benefit.

Obviously there is some cost/benefit tradeoff here I'm not getting. What is it?

The end of the article feels like a cliffhanger for a CI-CD sequel.

The amount of real-world experience you got from this I'm still trying to get. That to me is the value of being in tech at a startup. I enjoyed this article, thanks.

Minor typo here: "When we switched to ES2105"

Not a typo. It's a stage -10 spec, it's so far out into the future that no one has thought of it yet and the people to implement it haven't been born yet.

:) thanks. I'm fixing it!