Quality In, Not Out
Hey!
Welcome to February! We're finally out of January, felt like it had 100 days. I hope you had an excellent weekend.
Was this forwarded to you? You can subscribe here!
Things I enjoyed in the past week
- The Friction Fix: Change What Matters, a nice article about how to go about fixing what create friction from a systems thinking lens.
- I keep researching AI usage and came across AGENTS.md, which outperforms skills in our agent evals blog post from Vercel. I found it interesting to see how they evaluated the two approaches.
Everything about quality and how are practical ways to make it part of the process instead of inspecting it? There's a quote by Deming (which is not, actually) that goes something like, "If you're inspecting for quality, you're already too late." Basically, you're only checking what quality is already there, good or bad, compared to making quality part of the process, such that you keep improving with each iteration that comes out of your software.
I'm thinking a lot about that because where I work, we have many manual processes that still require significant human validation at the end of the delivery. You can imagine we have a project, and then, when we design the solution and everything, part of the project planning includes an end-to-end testing phase at the end of the project, making sure, in theory, that everything works well. As you can imagine, based on my quote, in practice, it means it is too late to review something at the end-of-the-line phase right before delivery. You will always be late; there will always be bugs, and software will always take time to coordinate.
If you have a front-end system that depends on a back-end and those changes need to be synchronized or at the very least coordinated such that you can only release something first and something later, and you cannot release one thing without the other, then you already lost the plot.
In practice, there's really nothing you have to take a step back and review what you are talking about, or what you're in terms of expectations of what you think you are verifying, what you're actually verifying. If you are doing the end-to-end phase just because it's a check you have to pass before delivering a project, not because you really want to deliver the best quality possible.
How do we get quality in?
It is more than having a Quality Assurance (QA) team present at every step of the process, which would require many people!
Instead, we have to set up ways to ensure every step is done to a certain standard, and that largely comes from ownership of the teams at each step. Ownership not only means we'll setup ground rules for the quality of our "piece", like we'll draft Jira tickets this way, but also comes from openness to accept whenever something is not working.
There's no recipe for success here; it will be based on the context of your organization and the socio-technical system in place, what pressures your teams to deliver to their customers, time, money, etc. Deming promoted the PDSA (Plan-Do-Study-Act) process, which has a better ring to what I described earlier. And you can read about learning organizations in The Fifth Discipline.
Your turn!
How do you help your team(s) deliver quality? Do you depend on other teams to "certify" the quality of what you're shipping? Let me know your thoughts by replying to this email!
Happy coding!
