Primer on what kind of CTO you should be
CTO should understand context: type of business his is in, how revenue is generated, what is the strategy play.
CTO should on understand that business is the core priority and product is often proxy for that — technology should be considered an ivory tower. Technology should be the enabler instead.
CTO should find way to enable fast expertiments, problem-solving and high agency culture.
Goal of this chapter
Show that role of CTO is to deal with the disfunctional person-level patterns as CTO is reponsible for tech department. If you fit in wrong kind of people — you won’t get the organization or team that is capable of.
Disfunctional team patterns
The first priority of CTO is to align the tech team on the business or product priorities. I talk about it a lot.
One of the issues here — disfunctional patterns. These patterns are generally what to avoid within the tech team of any kind. These are often context-independant, they can manifest in any types of business as they are coming from people, not business itself. These patters manifest on person-level and on team-level.
A few person-level patterns I’ve noticed through ~ 500 engineers I’ve met, worked with, mentored:
- Hysterical Offender. An engineer that complaints in an unplesant manner when their decision is violated. E.g. you touch their code, exclude from discussion and they act offended.
- Protecionist. Person that behaves strongly protective for their decision and or solution and or approach. They fight, negotiate and it is important to feel that they were right or at least not wrong.
- Risk Lister. An engineer that very skeptical, avoiding risks. He is listing as many caveats and uncertainties as possible. Every discussion with him is generating so many questions that it becomes hard to move.
- Approve-seeking Guy. The one who is expecting someone else to sign off on the decision made — either manager or another engineer. This kind doesn’t own, he is only discussing.
What CTO should do here
- Identify dis-functional person-level patterns within the tech department. Identify people who’s work is either poor on their own or
- Figure out why they are happening: personality? not enough encouragement? higher ups enforcing “approve” culture?
- Start fixing it with the right approach: encourage → train → isolate → fire.
Encourage → Teach → Isolate → Fire
This 4 steps is the mental model I use to judge what to do.
First if you see engineer that shows slight sings of disfunction — it is alright. We are humans, we never perfect. You encourage them to act differently, explain the reasons — and they start changing their behavior.
Teach — second stage, you see that a teammates displays some pattern. Instead of encouragement — they need training. It maybe 1 on 1 sessions, mentors or books. But this stage means the person need to learn different way to do things.
Isolate — third stage, when you see that the pattern is strong. If it is a risk lister — it means he acts this way and even if you explain or repeateable taught this person, they still act this way. If they are important and do their job on their own well — you simply rebuild the work structure so they are less of a blocker or stressor for other engineers.
Fire — fourth stage, when these some of the patterns happens regularly and you clearly understand that results are not fine — you let person go. This is best course of action.
Conclusion
If CTO doesn’t focus on dealing with these patterns — we get quite weak team.
They are worse on delivery speed, they require more people to work on medium size things, they block business more often. These are translate into measurable costs, delays and opportunity lost.
If you joined a team as a CTO, head of R&D or any high level tech leader — you need to deal with this and deal fast. Otherwise, you will not be able to fulfill promises you said to the business you will achieve.