Thanks for submitting your interest! The book will be soon available in Amazon and I will let you know. In the meantime, enjoy an excerpt of the first few chapters

Did you arrive to this page by mistake? Go here to learn more about the book.

The Playbook

How to read this Book

This is a collection of resources, methodologies, frameworks and tools I use or have used in my life as a CTO. They don’t work in isolation within the engineering team, or in individual teams. They require collective agreement from all individual contributors as well as executives and CEOs. Not all are applicable, neither are fixed “dogmas”. Each will require adaptation to each company culture, needs and resources and not all of them will be equally applicable.

In this book me, or some of my friends (and guest writers) will describe and explain cases for each of the topics so you have one (or several) frameworks on how to use or implement them, or where to learn more from. 

This is not a recipe for success or a mantra to take home such as “I will only work in Agile with TDD in my teams or die”. In fact those attitudes tend to be very dangerous. The goal is to have a big map of resources and tools so you can take the best tool for the job. Remember, if everything you have is Javascript, all problems will be await-async related.

The book is divided between the four main pillars or areas of work as an executive (in technology): Tools for Technology (management), Tools for Product (management), Tools for Leadership, Tools for Corporate and M&A, and finally a few notes on Tools for Taking Care of Yourself. Some topics permeate so take this definition as a fluid taxonomy. You can jump from one to another, and why not, add your own if you want. Take notes, read the recommended books, and create your own guideline.

Being a CTO is more like a “Choose Your Own Adventure” type of book (for those who don’t know those books, go ahead and get some!). The possibilities are endless but many of the challenges are the same. Go ahead and start going through the pages!

(Disclaimer: The views expressed herein are solely those of the author or authors and do not reflect the views of their employer or any other entity or person, neither the views of any other organization mentioned in the book.”)

I once had a (Technical) dream

I had a dream and it was great. 

I worked as the CTO of a thriving business. It grew organically and I was lucky to have amazing colleagues in the rest of the C suite. A super smart people-oriented CPO, an extremely KPI-oriented and attention-to-detail CMO, a technology savvy, but focused and long-term-oriented CFO and an incredible CEO whose job was basically… let us do ours the best way possible.

We didn’t have many shareholders or investors blocking our way. There was no special interest in increasing the stock price, selling early or a weird exit. We had no IPO plans nor buy-out strange strategies. We simply had a great product our customers loved and paid for, faithfully, month after month. We had enough cash to build what we wanted to build (failing sometimes, succeeding others), to hire good talent with decent salaries and to have nice offices with good perks… for those who wanted to use them. We even threw several parties per year, team gatherings and two big events that were part of the culture and not just some forced event that people go to unwillingly.

Our teams were organically structured. A fairly horizontal organization where technical people decided how we build things and product people decided what we build, but everybody’s opinion was taken into consideration. New features were considered based on user focus groups, surveys, and lots and lots of data. The developers understood why a new feature was needed, and who were their users. They knew the meaning of their work. Everything started with a very nicely defined user story that stated what they wanted to build, for whom, and why. And what was the real benefit of having those user stories? Not only everybody had the same understanding of what it meant, but it also  included acceptance criteria and then tests were built. In short: clear expectations.

Then developers started their work by dividing it into small chunks so they could once in a while (typically two weeks) demo to their stakeholders the results.

Those sessions were incredible because it was more a celebration than a meeting. Where everyone involved could see their efforts become reality. In some cases, there was feedback that was incorporated in future tickets, but mainly it was just approving what the acceptance criteria said.

Software was well tested and all the typical tasks of making builds and deploying them were fully automated. The same as the infrastructure which was nothing but another part of the code. Teams were cross functional so there was no ping pong balling and blaming others. Even though there were people in different locations and from different cultures, people were professional and human and understood each other empathetically and with compassion. 

Everything that was deployed was evaluated over time. Did something really make a difference for the user? Did it make us more money? Or saved us money? Was it helpful in the end? Regardless of the result we took action. Sometimes just removing the feature and the code. Sometimes modifying it. But in a blameless way. We just tried to keep learning and making our product and our team better over time. The same happened when someone messed up. Maybe with a bug in production, or sometimes with an incident that started calling the on-call DevOps to get quickly online and fix it. We are humans, we all make mistakes. We got into it and went methodically into what happened until we could forensically find out the original cause of the issue. Then, like a neurosurgeon we fixed it and proposed actions in a constructive way for something similar not to happen again. Not about the person but about the process.

People had autonomy to decide how to do their jobs. But most importantly, we all felt there was purpose. Even though we were not really changing the world with our product, we made a difference. Our users were happier with us, than with our competitors. Our clients were more competitive thanks to us. We did something that mattered and the leadership made sure this was crystal clear. Our team had one big personal goal as well, which was our own continuous improvement. Achieving (or aiming for) mastery. We put all the needed resources into that. Whether it was attending conferences, organizing courses or just moving people around teams for them to gain experience. Everyone knew what was expected from them and what they had to do to grow thanks to a clear career ladder (which was not linked with any salary review, since that was a pure benchmark). Managers, executive leaders and HR mentored people to grow and it was one of their main goals to make sure that everyone had something worth pushing towards. Both for the company and for themselves.

On top of that, everyone knew what the company wanted to do, what it was destined to do. Hell, not only they knew it but they participated. Everyone decided their own goals so they were linked and tied with everyone else. You could follow the goals from the last newcomer intern all the way to the CEO and say “makes sense, I’m working for that vision”. It was their own flavor of OKRs, and some things needed polishing but still people were happy.

Right. Then I woke up. And I realized that life usually is not as idyllic as my dream.

We, consultants, typically come with great ideas to improve our workplace, team and company. We read extensively and apply all those elements that appeared in my dream. We can imagine easy ways of implementing those changes. And it makes sense, after all it is not rocket science. We all know the autonomy, mastery and purpose adage, that developers need time to refactor, and to experiment properly. That product leads needs data and time to make decisions, that UX is key and needs to go first, that technological debt needs to be accounted for by the CFO, bla bla bla. So what is the issue?

The issue is that the realities of life don’t give us the benefit of playing with the whole playbook all the time. Each specific moment, maturity state, financial situation, owners, ecosystem and the world in general create a completely different reality that makes playbooks useless. What worked for me in the past is not likely to work again in the future. So the key is not “knowing” that you have to give autonomy to your developers to help them thrive, or that you must go slow hiring to avoid toxic people and to make sure that the company culture is slowly cooked. But to adapt that knowledge to the specific situation and choose from your toolbelt which options are the best for a given situation.

Is your company looking for a buyer and doing active due diligence processes? Are you a startup raising a series A? Or perhaps a bootstrapped company that has a steady source of revenue, but not enough to pay over the market salaries. Each situation tells you the hammer you need to use to hit that specific nail.

So much for the introduction of a book called “The CTO Playbook”. But here it is. 

So, a playbook, right? Do I apply this playbook by the letter? Everything you will see written here? Absolutely no, or better said, not at the same time. Have I always succeeded at applying everything in my toolbox? I wish! I learned (sometimes the hard way) that one size does not fit all and that the job of a CTO is a new one in every step you take. And I assure you, this toolbox will continue growing for as long as I keep working and I will keep screwing up for as long as I’m human.

Does it mean you have to agree with what I’m saying here? If that were the case, it would mean we engineers have reached the nirvana of agreeing with all possible methods, and as you probably know engineers are <sarcasm> not stubborn at all </sarcasm>. Therefore no. It is completely fine and normal to disagree, and if so I would love to hear about it! Perhaps I could add your notes and comments in the next edition!

My recommendation is that you should not agree with what you will read (here or anywhere else) without a critical analysis and comparison with your own reality. You should be skeptical. Question it, explore it deeper and negate it completely if you must. 

I just ask you one thing: Do not negate it straight away  just because it didn’t work for you in the past or because you simply have a different, potentially better way. Just consider it as a new tool to use (maybe?) only when the moment is right. Remember, different companies are different universes and you never know where and when you will need to do “that thing”.

Why this Book and Why Was it Written by Me?

How do you learn how to be a CTO? Is there any University degree, bootcamp or course out there? Unfortunately not (even though some Universities have tried, including myself). But can you actually make a program for CTOs? Actually, what is a Chief Technology Officer?

During my career of more than two decades in technology leadership roles I don’t think I have repeated my job description a single time. Sure, in most cases the common denominator was around “liaise with business, and coordinate a bunch of engineers to build stuff”. But the “how” and the context have always been different. 

I have been a technical co-founder that was the sole developer (And yeah, I had the CTO title… and in retrospect I was not a CTO), in startups that succeeded and that failed miserably. I have been “that” cofounder that scaled a company up to a handful of engineers until we needed somebody more senior. Then eventually I was that senior person who replaced such a former CTO and took the business to the next level. And then at some point I sold a company, and then two and I was dealing more with investors or buyers than with code. I still have a ton to learn, hopefully I will keep learning until my brain does not work anymore. But at the same time I’ve seen a lot to see at the very least, what does not work.

What is a CTO? What is a VP of Engineering? What about a CIO and a CDO (D as in Digital)? How about Innovation, AI/ML, Infrastructure and Cybersecurity, IT, Technical Ops, etc.? Those are very related yet represent different hats and skill sets. How about a CPO (as in Product) and what is the relationship between all those roles? Is there a place for a “CTPO” (no references to Star Wars please). How do you navigate that complexity and make strategic decisions on that?

It’s all complicated. Especially if you are an engineer like me who has a passion for building stuff with code. “Just leave me alone and let me code”. Not in vain, software engineering is one of the careers with the highest ratio of managers who go back to be individual contributors. We like certainty, deterministic outcomes. If something does not work, the problem must be between the chair and the keyboard. However when you become a manager suddenly you have to leave with the uncertainty of humans. The unexpected turns of the board, the mood swings of your CEO and the different challenges humans have (from supporting a team member that is grieving… but also has the key to deploy a critical feature in production, all the way to deal with works councils or unions).

And nobody teaches us how to do it. Only experience and failing many, many times, and ideally getting support from mentors, good managers, great friends and family. Or at least that is how it has been until now.

There are always two key questions I ask myself when deciding about a new job or interviewing. The first one is “What new stuff will I learn that will keep me on the edge”, and the second “If I take this job, what new career opportunities will it unlock afterwards”. (i.e. what will be the job after this one). Maybe you can think about it as your skill tree in an RPG. You do specific quests to gain knowledge, skills or experience in a given tree. And you think strategically about it thinking how far that branch can take you.

This is the equivalent of “where do you see yourself in 5 years”, but a bit more structured. And it has allowed me to go from startups, to scale-ups, unicorns and corporations. To raise my own funding rounds in my own founded companies as a CEO or as a CTO. To love my partners, to hate my partners. To liquidate my company or to get a decent exit. All the way to try to scale myself up as an investor, advisor or mentor.

In my companies I have gone through different industries and verticals. I have managed traditional web stacks, mobile applications, very heavy traffic and concurrency systems all the way to complicated Machine Learning workflows. I have worked in very legacy, on-premise systems and in state of the art, new stacks. And then I moved to new horizons where I was able to do more research than application in the realms of AI and Quantum Computing. I topped it up with training and education. You can only truly understand a concept if you are able to teach it. That is called the Richard Feynman method. So I have been teaching all kinds of classes at Universities, as well as appearing often in conferences and seminars.

I am definitely not the best one out there. I am not a “code ninja” or a “developer rockstar” (In fact I kind of despise those terms).  I have a ton to learn and I am more of a “Jack of all Trades” than a specialist. So it is very likely that you, dear reader, will know much more, and be much better than me at several of the topics discussed here. However what I try to bring is a holistic view when you put everything together. I don’t have as many flight hours doing TDD as some of you may have, but I have lived its benefits and know very well how to implement it in teams. I have also suffered from it so I can see when not to implement it or how to tweak it.

So, who am I to write this book? Well, I am just a CTO. And I have been putting together a bunch of tools, frameworks and ideas that typically have helped me on the job. I wish someone had given me this book many years ago when I had my first CTO gig. Or who knows, maybe I would have read it and said “this does not apply to me, I already know what I have to do” (Yeah, I’ve had my fair share of hubris). Either way I am putting a lot of learnings that I got over the years. Some came from reading books and trying to apply those concepts. Some came from trying out different things, failing and recovering. And some from learning from the best. Some of my good friends and colleagues who are my travel companions.

The CTO role will keep evolving and so should each of us. Some of the topics in the book will be greenfield and some others will be completely outdated. But the intuition remains. 

Hope you enjoy it! 

Sergio

The Hats of a CTO

Go out on Linkedin or any other job portal and take a look at “CTO jobs”. I’m sure this is not news to you but there is a completely different definition for each job offer and company you will see. CTO, VP Engineering, Director of Engineering, CIO, Head of Development, CTPO, etc..

Then you will see positions for a CTO to manage a team of… one, in a small startup (or a huge e-commerce company that outsourced everything!), and others to lead teams of 300 or 500 engineers.

Some positions imply managing products as well, some others report under the CPO. Some have a seat on the board, some are relegated to the dungeon where they should not speak at all. Wherever you look you will find technology leads, and none of them is alike. But if you were to put them in four buckets you can typically find 4 “hats” you may have to wear..

The hats of the CTO are usually the following:

1. Lead small teams. You know your technical trade and are, to some extent, hands on.
2. You lead a much bigger team where being hands on or even making direct decisions on the code or architecture is a dream. Your job is to empower your team to make those. I.e. You are a manager of managers.
3. You have a seat on the board, speak with investors and are a key component of the strategy of the company. You speak business
4. You are a quintessential part of the board and the investors group. You participate actively (or even lead) M&A processes, funding rounds, etc.

This does not mean you are completely outside of technology when getting bigger teams or focusing on business or corporate tasks. You may still be coding on weekends or even find some time during your workday. With the first hat you will be coding a lot, maybe you are even the technical co-founder and only “coder”. When your team grows you put on hat two (and beyond). Here you should let your team do the thing. But as a technologist you still need to keep updated and trained. It does not mean each of the hats are isolated or linear steps. Normally you will grow from one to four, but in reality they are more like gradients, or in specific situations you may be touching parts from different stages. As you grow in your career you will find yourself doing more of the last points than the first.

You can of course move from one step to another. After selling your company and completing your vesting you can go to stage one, or even move completely into business as a CEO or GM in another company. In fact, to be in stages 3 and 4 you need a level of business acumen comparable to your peers in the leadership team. You need to know about corporate finance, marketing, product and general management. 

Do not see those stages as steps in the game. The goal is not to become the biggest CTO in the world. In fact you can have a pretty good life in a normal company with just a handful of really good engineers who know each other, where you build awesome software and evolve with technology. See those stages as a guide on where you are, where you want to be, and the things that you will need to know and deal with as you move from one vertical to another. If your company gets acquired and you have a bigger scope, you can come to this book and see some of the things awaiting you. A headhunter contacted you for a role that seems a bit above your paygrade? Check here what things you may be missing.

As the industry evolves, so are we and some elements get more standardized. But as of today you will be applying to 20 CTO roles on Linkedin and in each one of them they will expect something different. Guaranteed.

Tools for Technology

Full DevOps philosophy following the “4 types of work”. 

They say the two most difficult things in software are “naming things” and “purging caches”. But the reality is that one of the most complex challenges technical managers have is about estimating tasks and coordinating them, in a world where the rest of the executive team seldom knows the implications of what is behind and what it requires.

One argument I hear very often is how sales, marketing or operations teams are easy to measure and track. How their plans are sometimes water tight (not always!) and how easy it is for CEOs to follow up on that. Whereas with engineers we get lost in jargon and things like “technical debt”, “Infrastructure changes”, “CI/CD” and other stuff that usually means nothing to business. We don’t have the right translation options to express the internal dependencies of processes and projects and the hidden work that typically goes associated with a visual feature, or the implications of improvising or lack of planning.

In that sense, Gene Kim talks about the four types of work (The Phoenix Project, Kim 2013). Every type of work can belong to one of these buckets: business projects, internal projects, operational changes, unplanned work. This is related to the theory of buckets that I explain in another chapter. But basically you have fully autonomous teams where there are no dependencies and at the higher level of the company you can divide what level of effort you want to dedicate to each of those buckets. Business projects represent all the work that brings very specific value to the company’s clients: features on your products, a completely new business line, enhancements, etc. Internal projects are all the tasks and projects that are core to the company but not necessarily a product per se. A CRM implementation, an internal ticketing system, order processing software, etc. Usually the things clients don’t see but in many companies are below water in the iceberg.

Operational changes respond to everything that needs to be done to support the above. For example a cloud migration, or a new testing framework. Upgrades in the infrastructure, cybersecurity considerations, etc. And finally unplanned work is everything that, well, is unplanned. The “last minute thing – please can you do it now” stuff that is more urgent than anything else.

Those buckets are just one method and you can create any collection as long as a) They are discrete, don’t change and are very clear to everyone. And b) Everyone in the company agrees with those buckets and what they represent. For example, once you have a system like this it is very easy to measure how much investment the company is dedicated to supporting core functions, so a debate like “Should we build our own CRM or buy one off-the shelf” is not a debate anymore. When you measure this and you see how your unplanned work eats everything else and you can justify with numbers those facts… planning will become more important for everyone else.

The same applies to technical debt. TD is more debt than technical, therefore it starts with the CFO. But CTOs need to be able to speak the same language:  Excel spreadsheets.

Once you have your buckets you can have quarterly reviews on priorities and create estimations (or even better, limits) on how much you want to spend in each type of work, and slowly measure how the tide moves from one to the next. But this is not enough by itself. In order to measure the types of work, they need to be independent and autonomous, i.e. have no dependencies.

(Image by John Cutlefish)

Many companies would divide the Engineering (or IT, or P&T) work in: Design, Development, QA and Systems Engineering. Then they say they do Agile and do sprints but the reality is that a piece of work takes 2 weeks being defined (with some luck there is a well defined user story with acceptance criteria, scope and other data). The following 2 weeks goes into Design to mock up screens (in the worst case, design goes last and the process typically has to start over again). 2 weeks later development starts, but usually they will have dependencies among them (front-end needs APIs that were not properly defined, back-end needs first a database being deployed, the one developer who knows how to do X is on holidays during that period). N weeks later QA reviews and finds issues, so it goes back to development. T weeks later finally Systems Engineering (or Infra) takes an artifact and deploys it somewhere. But most likely that will not work or there will be dependencies not communicated (because Dev and Ops don’t speak) and it will again go back to Development. So, a very simple microservice takes 6 months to get into production. And that task itself has involved dozens of people, from different teams, in different workstreams.

It is absolutely impossible to calculate anything there. It is absolute chaos and leads to teams with an SEP-attitude (Somebody Else’s Problem).

We will touch in detail some of the topics below. But that is the very purpose of DevOps, where developers own the product, not just the code, but the product. They are responsible for the quality, deployment, fixes and ultimately the success of that story or feature. They can be supported by Site Reliability Engineers and other colleagues who can advise and help. But not own or block.

So, to be clear, if your DevOps team does not know coding extremely well (I’m not talking about just bash, and python with some luck, but knowing your code base and what your products do). If their job is taking somebody else’s code and requests and building infrastructure for them or do deployments. You are not doing DevOps. Even if you use Terraform, you are still not doing DevOps. If you are not automating all those processes so humans can dedicate themselves to generate value with the code, then you are not doing DevOps.

Your development team (or cell) needs to be fully autonomous. Design the software, develop it, create the infrastructure (whether it is composing containers, terraform, cloudformation or any other tool you like) and own the deployment pipeline. You may have central teams taking care of standards and giving you templates. Forcing you to use one specific cloud provider, a certain CICD tool or GIT provider. That is fine and it will happen in most big companies. But if you are not the one who owns the whole process end to end then you are not the one bringing value to the customer. Every member of your squad should be able to identify a bug in production, fix it and deploy the fix. (And know how the right tools and processes around it can help do that for enterprise-grade, SOC2 compliant platforms).