Hey there 👋🏼
In today’s email:
Technical Debt: Time to pay your dues!
Leadership Debt: It’s not just the others that create debt.
Cool stuff on the web: The best stuff on the web.
Post of the week: 5-star on social media.
TECHNICAL DEBT
I'm sure you've heard all about technical debt!
Heck, it's a topic of conversation within the first hours of leading a team. You hear people talking about it in retrospectives by the water cooler, and it's one of those topics lost deep within the team's backlog of tasks.
So let's start at the beginning.
Do you know when you take a shortcut or make a trade-off that will help you deliver a feature faster? The "we'll fix this later"? That's what technical debt is.
By itself, the decision to take a shortcut shouldn't be a problem. However (and get ready because I'm going to use that word I love so much), as technical debt piles up, it compounds!
And this is where the problem lies.
Before you know it, your team has several, and usually undocumented, shortcuts throughout your codebase that made sense at a point in time but now slow down progress.
Technical debt can take many forms:
skip creating all the necessary tasks due to time constraints
take shortcuts, prioritising a more straightforward solution
making assumptions, etc.
This leads to poor code, making it harder to evolve and find and fix bugs.
Now that you know and can identify technical debt, here are some essential practices to avoid, manage and remove your technical debt.
Keep a Technical Debt Ledger.
I can't stress the importance of documenting decisions enough.
How often have you received a project where critical decisions were made but no documents support the reasoning behind these decisions? Or having to develop a feature, but you need to understand why the team took shortcuts two or three years ago, and the people involved in those decisions are probably no longer with the team.
A Technical Debt Ledger is a document where you track the debt of your team. You write down every shortcut, quick decision, shortcuts, known bugs not fixed, known areas lacking testing, etc.
A ledger should contain key information such as when the debt was added, the reasoning behind it, how much it costs to fix it and above all, the linked task to pay the debt.
If you want to start using Tech Debt Ledgers, I created one in three different formats for you to use: Google Docs, Notion Template using Tables and a Notion Template using Databases.
You can find the templates in the newly created Free Resources area.
Make removing Technical Debt a Priority.
I'm 100% sure you know that you have to make it a priority for your team to reduce technical debt. But I've also heard time and time again how difficult it is for Engineering Leaders to prioritise Technical Debt with Product Owners/Managers.
So let's start by working collaboratively and not in us vs them category:
If your product owner needs to learn about technical debt, educate them and explain how it impacts the development process. Make sure you highlight the risks for the product by not removing that debt.
Highlight the benefits of paying your technical debt, focusing on the developer's productivity and happiness levels.
You should often report on the impacts that reducing your technical debt has on the team's ability to deliver features.
If you're not working within a product environment, you're in control of your team's roadmap, so you're the sole responsible for making it a priority:
Reserve time in your roadmap quarterly for Technical Debt initiatives
If you have small, achievable tasks that remove your Tech Debt, reserve a part of your sprints to do them.
Have you heard of Inbox Zero? Well, I recommend Ledger Zero! Be proud of your Ledger and share your progress reducing it.
Find the root cause.
Last but not least, if you recurrently add technical debt, you should find out why this keeps happening.
Only you know the reasons behind your team adding tech debt, but here are some common ones (you'll notice that they're all intertwined):
Tight Deadlines: Probably the reason #1 behind adding technical debt. Teams take shortcuts because they need more time to deliver features.
👉🏼 Review how your team estimates tasks and the time you're reserving to complete those features in the roadmap.Lack of Resources: If you need more resources to perform specific tasks, it's expected that your team takes some shortcuts or delivers tasks with lower quality than expected.
👉🏼 Review what is expected from your team and ensure you have the profiles in your team necessary to perform those tasks. Raise the flag if you don't. Communication and transparency are key.Changing Requirements: If requirements keep changing, it's natural that your team tries to adapt, which usually means making decisions that go in the direction of delivering fast instead of right.
👉🏼 If changes are recurrent, negotiate added time for execution per change. Explain the benefits of focusing on the right approach and avoiding adding technical debt.
Most (if not all) teams have some technical debt. The main difference is the strategy and the way they manage that debt that makes the difference.
Contrary to your belief, good practices in managing tech debt are in your control.
Take advantage of this opportunity.
Technical Debt should be reserved for cases when people have made a considered decision to adopt a design strategy that isn’t sustainable in the longer term but yields a short-term benefit, such as making a release. The point is that the debt yields value sooner but needs to be paid off as soon as possible.
Martin Fowler
Technical Debt Quadrant by Martin Fowler
LEADERSHIP DEBT
As I said. I'm 100% sure you have already heard about technical debt.
Have you heard of Leadership Debt?
Don't think teams only add that debt. As an Engineering Leader, you're adding debt as well.
Close your eyes and imagine you saying the following: "Let's do it like this for now, and we'll revisit this approach/decision in the future".
How many times have you said this?
Here are a couple of examples of situations where you might increase your Leadership Debt:
On Call practices: Let's use two elements instead of 3. Yes, there's some risk of burnout, but we'll revisit this situation in the future.
Communication issues: Team A keeps requesting tasks from us within a limited timeframe. Let's do it for now, but we'll revisit it so it doesn't happen again.
Backlog Management: The team continues with an unclear backlog. Let's ensure they have enough tasks for this sprint, and we'll review them in the future.
Mission & Vision: The team needs a clear mission & vision for what they're doing. Let's focus on this delivery, and we'll revisit it in the future, so they're more engaged.
I could go on for days.
As a Leader, you also add debt.
It's your responsibility to manage it and clean up the house.
COOL STUFF ON THE WEB
🎧 Modern CTO - The Tech Layoff Crisis
This is an interesting take on why we’re witnessing so many layoffs in Tech, emphasising the United States market.
📚 Cloud FinOps - Collaborative, Real-time Cloud Value Decision Making
Starting to read this book on how organisations can spread the values and culture of FinOps to manage their cloud spending better.
I’ll def come back to this topic in a later issue.
📰 ByteByteGo - How does ChatGPT work?
Almost everyone has heard of ChatGPT, but do you know how it works and processes information to deliver accurate responses? Alex Xu shares how it’s done. A must-read!
POST OF THE WEEK
Twitter has reached a new low point as it’s starting to make security features exclusively for Twitter Blue subscribers.
I’m yet to find an app that provides the same service as Twitter - Mastodon doesn’t quite cut it.
Open to suggestions!