Sharing your culture, finding your allies, and reliable code quality 💡
Monday Ideas — Edition #197
Hey, Luca here, welcome to a weekly edition of the💡 Monday Ideas 💡 from Refactoring! To access all our articles, library, and community, subscribe to the full version:
Resources: 🏛️ Library • 💬 Community • 🎙️ Podcast • 📣 Advertise
📖 Create a shared engineering playbook
This idea is brought to you by Packmind!
Most teams adopt AI coding agents without an engineering playbook. Standards live in people’s heads, Slack threads, PR comments, or scattered docs, so AI agents are left guessing.
Packmind helps teams create and maintain a shared engineering playbook, and automatically enforce it across repositories and AI coding agents.
1) 🪴 Share your culture
Speaking of handbooks, culture is not just what you write in there — it is what happens every day in your org. But you still need to communicate it effectively, especially to people who are not yet part of your company.
How do you show, rather than tell, your culture? This came up in one of our recent mastermind sessions. Here are the things I have found most useful:
1️⃣ Map your touch points
Every interaction with candidates is an opportunity to demonstrate culture. The most important ones: your public presence (website, blog, open source work), job materials (descriptions, career page), and the interview process itself (how you communicate, what you ask, how interviewers behave).
Each step tells a story, and the strongest cultures are consistent across all touch points. Shopify, for example, sends candidates a culture handbook upfront — you can only move forward by explicitly accepting their principles.
2️⃣ Show, don’t tell
Instead of listing abstract values, share real stories.
Engineering blogs are perfect for this: they reveal how your team thinks and solves problems. Public post-mortems show how you handle failure. Behind-the-scenes content shows how people actually collaborate.
3️⃣ Write from your best performers
Do not write aspirational statements. Instead, observe your best engineers: what behaviors make them successful? Document those. Instead of “we value excellence,” write: “our best engineers seek feedback early and take ownership end-to-end.” Concrete behaviors are way more useful than abstract values.
We talked about this in depth in our article on generative culture 👇
2) 🎌 Find your allies
Improving how a team works—whether it is culture, quality, or any other kind of change—is a two-part problem:
You have to identify what needs to change.
You have to make change happen.
The second part is much harder. Change is an uphill battle against tight roadmaps and already stressed-out people. So for long-term transformations, one of the most important things you can do is find your allies and recruit them.
Your allies are the people who care the most about this change — the ones who will not give up when pressure builds, and who keep others accountable. Lasting change is always a mix of top-down and bottom-up input, and the bottom-up part needs champions, especially at the start.
This reminds me of Christine Pinto’s three-step model for improving quality in a team. Quality processes do not appear out of the blue — they follow a messy progression:
🦸 Crusader — one engineer acts as a hero, spearheading change largely on their own while influencing leadership.
🪴 Coach — the hero teaches others, establishing principles and getting adoption.
🌳 System — when critical mass is reached, individual efforts turn into team-wide processes.
The pattern holds for culture too. It never starts with a policy: it starts with a person. We talked more about this below 👇
3) 🎙️ Static analysis is not enough for code quality
In my chat on the podcast with Adam Tornhill—author of Your Code as a Crime Scene and founder of CodeScene—one idea stood out to me: static analysis alone is not enough for code quality.
Traditional static analysis tools examine code at a single point in time, but Adam argues this misses the most critical dimension: impact and relevance.
“You can have the most complicated code in the world, but if it has been stable in production for five years, there is nothing urgent on the roadmap.”
— Adam Tornhill
Adam’s alternative is to analyze version control history to understand developer behavior patterns. This reveals a consistent finding across hundreds of codebases:
🎯 Extreme distribution — the majority of development work concentrates in just 2-3% of the total codebase.
🔥 Hotspot priority — technical debt in highly-active areas becomes exponentially more expensive.
This reframes how we should think about tech debt: do not fix the most complex code — fix the most active complex code.
Here is the full interview with Adam:
You can also find it on 🎧 Spotify and 📬 Substack
And that’s it for today! If you are finding this newsletter valuable, subscribe to the full version!
1700+ engineers and managers have joined already, and they receive our flagship weekly long-form articles about how to ship faster and work better together! Learn more about the benefits of the paid plan here.
See you next week!
Luca