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:
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:
๐ฉบ KTLO โ mandatory maintenance to Keeps The Lights On.
๐จ New thingsย โ work towards business goals, like new products or features.
๐ง Improvementsย โ work to improve existing features, including performance, reliability, and security.
โ๏ธ 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 ๐
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:
๐ High Priority + High Severity โ e.g. the login is broken and users can't access the tool.
๐ฅ High Priority + Low Severity โ e.g. terms & conditions are not visible anymore before users make the payment.
๐ฅ Low Priority + High Severity โ e.g. the checkout doesn't work with some niche combination of device + browser.
๐ฅ 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 ๐
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 ๐
๐๏ธย 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
Hi
Does bugfixing come into the improvements area in your classification?