Kill the leadership mind chattering
Leave all this behind: Architecture, Prioritization, Leadership, Autonomy, Protagonists. Go with these: Ownership, Initiative. Here's a simple tool to help you and your team.
TL;DR
It is that time of the year for budget and planning. Throw away long documents, indirect metrics and slack and email threads, plan to work on ownership and initiative and build from there. It is the single most important investment and guidance you will do.
The burning question
This is sort of a philosophical post and a review of my last 12 months or so. The majority of consulting and work I did was around teams that were not functional, needed to be more effective and products that were not successful - even when the process was seen as a success to be celebrated.
All these came with a pile of methodologies, books, medium posts and angry anonymous questions. But none of them helps when you are about to plan for another year, to recover from mistakes and review what didn't worked. Throwing more money into consulting, books and tools won't help either (maybe reading this Substack and getting yourself a copy of The CTO Field Guide will get you some shortcuts :D),
What’s behind rituals, committees, architects, architecture, strategy and endless documents about engineering at your company ? It is the desire for autonomy and the hope that people statistically do “the right thing”.
Why do we accept that in all disciplines - product, design, engineering, support and all - piles of word salads will fill ownership gaps as simple as prioritizing or designing architectures - and that customer and revenue will be a positive consequence ? That's flat earth thinking at best.
Architectures are given away everywhere as posts about how to build services and use databases. Metrics are by the handful, anything may have a successful product metric even if the money is not there. We live and hear stories of layoffs, down rounds, companies closing but insist on the same metrics.
As for individuals, all of the above won’t help their careers or team goals so why an internal copycat of a blog post would ?
My mentoring method is to empower leaders to lead outside of their team and their chair. I believe that leadership can be taught, and it is based on Ownership and Initiative.
Since I've released my book I wrote here about culture, decisions, layoffs, growth, metrics and all that, mostly by request. In October 2023, seeing more books and trainings about leadership abound, I am proud that my content focus more on what I believe and live. And I don't want to contribute the pile of useless documents.
So with these questions in hand I wanted to lead by example, delete a bunch of drafts about many of the points above, write a single post with a single tool to help you and your team develop ownership and initiative.
The path of (non)decision making
Foreseeing the future based on estimates is harder and frustrating, almost divination. Hence, decisions will be made based on what is known and what is needed. A team has to deal with exploration, new capabilities, technical debt and dependencies with/from other teams.
Non-functioning teams are judged by one metric: time. A team that sacrifices time to design lengthy perfect solutions or is just take tickets left and right with no regards to quality and scalability are perceived the same - slow and unreliable. That perception becomes the indicator of their maturity. Their stakeholder becomes the loudest person around.
A team regarded as mature has a balance of quality, velocity, scale and durability of their solutions that comes with opinion. They will fail, but when accounted together it is the overall impact that is taken as maturity metric.
The difference are ownership and initiative. Too much initiative without ownership and you are making a ticketing company happy, as one of your OKRs will be “Tickets closed”. Too much ownership without initiative will make you a big rock in a narrow path. Everyone will go around as you do with an opinionated but non productive team. The right balance of ownership and initiative will develop communication, leadership, architecture and outcome quality.
A team of individuals
You already have a lot of documentation that describe engineering or product culture and principles but they are mostly geared towards a team. On the other hand you may have a career development process with individual notes based on company values, expected behaviors or productivity indicators. But a team is not a single entity and rewards including career growth are aimed to individuals, derived from teamwork.
For example: long discussions about software engineering without actionable items for tomorrow and next week indicated that outcome ownership is stretched, diluted or non-existent - no one wants to carry the ugly baby, to own customer-to-code cycle and its impact.
If individual purpose is not clear, it is easy to confuse having impact with closing tasks. Worse, it will be common to assume that just being around is a contribution and lose sight of bigger goals. It gets uglier up the chain.
Building a Expectation list
The basics are what you expect, which behaviors are taken in account if an individual of any level has to make a decision. These expectations are not just a checklist, but they are to be constant, present from onboarding to delivery and called of in case of the need to tie-break or prioritize. They should be right most of the time, if not all the time. And short, in order of importante. Work on yours, here is mine to be read as “Every individual contributor and manager in every discipline is …”
Responsible for what customers experience
Responsible for team empowerment
Responsible for team growth
Working to unlock the team, giving guidance.
Doing their craft: Coding, Designing, Leading, Data Science
It should be actionable, easy to check. They are not your company values, they are not a full ladder but they are present in the ladder and discussed on 1:1s, team meetings, slack. Kill a wall of text by using one expectation and working the context.
Responsible for what customers experience
Handling incidents
Fostering an “You Build, You Run” dynamic with monitoring and metrics, being on call
Understand the product
Get customer feedback
Don't pass problems around
Stop all that you are doing to fix something (that should not even be discussed). Incidents, security issues, performance issues, sudden expense increases.
Connect to stakeholders
Responsible for team empowerment
Onboarding
Mentoring
Pairing
Self-development
Documentation
Responsible for team growth
Interviewing
Foster and work to improve diversity
Hire well
Find candidates
Contribute to career development
Working to unlock the team, giving guidance
Connect people (Decision making across teams is an art. )
PR review
White boarding (with your team, individuals, other teams)
Improve stack and tooling
Create data pipelines
Improve processes
Prioritization
Work on discovery, PoC, spikes, research
Write stories and tasks
Doing their craft
Code
Debug
Create automations
Create dashboards
Write RFCs
Discover, discuss and roll out team changes
Create models
Lead the team
Prioritization
Budget
Go get it
The best way to use this tool is to take it and write in your own words, review it and release. Then work bottom up to tie career and planning to it, and train yourself and the team to use it daily and tie it to outcomes. It is free but not easy to use, as most of the software we like !
When outcomes are not discussed, they come top down. When things are not working right, the team time is split between deadline compromises and magic time to fix issues.
Interference leads to complaints and once a culture of complainers set in, it is too hard to move to a culture of owners. No one wins delivering new features to a product with no customers. No one wins doing nice presentations. We win by ownership and initiative. The first one to get to the finish line takes the cake.
If you are looking for tools and ways to get your team moving, specially if you are starting in a new role maybe you want to know that I wrote a book called The CTO Field Guide. It is a book to help engineering leaders of all levels. Check it out at https://ctofieldguide.com !