Lessons from our Mastermind sessions 🧠
A round-up of the most popular topics we discussed
In March we started running monthly Mastermind sessions in the community.
These are group sessions where you can come and bring your own challenges, and get feedback + support from other community members.
Each session is facilitated by Joel Chippindale, a professional CTO coach who has 20+ years of experience. We have run three sessions already and we will run our fourth on June 18th.
If you want to join them, become a paid subscriber so you can join the community 👇
If you are already a paid subscriber and haven’t joined the community yet, just reply to this email and I will send you the link to sign up 🔗
During these sessions I take a lot of notes, so today we will cover some of the most interesting challenges discussed during the past masterminds, with the advice that was shared.
All information will be anonymized, as the sessions follow the Chatham House Rule: they are not recorded, and people can’t reveal others’ identities outside of the group. This is an obvious measure to make people more comfortable at bringing up real, personal challenges.
Here is the agenda:
🗯️ How to advocate for big tech debt work
⚔️ How to advocate for quality when your manager only cares about quantity
👑 How to provide technical leadership without strong tech skills
💼 How to get hired as an EM on teams with a different tech stack than yours
Let’s dive in!
🗯️ How to advocate for tech debt work
A CTO confessed they feel unable to advocate for big tech debt work. How can they convince other executives that some technical work is worth doing?
This reminded me of when we interviewed Laura Tacho, CTO at DX, a few weeks ago. At some point, she said something that stuck with me: technical roadmaps are destined to fail. She meant technical roadmaps as in roadmaps that are separate from the main product one.
In fact, I believe the (not-so) secret to getting big tech work done is to treat it as normal work: you negotiate it and prioritize it based on the opportunity of getting it done.
So my first advice is:
1) Bring data 🔍
When it comes to refactoring, migrations, and other work under the hood, I have found that there are three types of data you can use to advocate for it:
🏅 Customer KPIs — the impact of bad code can easily leak to customers through outages, latency, or reported bugs. This is the easiest angle for business stakeholders to understand, and the first you should look into.
🚚 Productivity — chances are your dev experience is impacted by the debt. You can measure this in terms of time spent on maintenance, code churn, or other metrics about specific parts of the dev process (e.g. your CI/CD got slower and slower and it now takes 2 hours to deploy). Being able to say “if we get this done we can ship 10% more features”, backed by numbers, is powerful.
🔭 Enablement — finally, consider product evolution. Does this work enable product features we couldn’t do before? In my experience, the enablement angle is the best way to partner with PMs on debt, which in turn is effective to get things done.
Now, sometimes data is not enough.
Sometimes you don’t have enough of it, or you believe you have, but it’s not enough for your interlocutors.
This is where trust comes into play 👇
2) Create trust ❤️
There is a famous quote, by economist Edwards Deming, which says “In God we trust. All others must bring data”.
I have seen it used often in product teams and I kind of disagree with it — to Deming’s credit, though, he was referring to scientific research, not engineering.
There is a ton of work that gets done purely because of trust. And that’s ok. Trust makes work faster and riskier — which, in many cases, is a good tradeoff.
The impact of trust is also not black or white. A successful argument might be based on 80% data and 20% trust, or 50:50, or you name it.
More trust can compensate for less data, so, for tech debt work, if you can’t get your point across, you can either bring more data, or more trust.
For the latter, start with your track record:
3) Create a track record 🥇
Advocating for tech work is easier when you have a successful history of tackling other tech work.
You can bring this up explicitly in conversation, by showing success stories from the past where similar actions led to similar benefits.
If you don’t have such a history, start building it, and start small: solve small pieces of debt, document it, and celebrate it. Build momentum and confidence that you can take on bigger things.
4) Involve others in the decision process 🔄
I have found that another strong way to build trust is by involving others early in the process. Partner early with peers, PMs, and people whose opinion is legitimately important to your cause.
You should partner with them when you are still unsure that the work is worth doing, and get to a conclusion together.
Conversely, do not autonomously decide for a course of action and then make the case to justify it to others. This can come across as disingenuous, and people may feel you are pushing some personal agenda.
5) Don’t make it all-or-nothing ⚖️
Finally, whenever possible, present different levels of investment.
Maybe the leadership isn’t ready to commit to a 6-month rework, but they would test the waters with a 1-month proof of concept. You may 1) do the most important piece first, in a fraction of the time, 2) show success, and 3) get green light for the rest of the work.
⚔️ How to advocate for code quality when your manager only cares about quantity
A Senior Software Engineer asked the group about a classic conflict happening on their team.
The engineer takes pride in writing quality code, but doesn’t feel like their manager is supportive of this — instead, they push for quantity and speed of execution.
What to do in this case?