Preparing next year as a CTO

Aliénor Latour
7 min readDec 27, 2023

Episode 3 of my CTO series, about yearly goals and how to stay on track

find previous episodes: -1- and -2-.

Mid-december, I finished my 3rd month as a CTO. On the day I joined, I attended a presentation about the milestones of Journey 3, the last 4-month period of 2023. You can imagine how much of what was said I deeply understood with my 3 hours of experience on the job. It was not a case of having too many questions, but one of having too few: I was missing the story, the background, the amount of work implied and the depth of the problems we were trying to solve.

3 months later, I am now finishing the hardest time of the year, as clients wake up with last-minute before-the-holidays demands, users wake up to spend all of their expiring budget, we are still struggling to release the new version of our app, and bugs from last-year reappear with a vengeance. One customer-facing colleague told me on December 14th about a bug from 2022 that would be impacting our entire user base, “by the way did you know?” Trivia time.

When my health started to send me signals around the middle of the month, I took the saving minute for myself: I needed to reduce the noise, for the sake of my whole team. Reduce the hundreds of so-called priorities to a handful and tell the world that we would refuse everything that was not helping them directly. Cut deep into all the varied subjects. Make all our lives more zen. That would be my North Star for the next year. Good thing was, I was already on the way. Here is how we are proceeding.

My visual representation of what I am trying to build: 5 cylindrical pillars in rainbow colours, each composed of three segments for the three journeys, support a rectangle labeled Goal for 2024. Underneath, a zoom on a segment shows that is it itself segmented into short cylinders for milestones, and each milestone is like a thick pie where each slice is an initiative. It does make sense in my head.

Company-wide strategic pillars

In November, the steering committee, composed of 8 people, gathered for two half-days of discussions to frame the goal for the following year after some alignment with our main shareholders. We drew 5 main pillars that would orient our strategy for the next 12 months. As CTO, it was the one occasion for me to push forward some refactoring, security work, and more generally speaking, reduction of the technical complexity, all the subjects that users don’t see directly but make the platform better.

Let me give you only one example, because I believe it is an important mission for all the startups of the world and it impacts the tech team most: increase stability and scalability. Usually not something you want to admit you need, but every company that has survived 5 years by making U-turns in its product definition and is finally on to something useful and sellable will have to go through this phase. (On a side-note I actually wrote about it years ago, and I am happy to see that my theory holds).

The title of each pillar is wide and blurry. We brought these pillar titles and the spirit of them back home. Time to turn that into milestones, as we call them.

Photo of pillars in a calm cloister by James Kemp on Unsplash

Tech-level milestones and initiatives

As I mentioned, we at Skipr work in 4-month Journeys. We define milestones that we want as few as possible, to avoid spreading the team thin, and to avoid exactly the cause of my pain in December: too many subjects, all of them important, difficult to prioritize, and the stress rises and the people start falling ill. No, thanks.

I had gathered a lot of good ideas from the team in the previous weeks, which helped fashion the 5 yearly pillars and were now to be turned into initiatives for the end of Journey 1 in April. Improve observability is a good example: while we have a self-hosted Grafana, it only shows a handful of business metrics that not everyone knows how to use, not because they are not documented, but because the documentation is actually too long to read, funnily enough. Nobody ever sat everyone down to list what was needed and what was not.

So we have the milestone, what are the initiatives? Make sure that Prometheus is plugged to Grafana? And then what? Create a dashboard with the platform’s health indicators? Better, but where do we stop, what do we chase after and what do we omit? Display 15 technical and 5 business indicators? That’s what I chose. Remember, it has to fit on a slide for shareholders to get a grasp ofwhat we are working on. This is typically a situation where we have the tools, we just never took the time.

Another milestone is Reduce cloud-provider costs by N%. It can be seen as a bad sign that we want to pull the costs down, which is not something you do when you’re scaling up. It comes from observations that we are wasting resources in a handful of different ways, so cost reduction here is a way to prepare for scaling better in the second half of the year.

Photo of a pillar capital where a person in robes is sitting on a wolf, holding 3 fish in their right hand and a baton on the left, directing a bearded archer to shoot a knight riding a sheep? by Micky White on Unsplash

Decision process

I first met with the CPO because what we decide will be executed by the same people. We drew a first draft of the list together, based both on our own understanding and what the teams had told us.

Second, we added product managers who are responsible for product discovery and prioritization within the two teams, the Head of Engineering, and the tech leads. Currently, that makes a grand total of 4 people, as recruitments are in progress and most of us are holding multiple jobs, so not a crowded meeting.

Once the initiatives were drafted, I gathered some feedback from the most senior developers. None of them were surprised by the contents, good news. It was also an occasion to ask them to think about which of the subjects they wanted to lead, without coming to a decision yet on a list that was still a draft.

Finally, once the milestones are SMART and the initiatives defined, there will be a session of alignment with the rest of the steeting committee to make sure that we all go in the same direction and we will announce the decision.

Photo og train tracks and pillars by MontyLov on Unsplash

How to stay on track

The plan now is to name a leader for each initiative. Any senior or above can be a leader. Considering the small size of the team, any mid-level can be a leader as long as they have the proper support.

That leader will have to:

  • Write a short explanation of what we want to achieve and why. Short, but longer than a line on a slide.
  • Gather people to refine the solution. By people, I mean a subset of developers, project managers who know how clients will be using the feature, anyone at all who can bring something to the table and will benefit from a better understanding of what we are building. This can take any form but needs to start with a synchronous kick-off meeting.
  • Write the findings and the decisions in a document, in the style of an architecture decision record or an request for comments. Make it concise, the target reader is the developer who will join in 2 months, but also me or anyone who missed the discussion.
  • Present the work to the management (CTO, CPO and Head of Engineering) to get a green light. In fact I hope to attend all the refinements as we are learning this new way of working, but ultimately I will only need the conclusion.
  • During the development, identify the blockers and either remove them or get help in removing them, the sooner the better.
  • Communicate via status updates. It can be regular meetings, Slack messages every week, updates on the document for asynchronous updates, anything, as long as I can know where we are and confidently answer stakeholders when they ask me what’s going on.
  • Send kudos to the rest of the team. That’s a plus, but any chivalrous deed that should be sung from any member of the team is part of the communication I expect.

What I would like to do better next time

The exercise is not finished yet, but I would like to start earlier when we do it again, so that we can hit the ground running on the 1st of May when we start Journey 2. I have a feeling that we will spend the whole month of January refining and will only be able to start the actual work in February.

I also hope that people will have better understood the idea behind this new way of working by then, and will all be convinced to follow it. Autonomy is the target.

Even though I gathered people’s opinion and ideas before joining the rest of the steering committee, I would like the process to be less of a top-down deal-with-it decision.

I know there will be other points on the list above that I will learn to improve in the upcoming weeks. Hopefully, in 4 months I will be writing that we are all very peaceful now and the raucous commotion of December is just a fond memory. Stay tuned!

--

--

Aliénor Latour

CTO at Skipr, co-author of Learning Go with Pocket-Sized projects. Wants to learn from wide diversity. White, cis, abled, French.