Trust, bugs, and hiring EMs 💡
Monday Ideas — Edition #143
💬 Unblocked • understand how your codebase works and why!
This week I am happy to promote Unblocked, which is a long-time partner or Refactoring!
Unblocked augments your team’s source code with knowledge from Slack, Confluence, Notion, and more, to instantly answer questions about your application.
Now everyone can get their work done – without having to dig for answers or interrupt their teammates.
Teams like Drata say they save an hour or more a day per engineer with Unblocked.
1) 🤝 The Four Domains of Trust
I am a fan of The Thin Book of Trust, in which Charles Feltman breaks trust down into four domains:
🎭 Sincerity — you are honest and transparent, even when it’s uncomfortable. This includes admitting mistakes early, being upfront with challenges, and sharing both good and bad news, without sugar-coating the latter.
⏰ Reliability — this is about consistency and following through. You do what you say you'll do, you set realistic expectations, and communicate proactively through regular update habits.
💝 Care — you have others’ best interests in mind. This means understanding their goals and challenges, being proactive in helping them succeed, and showing empathy when things get tough.
🎓 Competence — finally, you deliver results. For engineers, this goes beyond technical skills: it's about delivering business value, learning and growing from feedback, and understanding the big picture.
What I like about this framework is that it is extremely simple and it gives you concrete areas to work on. You can ask yourself: how am I doing in each of these? How can I do better?
Still, trust alone is not enough for good work relationships — I wrote more about it in this recent article about managing up 👇
2) 🐛 Prioritize bugs by severity + priority
How do you decide what bugs to address first? This is trickier than it seems, as you may have different stakeholders and different opinions.
A good way to get to a consensus is to consider two separate values of importance for a bug: priority and severity.
Priority — is how bad this is for business. How much revenue are we losing? How bad is the experience for customers? It should be assessed by the PM, with the help of customer support in case of user-reported defects.
Severity — is how badly broken the feature and software are. Is this 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 things are more broken under the hood than it seems.
Once you have set severity and priority values, you can simply fix bugs in this order:
High Priority + High Severity — the login is broken and users can't access the tool.
High Priority + Low Severity — terms & conditions are not visible when users make the payment.
Low Priority + High Severity — the checkout doesn't work with some niche combination of device + browser.
Low Priority + Low Severity — 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 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.
Does the process above create the perfect sorting? No. But it should be good enough as long as you are fast at fixing bugs.
The faster you are at fixing, the less important the order is.
More on fixing bugs below! 👇
3) 💼 Can you get hired as an EM on a “foreign” tech stack?
In a recent mastermind session, an experienced EM told us how, in their role, they are also involved on the technical side of things, but the team operates on a very niche tech stack.
Such a stack may not be relevant in other jobs — in fact, when interviewing, the lack of hands-on experience with more widespread tech seems to be a blocker.
So, what to do? Here is the advice from the mastermind:
Focus on language-agnostic skills 🧠
The best tech skills are either language-agnostic or totally transferrable between different stacks, system design being the #1 of these. The way you think about scalability, coupling vs cohesion, domain driven design, and more, are timeless.
Also, I have found that having deep knowledge of some stack/framework (e.g Ruby on Rails), including internals, quirks, and tradeoffs, makes it surprisingly easier to get just as deep on other frameworks as well. That’s because different frameworks need to answer many of the same questions, and even if the answers vary, just knowing what these questions are puts you way ahead of people who are starting from scratch.
So, during interviews, you may acknowledge your lack of experience in a given stack, but highlight your ability to pick things up quickly, thanks to your wider engineering experience.
Practice your interviewing skills 💬
Interviewing is a skill in itself — which is kind of sad if you ask me, but it is what it is 🤷♂️
So, practice your interviews. Look for common questions, prepare the right stories about your past experiences, and have good answers ready for your shortcomings.
Apply a lot 🗳️
Finally, recruiting is a deeply imperfect process, and being rejected doesn’t mean a lot. It’s a numbers game: you should do tens of applications, not just 5 or 6.
The job market is way tougher than it used to be, so you should take heart from the fact that you are getting interviews at all, and accept that some luck is required.
So, learn from rejections whenever possible, don’t get discouraged, and keep going. You got this 💪
More lessons learned from our masterminds below!
And that’s it for today! If you are finding this newsletter valuable, consider doing any of these:
1) 🔒 Subscribe to the full version — if you aren’t already, consider becoming a paid subscriber. 1700+ engineers and managers have joined already! Learn more about the benefits of the paid plan here.
2) 📣 Advertise with us — we are always looking for great products that we can recommend to our readers. If you are interested in reaching an audience of tech executives, decision-makers, and engineers, you may want to advertise with us 👇
If you have any comments or feedback, just respond to this email!
I wish you a great week! ☀️
Luca