Programming Rambling

mrzard's ramblings in the wild

What I Have Learnt as a CTO

| Comments

When May comes to and end, I will end my one and a half years journey as a CTO for

The reasons for my depature are diverse, and possibly this is not the best place to discuss them, but I am very grateful for the opportunity to grow and learn while developing a project that has the potential to be something special.

During this time I have gained a lot of experience managing teams, and learnt a lot about myself, specially when it comes to working with non-technical people, and how to manage expectations, deadlines and organisation when working in a very fast-paced and very improvisational startup.

I will write a list of things that I have learnt, in the form of:

  • List item.
    • How it has affected me personally.

Things that I now know I have to improve on and play a very big role in being a good CTO:

  • Voice disagreement and take a stand when needed
    • Sometimes I have voiced disagreement with decisions by just making the Product team know I was against the decision made, but not stating why and how I could give a better solution.
    • When I feel a decision is plain wrong (not just a difference in opinion) I have to stand my ground and not budge.
    • Don’t be afraid of denying requests if you can back your denial with data.
  • Find a sweet spot between being hands-off and hands-on
    • When handing out tasks I tend to plan them, and give them to someone on my team, then just wait for them to complete it. However, if they get stuck and ask for help I tend to sweep in and almost take over development. I have to improve because this, rightfully, can enrage senior developers, as well as be a hindrance to junior developers’ learning.
  • Be less aggressive with estimates.
    • Most developers underestimate how long tasks will take, or the number of interruptions that will happen, and I am one of them
    • An estimate like ‘3 days if I can work full-time on this’ is useless when you positively know that you will be able to put only 40-50% of your time in it. Say 7 to 9 days right away, because all your counterparts will remember is ‘you said 3 days’
  • Involve yourself in strategic decisions.
    • I used to see myself as the technical element for a business. Now I see myself as the technical bridge for a business. I have to take a more direct approach and influence on the product side, become a domain expert so I can really understand the business needs and choose the best technical solution more easily.

Things that I think I got right:

  • Protect you team.
    • Your team should not be interrupted by anyone. Concentration is key.
    • Success is result of the team being awesome, or a team member exceeding expectations.
    • Failure comes when we as managers fail to provide the team with the right information and opportunity.
    • Basically, as a CTO, if your team succeeds it’s because they are awesome. If they fail it’s because you did not do your work.
  • Install a ticket-centric culture.
    • No ad-hoc requests, everything has to go through a ticketing system (i.e. Redmine).
  • No premature optimization.
    • We did not worry about going too deep into performance until we had a decent amount of functionality and traffic going.
  • Try to find a ‘good-enough’ solution, and keep improving it when it’s no longer good enough.
    • Finding the perfect and definitive solution might be tempting, but when you work tight schedules, with the possibility of last-minute-changes on every turn, learning to recognise good-enough solutions will save you and your team tons of frustration.
  • Trust your team.
  • Always listen
    • There are no stupid questions.
    • There are no stupid suggestions.
    • Not everything has to be decided by the managers.
    • The idea that makes your business might be that one you didn’t want to listen to.

In a nutshell:

  • Measure everything. Try to improve. Rinse and repeat.
  • Build a great team. Trust them to do wonderful things. Assume they are awesome, let them prove you wrong: Most of the time they will not let you down.
  • Lose the fear to say NO.
  • Be kind, encourage the people around you.
  • Be honest, especially when it’s difficult. Dishonesty brings doubt and drives a wedge between team members.