Those that know your business and know that they know your business. They are sources of wisdom. Use them.
Those that know your business but act as if they do not know your business by being hands-off. They are sleeping partnerships. Awaken them and extract value.
Those that do not know your business and know that they do not know your business so are hands-off. They are helpful in other ways and can be great support.
Those that do not know your business and do not know that they do not know your business. They will impose their will upon the business and destroy value. Shun them.
We are often faced with a dilemma when considering how to use software to solve a problem: whether to build the solution to that problem, or whether to buy a product or service that we believe can solve it. Many people and groups struggle with this choice, and also struggle to find a reliable method for making well thought out decisions.
Every situation is different but as a rough guide I’ve found it useful to ask 5 directional questions:
Is there an adequate solution that you can buy?
You can integrate it
It fits timing needs
It has features you need now
It has features you’ll need later or can be modified
It is reliable
There is support available
Is this a key differentiator for your business?
Is there an industry standard solution that you can buy?
Can you build it adequately for less than the cost of buying it?
Do you have other projects that would be a better use of your time?
Often, this is how those questions guide the way to an answer:
I’ve heard CTOs described as Product-focused versus Tech-focused, and I’ve heard people described as strategic versus operational, but I wonder if these are false dichotomies. I wonder if a better scale may be Product vs Operational — or to put it another way — CTOs that excel more at considering what to build versus CTOs that excel more at considering how to help many different people build it.
Executives at either end of that spectrum can be strategic or tactical at different times. It’s a common misconception that operational CTOs are weak strategically, when in fact it seems impossible to implement long-term vision of operational excellence without having a strategy to guide decision-making. Likewise it’s a common misconception that Product-focused CTOs are weak technically. Some of the most gifted Product people I’ve known were also very strong implementers.
However, I’ve known hundreds of CTOs and I don’t think I’ve ever found a strong Product-focused CTO who also excelled operationally at scale, and likewise I don’t think I’ve ever known a strong operational executive who excelled in Product creation. I’ve known many people who have done both, but in all cases they were either excellent at only one of them or neither.
There is a difference between being good at the CTO job and being good at the CTO role.
The job is everything that is required to deliver real results: hiring great people, building great software, buying the right things, defining strategy and doing everything it takes to execute on that strategy accurately.
The role is the perception of the job you’re doing; how well you play the part.
It is much harder to learn how to excel at the role than it is to learn how to excel at the job. Expectations can change via conversations that happen in conference rooms you’ve never been to, involving people you’ll never meet, who discuss questions and decisions that will never be communicated to you. The CTO role is not a game played with complete information.
Despite that, it is important that we do everything we can to create and fulfill roles that we feel are right for the organization. Sometimes that means forcefully arguing for change, other times diplomatically finding compromise. Sometimes it means spending more time interfacing externally, and sometimes it means putting in extra face time internally. It involves finding the right balance between different stakeholders’ ideas of what the company needs, which are very often mutually exclusive.
One gauge of how good someone is at their job is how well they recover from mistakes. You can tell how great of a guitar player Neil Young is by seeing how well he recovers from a misplayed note in a solo — somehow, he actually makes it sound good. Likewise, chess grandmasters are excellent at making their mistakes as difficult as possible for their opponents to exploit and so turn many losses into draws.
In our jobs we often make mistakes when it comes to project management, hiring, putting the wrong people into a big role, politics, architecture, and so many other things. Being able to quickly realize that a mistake has been made, and somehow having the mental fortitude to leave the past behind and re-approach the current situation with a fresh perspective is what sets apart amateurs from professionals.
