Accountability dial, anticipating tech debt, default SPA 💡
Monday Ideas — Edition #58
Hey, Luca here! Welcome to the Monday Ideas 💡
Every Monday I will send you an email like this with 3 short ideas about making great software, working with humans, and personal growth.
You will also receive a long-form, original article 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.
⬆️ OneSchema — Import CSV data 10x faster
OneSchema is a ready-made CSV importer for developers — which automatically corrects customer data.
Validate and transform files of up to 4GB in <1 second, customize importer behavior, and launch fast with a library of prebuilt validators.
We implemented OneSchema in just one day, and what used to be a weakness in our UI is now one of our strengths. — Dominic Kwok, CTO, Heron Data.
OneSchema is a sponsor of Refactoring 🙏 here is how we run sponsorships transparently.
Back to this week’s ideas! 👇
1) ⏲️ Accountability Dial
I am a fan of the accountability dial, by Jonathan Raymond, as a simple framework to correct bad behaviour at work. It is based on five steps:
🟢 The Mention — is the first check-in in which you mention the issue. You can address this is from a place of curiosity, rather than judgement, by asking questions: “I saw you missed the meeting, is everything ok?” or “Your design doc doesn’t address X, were requirements clear?”.
🟡 The Invitation — is a more serious chat in which you address the issue directly. You investigate why it happens, make sure expectations are clear, and that your report knows/has everything they need to get back on track.
🟠 The Conversation — after two mentions already, you should have a dedicated conversation about it to express urgency. This is also where you can be more prescriptive about how to fix, and get a commitment in terms of timing.
🔴 The Boundary — after three mentions, it is time for a warning conversation that makes it clear there will be consequences if the behavior doesn’t change. If you think your report might not be able to move forward, sit down with them and show them how to do it (when relevant). Nobody wants to be micromanaged on a regular basis, but, every once in a while, microguidance is what people need.
🟣 The Limit — is the final ultimatum that makes it clear you should part ways if things don’t improve. This is a crucial conversation to have and should act as the final eye opener for them. Put it in another way: if you lay off someone because of underperformance, and they did not expect it, you did something wrong.
Parting ways isn’t the only way to reset the dial, here are more things you can try:
🎌 Move them to a different team — switching teams can reset their work environment and help them rebuild their impact and reputation with new people.
🧢 Move them to a different role — in some cases, changing roles is useful. E.g. some underperforming managers may benefit from getting back to an IC role, instead of being let go completely.
🏖️ Let them take time off — if you suspect they are stressed out or have personal problems, consider giving them some extended time off.
You can find more ideas on helping underperformers in this recent article 👇
2) 🦠 Anticipate Tech Debt
I have found that one of the best ways to handle technical debt is by anticipating it, which is not necessarily the same as preventing it.
During the design phase, you can often anticipate that something will not scale over some limit, or an abstraction will not fit if X happens in the future.
These limits are important to be discussed to make sure you are designing for the right scenario.
A limited design is good as long as you won’t touch those limits for a long time.
You can encourage this reasoning by addressing these parts in your design docs. You may include, for example:
❌ Anti goals — goals and features you are intentionally not designing for.
💣 Land mines — stuff that might be problematic for the current design if it happens. E.g. traffic load, or future features.
💸 Operational costs — how much it costs to maintain the feature, if there is any maintenance cost that you can anticipate.
In my experience, when all the cards are on the table, it is rare that you make truly terrible calls. Most mistakes are rather made because of unknown unknowns. Stuff that not only you didn't design for — you didn't even know it could happen.
We discussed this (and more) in the recent interview with Andrew Twyman, former Staff Engineer at Dropbox 👇
3) 🙅♂️ Beware SPA by default
There has been a tendency in recent years to use SPAs (single page applications) as the default architectural choice for frontend applications.
While SPAs are of course not wrong per-se, I feel many people choose them without being aware of the set of tradeoffs they are getting themselves into.
SPAs are challenging in many departments, like SEO, initial loading times, fine-grained analytics, browser history management, and more. So, based on your requirements, they may or may not be the best architectural choice for your app.
In recent years, interesting frameworks like Hotwire and Remix have come up with strategies to keep navigation and more business logic on the server, while still enabling good user experience. You should check them out!
You can find more tools and techniques for 2023 in this Tech Radar article I wrote earlier this year 👇
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 with someone who would like it, and get a free membership via the new referral program.
I wish you a great week! ☀️
Luca