Process == Culture
“Process should be written by those who are not only intimately experiencing the pain of a lack of process, but who are also experts in the culture.”
— Michael Lopp
I was recently reading an old Rands In Repose article about process with the team leads here at WayUp, and though I’d read the article many times before, this sentence got me thinking.
As a company grows, the process needs to change. What works as a four person team doesn’t work at 16 and definitely doesn’t work at 256. This seems obvious, but it is easy to get stuck in a process that once worked great and not recognize that it’s not working anymore.
The obvious path is to create a process based on what you want the outcome to be. Need fewer bugs? Add a QA team, problem solved! However, it is important to consider what values you are enforcing when you create a process — not just what you do, but why you do it. In reducing bugs, who should own quality in the team, and how is quality being delivered?
By examining culture decisions such as this, you’ll make better decisions about how you define your process. Let’s look at a few examples.
Quality Assurance
Since we’ve started talking about bugs, let’s dive into developing the QA process. Quality adds time into both the development and testing processes and adds expense in those areas as well. The choices you make about including QA in your process will directly reflect how you value quality versus expense and time to market– the worst thing you can do is address one without considering the others.
At one end of the spectrum you can choose to expect quality to emerge naturally from your process, while at the other end you can include a step where a person dedicated to quality needs to sign off on every release. Measures that fall in between these ends include an additional developer doing a code review, having a product manager sign-off, or having a quality engineer writing automated tests as part of a seperate release process.
Who in this processes owns quality? If you have a person whose job it is to assure no bugs get into production, then maybe they own quality. But is quality only measured in a lack of bugs? What about customer satisfaction? What about efficiency for scale and cost? Is a feature is delivered with a minor bug less valuable than the same feature a week later without a bug?
You should not run a medical device company or a bank with the same quality processes as a social media network or blogging site. How you measure quality and who owns it will depend on your business and what you believe you need to be successful.
If a defect-free product is your highest priority, you may include a dedicated tester in your process with the final say on when a release is ready. If product-market fit is more important to you, you may rely on releasing quickly, fixing defects on-the-fly and handing the responsibility for quality to your product and engineering team. There’s no wrong way to do it, but some ways will be a bad fit for your goals.
The Deploy
Another process that every web development shop has is deploying code. In a small company, often just one person is involved in the deployment. The developer deploys the code, fin. However, as a company grows, more people can get involved: a product manager, a quality assurance expert, a systems administrator. All of these individuals may be involved in the process, or it may still be just the developer, even in a 5,000-person company.
Who in your process you choose to have control deploys is just as important as how a deploy is executed, and it speaks volumes to what you value. If you have developers execute deploys, it shows you value speed and trust the team. However, that kind of approach may not be appropriate for products with very high service level guarantees, such as air traffic system — in which case, deploys may be controlled by systems administrators who can more easily manage the integrity of the system. For security products, it might even be a security expert that controls the deploy. Ultimately, the person doing the deploy is accountable as the final arbiter of deciding “this is ready to go,” which then speaks to your team and your company about what YOU think “ready to go” means.
Who do you want to have final say on when something is finished? Who is responsible for maintaining uptime for the site? Who is responsible for the reliability of the system? Do you want an audit trail of deployments to hold people accountable?
The fewer people that are involved, the more focused the accountability. If a developer pushes code without consulting anyone, that developer is responsible for the outcome. As you add deploy controls for product, QA, and administrators, they become accountable for different aspects of the outcome of the deploy, and you can draw a direct line between process and outcome responsibilities.
The Process Mirror
All these questions speak directly to your engineering culture, and they also define your process. If your quality assurance team is responsible for any bugs, you might want to give them a signoff. If the development team is responsible for bugs (they wrote them), then maybe you don’t.
Whether you intend it to or not, your process does reflect your culture. Every process you put in place, even the unintended ones, plays a part in your team’s productivity, their happiness, and your company’s well-being.
You will need process as your company grows, but you need to be thoughtful in not just what it is, but why it is. You need to be sure you can explain how it reflects what you want in your engineering culture.
