3 years as a CTO - Another follow up
For the last couple of years I have been writing a yearly post talking about my experience as a small company CTO. You can check them here. As last time, I got some very interesting comments, some thoughtful DMs and some nasty responses. I said it last time and will say it again, if you don't find these posts interesting, downvote and move on, no need to be an asshole. You never know what others are going through.
So let's get to it. Long story short: first year was shitty, second year was less shity, third year has been slightly shitty. First year was a constant struggle with the former head of product and an outsourced team, eventually having panic attacks and wanting to quit. I fired the outsourced team and the head of productdecided to leave on his own. Second year was better, hired some great devs I can fully rely on and tried to create a healthier organization.
This third year has had it's highs and lows. The goal of this year was to build a new MVP for a new product we want our current clients to adopt. The development team has proven to be more than capable of achieving this goal, but we have been constantly slowed down by our new product team. This new product team is the result of hiring a new Product Owner that's very good at his job but keeping as Head of Product a boomer that's been on the sales team for years and wanted a promotion. This guy convinced the CEO he wanted the product leadership role without any other experience than being a sales rep for 20+ years . The result hasn ot been great and has caused lots of friction between him and my team, but also between him and the new PO. As a sales rep, his role has consisted in constantly pushing the team to deliver while not providing any kind of priorities nor making decisions about the product. At the same time he has prevented the new PO from making any important decissions and has systematically dropped most ofhis ideas. He is the kind of guy that does not want to make any decissions just in case anything goes south. In parallel, he does not rely on anyone else making decisions.
We were given a year to build this new MVP and for the first 9 months we barely did anything. I pushed this guy to make decissions, bypassed him and made those decissions with the other PO, argued constantly about how I was doing his job and suddenly it all stopped. He started being defensive and putting spokes in our own wheels. SOme of our devs started to speak up against him during meetings. Sprint plannings were miserable as the priorities where non-existent.
One of the greates examples was the decission to build a chatbot within our product (yes, again) that connects to ChatGPT and answers questions for our users. That would make sense if at that point we had had anything to answer questions about. It was a greenfield and almost no business logic had been developed at the time. When I confronted him about this decision his answer revealed what I already thought: he is a sales guy. He said "this will help us sell the product because everyone wants AI". First, I doubt that. Second, at these early stages the goal is to prove your product works and solves a problem, not selling.
While all of these was happening I was requiring the CEO to get this guy back to sales, where he should have always stayed. We've been discussing for severalm months that the product team should not be under his chair but mine. Our CEO does not have previous experience developing software so his POV is really far from reality.
In any case, the team kept somehow delivering and the feedback we have gotten so far has been quite positive although no sales yet. In any case, my team has decided to bypass the head of product and work closer to the other PO, who's been great so far. I also work close to this PO, and he is scared his boss is not happy about it, but I am working to protect the guy.
One of the toughest struggles this year has been the Claude Code hype, and I am already echausted. I don't want to sound like AI is the worst. I don't want to sound like I believe in software craftmanship. For me, software development has always been a job and any tool that makes it easier will be welcome. But, there are some problems that come with these tools.
- I do believe Claude Code makes developers faster. It has it's problems, but overall, it's working fine. My main concern with this tool is how it's being pushed as a KPI. The more tokens we use, the better. It reminds me of how, when I was very junior dev, a very old-school company I worked at measured our performance based on lines of code. The result was all of us changed our coding style and started adding empty lines and brackets in new lines and all kind of stuff that made the code worse. It's the same with tokens.
- Development speed has increased so the cost of development has shifted. It's not a matter of adding more, but prioritising according to the actual value users and clients will see. We can now prototype faster than ever to prove if a solution will work. The cost of delay has shifted from delivering slowly to delivering anything. A good Product Owner needs to know what to prioritise and that means dropping other things. When speed is no longer an issue, direction is. For the first time in my career my development team delivers faster than the Product team can define new features. This has taken us to develop low priority items that were there in the backlog. Add that to an incompetent head of product that boycots anything we try to work on. Not great.
- Collaboration is a must and devs need to be part of the cycle from the very early stages. AI is also isolating team members. Instead of asking for a second opinion we tend to ask Claude and asume it is right. As the cost of prototyping has decreased, one thing that's working wonders for us is meeting with the PO and our designer and discussing a feature on paper (or a digital whiteboard) and then spend a couple of hours building a prototype to show it in action. We then show the prototype to our designer and PO and either they approve or suggest changes. Once everything's clear, evertyhing's written down on a ticket and worked on from scratch and in a couple of days most it will be developed.
I don't want to sound like I know what I'm doing and others don't. I also messed up big time during this past year.
I had to let go the first developer I hired when I joined. He is a great guy, capable of the very best, but was struggling delivering. I tried talking to him and bring him back on track during almost six months but at some point other team members were tired of his performance and had to fire him. I still question myself about it. Not about firing him, but if it took me too long. Another one of the devs is very picky about how we structure our code and can be very strict when approving PRs to the point of rewriting features from scratch to prove a point. I had to sit down with him and ask him to stop because most of the times he was making a fuss over minor details. This did not really work and now he is being passive aggresive against his coleagues, which is not great andI'm afraid I'll have to seriously talk to him about it.
The biggest failure over this past year was not achieving the main goal. We were given a year to deliver an MVP and it's taken us almost 2 extra quarters to deliver it. I was explaining the CEO just the other day that the main issue was trying to goldplate everything. An MVP is an MVP and both, product and development teams, did not want to release because it was not ready. Looking back, we could have delivered and granted access to our existingclients forfree and most of the feedback we arenowgetting we would have gotten earlier. There are many things we developed assuming our clients needed that are now being rolled back.
Another big fuckup took place almost a year ago. We wanted to implement a workflow manager to allow users to program automations within the product without the need to code. Think of tools like make or zapier. It is quite a complex task and we did not know where to start at. I suggested we took two days and make teams of one frontender and one backender to prototype a solution. They competed, each team had a different approach and at theend of the day our Head of Product did not understand why the feature was not in prod yet. I was clear (or at least I thought I was) this was a prototype and anythig done during those two days would be discarded and started over, but of course they wanted it to get to production. In the end it took us a few weeks to have a first, very poor version of it, but truth be told, it's really easy to add new "boxes" to it, so new developments take a couple of hours (maybe a day or two if the inner logic is complex). This might sound like a win, but at that time it caused frustration and confrontation between product and development to the point we have forbidden the use of the word "hackathon".
As usual, some pieces of advice and some things I regret:
- Technical leadership is people leadership. We usually think a technical guy willnot manage people, but at theend ofthe day it all comes to agreements between developers. Managing egos (including our own) is a skill.
- When something's not working, act fast. Letting people go when it's right will be seen as strong leadership. Waiting until things are all fucked up will only cause more damage.
- Fail fast is a state of the mind. AI allows to prototype fast, but it comes with a new skill to learn, which is explaining those prototypes are not deliverables.
Anyway, interesting year. Better than the previous one, but also more exhausting. I really hope this helps anyone that's in a similar place. I'll read you in the comments. Be nice.
TLDR: Third year has had it's struggles, I have developed a love-hate relationship with Claude Code, but overall it's been better. Still learning though and I wish I was rich and did not have to work.