Dev Autonomy; Handling Tech Debt at Google, Why Developers & Bosses Disagree on GenAI, The Power of ADRs
Issue #51 Bytes
🌱 Dive into Learning-Rich Sundays with groCTO ⤵️
📺 Driving Success with Dev Autonomy ft. James Samuel from Reddit
In this blast from the past episode, meet James Samuel, a Software Engineering Manager and the mind behind 'Effective Software Leads.' Get ready to hear about his fascinating journey from Nigeria to Germany and the secrets to being a top-notch engineering leader.
We'll dive into his role at Reddit, how he empowers his developers, tackles stakeholder expectations, and builds high-performing teams – all while keeping an eye on those crucial DORA metrics👇
Article of the Week ⭐
“Google took an empirical approach to defining technical debt. They asked engineers about the types of technical debt they encountered and what mitigations would be appropriate to fix this debt.“
How Google Measures and Manages Tech Debt
Dr. Milanović, a fellow CTO coach on Substack, shared his insights from analyzing a 2023 study that researches at Google conducted to put their fingers on handling tech debt efficiently.
Definition
The research didn’t start with a theory. They started with their engineers. Instead of debating what technical debt means, they asked teams what kinds of debt actually got in their way.
This resulted in a practical, grounded definition built from real-world friction. Their research surfaced 10 clear categories that engineers consistently pointed to:
🔄 Migration needed or in progress
📄 Poor or missing documentation
🧪 Inadequate testing
🪲 Bad code quality
👻 Dead code
🕸️ Code degradation
🤷♂️ Knowledge gaps
🔗 Problematic dependencies
❌ Failed migrations
🐢 Outdated release process
This gave teams a common language. Instead of vague complaints like “the code is a mess,” engineers could pinpoint the exact kind of debt.
Measuring
The next challenge was figuring out how to measure something so intangible. They started with the obvious place: asking engineers.
Every quarter, Google surveys a large portion of their engineering org—not to ask where debt exists, but where it’s actually slowing people down. That distinction is everything. Not all debt is urgent. Some of it just sits there quietly. But the kind that blocks progress? That’s what they focus on.
They also tried going further with testing 117 potential engineering metrics to predict technical debt: things like the number of TODOs, how much code was written by past team members, or how often migration terms showed up in bug reports.
The results? Almost all of the metrics failed to predict what engineers were actually feeling. Even the most advanced models had high precision but low recall. Meaning they’d catch some high-debt areas, but miss a ton of others.
Technical debt is context-dependent. What counts as “debt” changes depending on what your team is trying to do next. Python 2 isn’t debt in isolation. But it is when you need to move to Python 3.
In the end, surveys still beat dashboards. Listening to engineers remains the most reliable way to spot the debt that matters.
Managing
Defining and measuring technical debt is great. But the engineers at Google went after the real goal: reducing it in a sustainable, system-wide way.
They formed an internal Technical Debt coalition focused on making tech debt visible, manageable, and most importantly, fixable. The standout move was building a clear Technical Debt Management Framework: something every team could use to track debt, assign owners, and follow through with actual fixes.
To support that, they rolled out a Tech Debt Maturity Model. The model is a self-assessment tool to help teams understand how mature (or reactive) their debt practices were. It breaks down like this:
🔥 Reactive – No system, just fire drills when things break
📊 Proactive – Teams track and talk about debt, with basic metrics
🎯 Strategic – Debt has owners, gets prioritized, and tackled at the root
✅ Structural – Debt is built into the workflow, with org-wide consistency
On top of that, they invested in education and culture: internal courses, tech talks, and regular conversations to normalize the idea that tech debt isn’t shameful, but strategic. In addition, tooling and dashboards to help teams track coverage, docs, and dependency health. Not to automate away tech debt, but to support progress once it's being worked on.
Tech debt went from being something engineers quietly complained about to something teams planned for, tracked, and improved over time.
Balancing
The goal isn’t to eliminate technical debt entirely, but rather to manage it wisely.
This reframes debt entirely. It’s a tool, like taking out a mortgage, some debt helps you move faster in the short term if you know how and when you’ll pay it off.
They leaned on Martin Fowler’s framework to make the distinction:
✅ Deliberate & prudent debt: taken on consciously, with a plan
❌ Inadvertent & reckless debt: the stuff that quietly compounds over time
The takeaway is simple but powerful: strong teams accept debt when it makes sense, but they don’t ignore it. They track it, manage it, and pay it down before it slows them to a crawl. Discipline, rather than perfection.
Being Pragmatic
Google’s approach is impressive, but it’s not just for giants. The key is to treat tech debt like a real part of the work, not just something you'll “get to later.” Here are some practical ways to start:
📋 Make it visible – Track debt items like you track features. Use a Jira board, a wiki, or whatever fits. The point is: don’t let it live only in engineers’ heads.
📆 Prioritize it – Not all debt is equal. Decide what’s worth paying down now and block time for it, not just during “fix-it” weeks.
🎯 Take on new debt consciously – Sometimes you should take a shortcut. Just make sure you know it’s a shortcut, and document it with a plan to revisit.
🏆 Assign ownership – Google found teams made the most progress when someone—often a tech lead—was responsible for driving debt conversations and follow-up.
📊 Use tools as feedback, not truth – Dashboards can’t spot debt on their own, but they can show progress once a team starts tackling it.
🎓 Keep educating – Share stories of incidents caused by hidden debt. Normalize clean code practices. Make debt a topic in planning, reviews, and retros.
Other highlights 👇
Why developers and their bosses disagree over generative AI
A recent survey found that while tech execs see GenAI as the top lever for boosting productivity, only about one-third of developers say it’s made any real difference. Why the disconnect?
It turns out most AI investments are narrowly focused on writing code—but developers actually want to spend more time coding. So AI ends up automating the one part they enjoy, while ignoring the pain points that truly slow them down.
What devs really need help with:
🔍 Debugging and stack traces
🧪 Writing and maintaining tests
🧾 Improving documentation
🔄 Navigating complex systems and dependencies
📚 Learning and onboarding faster
To close the gap, shift the strategy:
Start small and let teams experiment
Ask what actually slows devs down
Never mandate GenAI use
Frame AI as a partner, not a replacement
Focus on outcomes, not output
Bottom line: AI doesn’t drive productivity unless it earns trust. That starts by listening to the people you’re asking to use it.
Elevate Your Engineering Culture: The Power of Documenting Architecture Decisions
Ever lost hours explaining a past architecture decision… that no one remembered making?
That’s where Architecture Decision Records (ADRs) come in. They’re short, structured docs that capture the context, trade-offs, and reasoning behind key technical decisions so your team doesn’t have to re-litigate them six months later.
The benefits go far beyond documentation:
✅ Clear rationale for major technical decisions
🚀 Faster onboarding and fewer Slack archaeology sessions
🧠 Encourages thoughtful, data-driven design debates
🔁 Makes it easier to evolve architecture with context in hand
📂 Builds a searchable, living history of your system
You don’t need a complex tool. A simple markdown file per decision is enough as long as it is stored with your code, tagged, and easy to find.
The rule of thumb? If someone might question the decision later, it deserves an ADR.
Find Yourself 🌻
That’s it for Today!
Whether you’re innovating on new projects, staying ahead of tech trends, or taking a strategic pause to recharge, may your day be as impactful and inspiring as your leadership.
See you next week(end), Ciao 👋
Credits 🙏
Curators - Diligently curated by our community members Denis & Kovid
Featured Authors - Dr Milan Milanović, Jennifer Riggins (for LeadDev), Karol Galanciak
Sponsors - This newsletter is sponsored by Typo AI - Ship reliable software faster.
1) Subscribe — If you aren’t already, consider becoming a groCTO subscriber.
2) Share — Spread the word amongst fellow Engineering Leaders and CTOs! Your referral empowers & builds our groCTO community.