Monkeys, investment metrics, and prioritizing bugs 🐒

Monday 3-2-1 — Edition #53

Hey, Luca here! Welcome to the Monday 3-2-1 ✨

Every Monday I will send you an email like this with 3 short ideas about engineering management, technical strategy, and good hiring.

You will also receive the regular long-form one on Thursday, like the last one:

• Tech Leadership across the Startup Lifecycle 👑

To receive all the full articles and support Refactoring, consider subscribing if you haven’t already!

p.s. you can learn more about the benefits of the paid plan here.

---

---

〰️ Wave • Your tailored coach for infinite growth

This week I am promoting Wave, because I love their unique approach to coaching and AI 👇

Wave provides a tailored coaching experience to take your career to the next level and overcome the challenges you are facing at work, like:

• Building self-confidence in your role

• Improving your productivity and organization

• Rethinking the way you lead, communicate, and build trust

Wave lets you tap into the collective brainpower of multiple coaching experts empowered by AI, and take your leadership skills to the next level 🚀

It is used by founders, managers, and leaders from companies like Amazon, Stripe, Google, and Strapi.

You can start for free and, as a Refactoring reader, you get a 30% discount when the trial is over by using the GROWWITHREFACTORING discount code.

Back to this week’s ideas!

---

1) 📊 Investment metrics are underrated

Investment metrics are for figuring out how you spend your time as a team.

For example, how much time goes into maintenance vs new features? How much on new features vs small improvements?

In my experience, tracking your engineering investment has incredible ROI. It creates alignment with the business, builds trust, and counters natural biases your team may have towards specific types of work.

In fact, based on their culture, most teams naturally skew towards some modes of work. For example:

• 🏭 Feature factories — always pumping out new stuff.

• 📊 Optimizers — focus on short-term and small improvements, rather than big initiatives.

• 🏗️ Perfectionists — engineering-heavy teams who overly focus on refactoring.

The best way to counter this is to start visualizing where your time goes, and adjust.

About this, I am a fan of the balance framework, which divides work into four main areas:

1. 🩺 KTLO — mandatory maintenance to Keeps The Lights On.

2. 🔨 New things — work towards business goals, like new products or features.

3. 🔧 Improvements — work to improve existing features, including performance, reliability, and security.

4. ⚙️ Productivity — improvements to the developer experience. This may also affect operations and other departments’ productivity.

This helps you have conversations based on grounded evidence, and build a sustainable work balance. E.g. are you spending more than 30% on KTLO? You can bring up the data, discuss if there is some debt that slows the team down, and plan actions to improve.

Most engineering metrics tools today provide ways to track your investment. You can find more info and ideas about how to use engineering metrics, in this previous Refactoring article 👇

How to Use Engineering Metrics 📊

---

2) 🐛 Prioritize bugs by severity and priority

Bug fixing is not exactly everyone's favorite engineering activity.

It's a tricky process that requires coordination between several stakeholders — PMs, customer support, QA, and engineers.

A good way to involve all stakeholders in prioritization, while also keeping conflicts low, is to consider two separate values of importance for a bug: priority and severity.

🏆 Priority

Priority is how bad this is for business. How much revenue are we losing? How bad is the experience for customers?

Priority can be assessed by the PM, with the help of customer support in case of user-reported defects.

🔨 Severity

Severity is how badly broken the software is. Is the feature still usable? Why is this happening?

Severity is assessed by QA and engineers, who can ignore how relevant the broken feature is, to focus on how much it is individually impacted by the bug.

Engineers can also evaluate whether the issue is a symptom of a larger disease, and whether things are more broken under the hood than it seems.

🔄 Process

Once you have set severity and priority values, you can simply fix bugs in this order:

1. 🏆 High Priority + High Severity — e.g. the login is broken and users can't access the tool.

2. 🥇 High Priority + Low Severity — e.g. terms & conditions are not visible anymore before users make the payment.

3. 🥈 Low Priority + High Severity — e.g. the checkout doesn't work with some niche combination of device + browser.

4. 🥉 Low Priority + Low Severity — e.g. the border radius of the button doesn't match the design system.

Basically, priority wins over severity, with the latter being considered when the former is equal.

This framework is powerful for two reasons:

• Separation of concerns: it avoids the negotiation between the business and technical side of the team, because each side gives its own value separately.

• Clear sorting: It provides a clear rule for deciding in which order to fix bugs — one that doesn't need to be rediscussed every time.

More ideas on prioritizing bugs 👇

How to Prioritize Bugs 🐛

---

3) 🐒 Avoid the monkey on your back

As a manager, having the monkey on your back is a metaphor for having the initiative on yourself. You are the one who has to take the next step — the ball is in your court.

For any activity, you should strive to minimize the time the monkey is on you, and figure out how to return them asap to your reports.

I love this metaphor — I explored this and more ideas about delegation in a previous Refactoring article 👇

How to Delegate Effectively 🤝

---

🏛️ Plato Academy ($100 gift card!)

Last week we covered Plato Academy, the mentorship platform for engineering leaders.

At Plato Academy you get cohort-based learning, 1-1 mentorship, and community Q&As with mentors coming from leading tech companies like Reddit, GitLab, Netflix, Box, and more.

As a Refactoring member, you can get an exclusive $100 Plato Academy gift card 🎁 by filling out this form!

---

And that’s it for today! If you are finding this newsletter valuable, consider doing any of these:

1) ✉️ Subscribe to the newsletter — if you aren’t already, consider becoming a paid subscriber. You can learn more about the benefits of the paid plan here.

2) ❤️ Share it — Refactoring lives thanks to word of mouth. Share the article with your team or with someone to whom it might be useful!

I wish you a great week! ☀️

Luca