CTO day 1: first steps and hiring framework

About a year ago, I agreed to be promoted to interim CTO at Akvo.

This is the "first steps that I took" on a series of blog posts about it.

So, what is a CTO again?

Nobody will give you a clear definition because the expectations for the role are very context specific.

Context being the organization and each organization being unique, this is how I understood Akvo back then:

The partnership team had plenty of structure, but from my point of view it was just an amorphous blob of people that I rarely had to interact with. They were "The Business".

The Head of Product Development position has been vacant for more than nine months and the Management Team shrinked a few months back leaving the Technical Director out.

The Solutions Director has been taking care of all the software teams during this time, and we have formed a "Council of Elders" with all the technical team leads to cover for the most technical aspects until there was a new CTO.

Given my very technical background, the existence of the Council of Elders and that the CTO position was going to report to the Solutions Director, I understood it was a mostly technical position, being the Solutions Director still responsible for the product managers and the design team.

That suited me well.

Shortly after accepting the role, I learned that the Solutions Director was leaving in a few months.

So to my surprise, I found myself leading a team of 17, owning five different products and having to manage for the first time people outside my area of expertise. Is it even possible to be a good manager if you have no clue what those people are doing or talking about?

A mentor

Conscious of my own limitations and lack of experience, I started looking for a fellow CTO mentor without too much luck.

Grumbling about it with an old friend from university, Jose Bronet, he offered his help. As Senior Director at Cisco he has been managing big teams for years.

This is the only piece of advice that I will give you today: find yourself a good mentor.

Jose's help has been invaluable.

First steps

We started the mentorship with the following activities:

• Read “Becoming a Tech lead”. Very insightful. Here are my notes.
• Understand and apply Situational leadership.
• Loads of work to understand how Akvo’s side of the business works.
• Know yourself:
  • Your streghts: Curiosity and interest in the world is my top one.
  • Learning style: I am a reflector/theorist.
  • MBTI test: I am a logician (INTP-T):
    • "Tend to share thoughts that are not fully developed, using others as a sounding board for ideas and theories in a debate against themselves rather than as actual conversation partners".
  • List of my values:
    • Curiosity
    • Passion
    • Accountability
    • Safety
    • Joy
• Writing down what being a good CTO means:
  • Technically capable:
    • Coding.
    • Architecture.
    • Software process and practices.
  • Align software development strategy with business strategy:
    • Buy vs build, Refactor vs Rewrite.
    • Stop useless development.
    • Keep an eye on new trends.
  • Able to communicate up the technical aspects and down the business aspects.
  • Empowers teams:
    • Gives them autonomy.
    • Gives them a vision.
    • Makes constraints clear.
    • Supports their decisions.
    • Hires, fires and retains the correct people:
      • To retain, grow people.
    • Provide problems, not solutions.
  • Teaches and inspires.
  • Creates connections between teams, between departments, so they have enough information.
  • Works on the correct problem.
  • Know his weaknesses and asks for help.

I would also recommend to read Your first 60 days as a CIO and sight up for Patrick Kua’s newsletter.

SMART challenges

Jose’s answer to how to manage people outside your expertise area is to challenge your reportees to ensure their work and ideas are Specific, Measurable, Attainable, Realistic and Time bound (aka SMART).

Questioning on all those aspects confirms if the reportee understands the problem, possible solution, and that their decisions are data based.

Questioning will highlight missing information and holes in the reportee line of thought and will help them find their own solutions.

Questioning gives you more information, which will allows for making better informed decisions down the line.

This technique is not only useful with your reportees but also with your peers and boss, and most importantly with yourself.

Career paths and hiring framework

It takes nine to twelve months to replace the wrong hire, so hiring the right people first time around is crucial.

For this I started working on a hiring framework:

• Identify three to five Values that are the most important.
• Hiring framework is aimed to score the candidate on those Values.
• Interview questions must always be the same to avoid some biases.
• Each question should be related to one Value in the framework.
• Score each question with a red (0 points), yellow (1 point) or green (2 points).
• Sum up all the scores per Value.
• For each Value, determined the point range for a green, yellow or red:
  • For example, a green in Passion is 8-12, a yellow 5-7, a red less than 5.
• Each Value can have different ranges.
• Define which combinations of Value colours are acceptable. Example:
  • At least 3 green and two yellows, or
  • Tech capability must be green and at least two other yellow, or
  • If tech capability is yellow, at least three others must be green.

The expectation is that the hiring framework will make the hiring faster, consistent and remove biases.

To give clarity to the team, I worked in parallel on a career path for Akvo’s technical staff.

I would recommend Marco Rogers' Creating a career ladder for engineers talk, Camille Fournier's The Manager's Path, and https://www.progression.fyi has plenty of examples from well known companies.

But all this work went into shambles as my next task was not precisely hiring ...