Roast Me
I’ve been a lousy CTO
I knowingly did something that I know no good CTO should ever do. So, shoot me with the best you can! (If you also have some good advice, that would be more than welcomed, too :))
Disclaimer
For privacy-sake and also to make reading this article less boring, I waited enough time so it’s not recent history and I also altered some details from the story. The core of it is true, but it’s embellished so that it’s not exactly what happened. Nevertheless I think it will work as something to reflect and learn upon. Like one of those Based on True Story movies.
The Setup
I’m a CTO, so part of my role in my company is to help developers when they’re stuck with some hard task. Another (prior) part of my job is determining the different tasks involved in a project and estimating how much each of them should take.
I’m an Erlang developer, too. That’s actually how I started in this company, then I slowly transitioned to my current role over the years.
This story begins with a brand new project that involved an Erlang server. Two developers and I analyzed the request, planned the project and estimated the tasks, as we usually do.
Our proposal was approved, a team of developers was built and a Project Manager was assigned to the project. Since the Erlang part was far from easy, I oversaw the project development on a daily basis, jumping in and out of it, partaking in small pair-programming sessions with the Erlang developers, discussing architecture decisions, etc.
At some point, it was clear that, for a particular task, we needed help from a specialist. Luckily, we had one at the company. The Specialist then jumped into the project with little to no context of it, worked on the hard task and solved it in a perfectly well documented but rather complex way.
How Everything Went South
If you already spotted some causes of concern in the previous paragraphs, just wait: the worst is yet to come.
The thing is, since The Specialist was already assigned to this project and he did a great job with the task he implemented, he stayed in the team after he was done with that. But of course, he was never fully briefed about the project. The project manager just started assigning other tasks to him, some related to what he had worked on originally, others not at all. And, to be clear, this was something he discussed with me and I agreed it was a good idea.
The Specialist then, being a specialist and all, couldn’t figure out that some tasks were not deceptively simple tasks but actually simple tasks. Like really really simple CRUD endpoints in a REST server. Those tasks were assigned to him not because he was a specialist, but because he didn’t need too much context or knowledge about the rest of the project to understand them.
The Specialist proceeded to work on them as if they somehow required strange optimizations or super complex pieces of logic. That way, he invested a few days in a task that was estimated to take no longer than one.
And he did that not once, but multiple times. After the first task in which the PM and myself detected this behavior, we had a talk with him and explained the situation.
After the second time it happened we had another conversation with him and finally agreed on 1 pull request per day strategy (with WIP tag if necessary -the project was kept on gitlab-) which he followed correctly for the next tasks on his plate.
But then, some days while reviewing his code I had to remind him that he should not complicate nor optimize stuff unnecessarily with the only effect of finding that code simplified the next day along with another bunch of new super-complex code along with it.
I must state here that these tasks were not consecutive. Between them The Specialist got a few other simple tasks that he actually implemented in a simple way and within estimated time.
Something that Shouldn’t Have Happened
At some point, after several rounds of what I described above, The Specialist was assigned a new task that actually involved 5 small sub-tasks. PR-a-day rule still standing, he started working on that.
A week of work and lots of gitlab comments later, he had implemented 3 of the 5 sub-tasks, 2 of them a bit overcomplicated and the last one not just overcomplicated but entirely wrong and not at all in accordance with what was discussed with the client team.
At that point I did what I think was the worst mistake I made in this whole story (and you might have found many mistakes already): On a rage, I kicked The Specialist out of the project and took over from him. I basically dropped all his code for this 4th task and I started implementing it myself.
The Outcome
It took me 3 days (a bit less than originally estimated) to implement that. But that shouldn’t be considered a good thing: those were 3 days in which I didn’t work as a CTO at all. And if you add all the days used to write the code I dropped it actually accounts for more than double the estimated time for the task.
Roast Me!
I have already identified a couple of things where this went wrong, several bad decisions or practices that I (and my company in general) already improved or we’re in the process of improving. I won’t list them out here because I don’t want to condition your comments. I might eventually write a comment with my own view on the subject, but for now I would like to listen/read what you have to say about it.
Ask me anything!
Let me know if you need more data to evaluate and/or form an opinion on what happened. I’ll happily tell you more about it, if I can.
Criticise me!
Tell me when I was wrong and what I did wrong. I want to learn and improve, so hit me with the best you have!
