π― Sleuth β alignment at all levels
When priorities change, here's a simple process every engineering leader should follow:
βοΈ Re-align β on goals and re-allocate resources as needed.
π£ Communicate β the change to the team, or the entire org.
π Monitor β check if everyone is rowing towards the new direction.
This week I am happy to promote Sleuth, which makes this whole process easy.
Sleuth is a long-time partner of Refactoring, and it helps leaders align at all levels of management. Find out how π
1) π― Beware of merchants of complexity
In our recent interview with David Heinemeier Hansson, we discussed the concept of "merchants of complexity" in the software industry, which David wrote about in a recent blog post.
David argues that companies that profit from complicated layering have an incentive to maintain it. This creates a conflict between simplifying software and sustaining a business model based on such complexity.
This is whyβDavid explainsβhe never commercialized his work on Rails:
I knew that I could have all these noble ideals about how we should build software and we should keep it simple and we should compress complexity instead of layering it away. And I'd go like, all that would eventually disappear because the incentives of needing to sustain and grow a business would overwhelm that.
By keeping Rails as an open-source project, separate from his commercial ventures, David can maintain his focus on simplicity and complexity compression, without the pressure to monetize the framework directly.
The interview is chock-full of stories and insights β you can find it below π
2) π¨ Good principles are about the how
Many companies do not invest in creating a set of engineering principles, because they are confused as to why they should be useful.
My simple answer to that is that principles describe how decisions should be made.
Why does that matter?
Without principles, you might meet goals in a way that doesn't reflect your culture:
Engineers might deliver features... without peer review
Managers might meet deadlines... by making people overwork
Teams might go fast... cutting corners on security and accessibility
Principles are a set of shared beliefs that create alignment over how you do things in your company.
They are, simultaneously:
π A definition of what good looks like
π£οΈ A shared language to be used in daily work
In other words, they create alignment and enable autonomy.
You can find our full article on engineering principles below π
3) β¬
οΈ Shift code-quality left
Code (and product) quality is a holistic virtue that comes from taking care of things at all stages. If you think you can take care of quality simply through good QA or code reviews, you are mistaken.
The best teams I know guarantee high quality throughout all the development stages, not just at the end. Here is what they do:
Great integration testing π
You obviously donβt want to catch integration errors with end-to-end testing.
Integration tests are 10x easier to write and maintain than end-to-end, so you should invest in the former to minimize the need for the latter.
Zero-defect policy π
Foster a culture where bugs are fixed asap, even if low-priority. This is a no-brainer: having few-to-none known defects at any given time makes your testing more reliable and improves the morale of your team (no deadly maintenance backlog).
It also makes it easier to identify and focus on new bugs when they come up.
Good observability + testing in prod π
I am a firm believer that engineers should own the code they write even after it gets to prod. They should use good observability tools to verify that everything works as intended, and catch bugs early.
As we discussed with Charity Majors a few months back, modern tooling today allows for an unprecedented level of inspection, and this should be totally owned by the same engineers who write the code.
Get engineers invested in quality π
The strategies above may look easy or hard to you based on how much quality already belongs to your teamβs culture. If the answer is βnot muchβ, the good news is there are practical things you can do to steer the ship.
Here is what worked for people in the community:
π«Β Get buy-in about changing your culture β get your team on board with improving. One participant of the mastermind described running a workshop with their team, getting them to describe what they were currently known for as a team (βreleasing buggy softwareβ) and what they wanted to be known for (βreleasing reliable softwareβ).
π§βπ»Β Expose devs to consequences β give engineers more exposure to the consequences of bugs. This can be done in many ways: making engineers spend some time on customer support, sharing stories about the impact of bugs on users, or involving engineers in calls with users where issues are discussed. Nobody wants to ship a shitty experience.
πΒ Make testing a first-class citizen of your process β have conversations to plan how features will be tested. Setup checklists and templates (e.g. in your design docs) to make expectations clear.
β€οΈΒ Show that you care β finally, if you are a manager, show your team that quality is important to you. Reflect on how you express this, in terms of what you talk about, what you praise, and what you criticise.
Last but not least! We are running a big survey about how engineering teams use metrics to improve their practices. You can help us below π
We are also giving away 20 paid memberships for free ($150 each!) π to people who answer the survey! We will draw the winners next month
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. 1500+ engineers and managers have joined already! Learn more about theΒ benefits of the paid plan here.
2)Β π»Β Read with your friendsΒ β Refactoring lives thanks to word of mouth. Share the article with your with someone who would like it, and get a free membership through the new referral program.
I wish you aΒ great week! βοΈ
Luca
Although I agree that good principles are important to create Aligned Autonomy without burning everyone, I find it weird that the quadrant with both high autonomy and high alignment is trust. Trust is created through accountability, which itself requires transparency and commitment (see this article from Richard Lennox about the subject https://medium.com/@richardlennox/balancing-autonomy-and-alignment-with-accountability-3a0dabe98a95). It is required for Aligned Autonomy to be sustainable and effective, but is not a result of it. The result of Aligned Autonomy is effectiveness and synergy, or in more layman words, smoothness. If you have difficulty to maintain such Aligned Autonomy however, you should certainly at any trust issue you could have within your team. Don't be blind! Blind trust is worse than no trust at all! No trust can be fixed, blind trust is like no trust but no one admitting it.