This is the first post of a series that will talk about my experience in transitioning from a pure software developer into a leadership position (specifically being a CTO, more on the cursive later), what I learnt and what I wish I had learnt, and in doing so maybe I can help as well as learn from others. The views expressed here are my own and not subscribed by my employer.
My job title is defined by the acronym CTO, but many times I refuse to apply it, using instead tech lead or similar wording. I feel like I don’t belong to the role defined by these 3 characters. I’m currently a CTO, but could I be it in a company with 1.000 engineers? No, at this stage I couldn’t: there is still a long way to go. On one side you can call yourself CTO of your 2-person company, or you can call yourself Werner Vogels, and then all the individuals that fall in-between (hint: I’m certainly closer to the first case). On another side you will find individuals that will focus most of their energy on the public facing of the company, others who are completely product-centric and other individuals focusing on tech architecture/strategy and capacity planning. Or ideally you will find all of it in the same person. And maybe most of us use the word CTO indiscriminately and incorrectly, applying it to a variety of management and leadership roles in technology. So am I a CTO? Maybe this is not the question.
Anyway, how did I end up here?
I have always been a generalist; sometimes I wish I could say I have 10+ years in JVM-based distributed systems — specialisation is highly valued in today’s ICT world. I’ve been a front-end developer, a back-end’er, a “full-stack”, a native mobile dev and a creative coder. Worked in consultancies, tiny companies, small-to-mid agencies and free-solo’ed. Did an MsC with a focus on image processing and machine learning. And after 10 years of professional career I was offered a tech lead position transitioning to a CTO one. And I took it. Little did I know how ingenuous was I. But the learning has been so enormous that despite all of the pain it’s been completely worth it. And this series is about it.
Starting in the role brought in more frustration and failures than anything else. So unless you have a gradual progression to leading roles, embrace failure. I had no previous experience whatsoever in leading a team, so I had a lot to prove, not only to others but to myself too: firstly I had to prove that technologically I was up to speed and could gain respect in this area; secondly I had to prove that I had way more than that, which is to say, that I could do the rest of what the CTO acronym entails, which is the 80% remaining. All of this takes lots of time, energy, reading, trying and failing, and thus all of the processes and learnings that I will expose below are the result of experimentation, success and failure throughout this journey from a developer position to a leading role.
There is no magic formula, but the process I’ve gone through goes along these lines:
- Invest time (lots of it, and then more) into learning all the technologies that could define the company stack. Ask why, and repeat. Let your team advise you. And not only this, but learn the entire world, at least get to know it. You are not the best in something, but you need to know what’s going around, daily
- Be conscientious of your soft skills and focus on your attitude, your influencing on others, how you talk, what are the values behind your decisions, your handling of issues that affect people: be your biggest critic and again, read, read a lot
- Finally invest even more time into learning about business, the commercial side of things and product development. All those areas you didn’t even think about. They won’t be daily present in your first baby steps, but will end up inevitably be part of your every day decision making, and they better be
I have a cat, which has overly simplified the time I have devoted to this process. They say you need to invest 10.000 hours (not everybody: http://www.businessinsider.com/new-study-destroys-malcolm-gladwells-10000-rule-2014-7) to master anything. Obviously I haven’t put this amount of hours, but as in any learning process you need to invest a lot of your personal time, not only by using office hours you will make any progress.
So what does (should) a CTO do, IMO?
There are a few core pillars that I have found best define this role, whether or not you have a strong product team, whether or not you are accompanied by roles such as the VPoE or Heads of Engineering and whether you work in a 10 people startup or a 10.000 engineering team:
- Help establishing tech culture and values
- Technology architecture, planning, strategy and forecasting
- Help syncing technology with product and commercial expectations
- (Help) Hiring and measuring of teams/individuals
- Creation and continuous improvement of tech processes that ensure the realisation of the company’s value propositions (automate, automate everything)
- Setting of priorities together with product and leadership
There is a nice answer on Quora that explains what a CTO does, focusing on areas that I haven’t listed above and it is probably quite an on-point definition: https://www.quora.com/What-does-a-CTO-do
On the other side if you fall within the 2-person company area, you will inevitably also do much of the following:
- Software developing related work such as daily coding of features, bug solving and pull requests review
- Backlog prioritisation and short-term planning
- Direct hiring
- Daily involved in all operations
The core assumption here is that this role is not a static defined list of characteristics, but a mutating evolving role that has to adapt together with the shape and progress of the company. The smaller the company, the more focus on operations; the bigger, the more attention to strategy.
The biggest learning
I sit in between of both definitions above. When I started in this role I was coding most of my time, and 2 years and a half later you can find me coding significantly less, more focused on prototyping and setting tech directions on possible technologies to use (even though I still help adding new features!). I keep an eye on day-2-day operations, trying to free myself whenever I can to set the eye on the mid-to-long term, bouncing back and forth between the two perspectives as required. If I focus solely on the strategy for too long and not pay attention to operations, the company feels my disinvolvement; if I focus on operations forgetting about forecasting and strategy, then the failure is palpable as well. It’s a delicate balance that needs daily readjustment to evaluate where should I focus the most. We are currently a technology team of 7 people, not counting product nor design, expecting to grow up until 10 people in the forthcoming months. It’s small, but it has enough people to have some proper processes and pipelines for things to run as smooth as possible, being totally unstructured would kill us. And in this friction of perspectives, in this growth within the role, you will constantly battle and wonder where you should be putting your effort and specially, how to time-manage yourself without resorting to human cloning.
Through this journey of mine and from the questions above there are two elements that I have identified vertebrate my daily job and what is expected from me, namely:
- Getting out of the way as much as possible
- Being in the middle of everything as much as possible to facilitate dialogue and move things forward
Which is yet another friction that I need to closely monitor. The following graph illustrates the perfect sweet spot where everything would work flawlessly, but it’s so hard to nail it down:
While trying to find this spot I have also learned (in very frustrating ways), that burn out can easily be achieved and that one can’t do everything (and do it right), as well as be everywhere. One must learn to prioritise, to evaluate a personal plan in sync with that of the business, maximising the gains of one’s self time involvement by reevaluating the myriad things of your own ToDo at every moment, adapting them periodically to the different risks and mostly, (one of the tricky parts) planning ahead. Once the shit hits the fan, the only thing we can do is use as many umbrellas as we can, but shit will inevitably leak, albeit a bit. Focus should be in preventing the shit hitting the fan, period. There are many methods, apps, posts, companies and talks out there aiming at helping you organise your daily stuff. End of day you got to find your best method, and that is the one that lets you swiftly prioritise, replan, keep an eye on and execute your ToDo and priorities, instead of forcing you in investing time in the method itself, rather than the issues.
As a simple example what has worked the best for me is the following:
A) Create sections based on action status and create subsections as needed accounting for more fine-grained priority (i.e. https://blogs.msdn.microsoft.com/willy-peter_schaub/2009/10/22/getting-your-priorities-right-p0-p1-p2/). What I found key to track:
- Things that I need to tackle next / right now, in order of priority (p0)
- Things that will have to be done at some point, rather sooner than later (p2)
- Red alert issues (p0 to p1): those that will definitely be part of the first section but can still be postponed for a bit and deserve a section of its own
- Issues to keep an eye on: all those topics that are continuous in time and require evolution, usually solved in a few steps
- Backlog: issues that will eventually be tackled
B) Create at most 2 big overviews of strategy/capacity planning. Dot not overcomplicate it or you will never look at it after the first time you created it (at least I don’t), as it will immediately phase out with reality (similar to documenting code such as Javadocs).
- Mid to long-term big-picture: helicopter view of projects and areas to be tackled during the current and following semesters and/or year
- Short to mid-term projects: classify and visualise projects in areas that belong together, which can help in navigating your product backlog
Note that these lists can be shared with the product team, be a copy or just make someone like the Product Manager own them, having a side-copy for an own technology forecast, planning and capacity. This all depends on your organisation.
But as mentioned above, shit eventually hits the fan.. no matter what. How you respond is what matters. I am still learning it, sometimes the hard way. And this brings me to the soft skills side of the picture: they are needed and they should be one of your most precious qualities.
Couple of words on values
Leadership and management positions have an added responsibility within the overall structure of the organisation. Their actions and attitudes affect the entire organisation. Therefore it’s of utmost importance to reflect on oneself. Being your biggest critic will definitely help inspecting yourself on how you deal and how you should do better next time. There is no better way to learn than by failing, but it is really important that the set of core values are solid, otherwise it will be really hard to bring them back. I will talk more about values in the next post of the series, but it is clear that they are the vertebral column of a healthy company. For now I leave you with a preview list (kind of the ten commandments) that I have identified throughout my career:
- Vision — aligned with strategy and short-to-mid term projects and goals
- Empowerment and growth of individuals
If you keep in mind this list at all times the rest should vertebrate around it and you will be resilient to failure. If you have them wrong doesn’t matter what you do but it will feel more like patching around a broken core. If trust is broken it’s hard, very hard to restore it. I can tell you I’ve failed in them, and the price you pay is too high: we are not only job titles or resources working in a company, but people. Therefore invest time into fixing the values: once they are clear and reflect in every decision you and the company take, then the strategy, product planning and development, hiring, continuous deployment and delivery practices and you-name-it will be sustained on a solid basis and derive from them.
For now let me finish here. Next posts will tackle more in depth about values, on the transition from no to full process, on scaling the product and on key points that have helped vertebrate the technology team at my current employer.