image of the developer

ellen wondra

software engineer. pet herder. crafty.

My Values at Work: Iterate on Processes, Not People


This is the second in my series on my values at work! To read the first, go here

I'm looking for a job. This means that I am going through the job interviewing process, and talking with a lot of different people about myself, and which values I embody and need to share with my employer. One value that I embody to action, and that I often repeat, is this: iterate on processes, not people. But what does that mean?

Sometimes, in a group or an organization, it can be tempting to iterate on people until you get things right. By this, I mean, feedback loops are tied primarily to individual performance, and when the outcome is negative or the system fails, an individual is fired or removed and replaced, ad infinitum, until the right combination of people is found. This is in opposition to what I call iterating on process, which looks at a failure in the system as an opportunity to build training, add tests, and locate new avenues for mentorship programs.

There are parts of iterating on people that are tempting. Sometimes people are bad fits for the group. There are also absolutely problems and people who cannot be fixed by systemic adjustment, like predators. Iterating on your personnel and firing a sexual predator is a great way to improve your company. Additionally, individualistic blame is often less complex to resolve, on a number of levels. It's easier to move a cog than it is to move the entire machine.

But the reality of a person-iterative-focused-paradigm is that it ignores the fact that a negative outcome is, almost always, systemic failure. Most big companies are complex systems full of people working carefully together, not siloed wizards of industry. Acknowledging this is not an abdication of personal responsibility; far from it. It is simply an opportunity to create better processes and technology, instead of succumbing to the tempting tune of monoculture--which is, of course, the other big sin of iterating on people and not process: while it theoretically operates just on business principles, in practice it often leads to monoculture, smoothing out personalities that stick out, disproportionally punishing people of color, gender diverse folks, people from non-traditional backgrounds, etc. 

So what does iterating on process and not people look like in practice? Let me give you an example.

A few years ago, I worked on a consulting team with a brilliant designer, let's call her D. She saved our butts on a number of projects, both by making them beautiful, and by making them accessible and utilitarian. In doing so, she often broke the hell out of our code. I mean, anytime D touched the code, we knew we'd need 5 minutes to 2 hours to fix what she had done, and then we might need to pass it back to her to fix what we had broken in the UI, and then the cycle would begin again. Her design work was unparalleled (and, frankly, still is from what I have seen) but her code was abysmal.

Another company might have fired her and replaced her with someone more like the rest of us, who knew more code, even though they weren't as good at design. They might have given her homework, cut her time on the job in half so she could become more like us and stop making these mistakes. She was essential on every product, though; we needed her time where it was.

What we did instead was take time to look at the points where the process was failing. We realized that we didn't need to teach her to do our jobs; we just needed to flag which parts of the code were important and could not change without altering the function of our product. Code already has a way to do that--testing!

By adding more tests into our process, and a githook to make sure that the tests ran before committing code, we were able to significantly increase the quality of the code we were running, identify problems sooner, and prevent the issues we had been having before, all while ultimately spending less time than we had been spending putting out fires. And by keeping D on our team, and paying attention to the parts of the process that weren't serving her brilliance, we both kept an incredibly valuable team member and got to learn from her for years. I owe a lot of my early knowledge of accessibility and usability to D. I am a much better engineer because we improved our process to value the insights and skills that she gave me and the whole team.

Make no mistake: iterating on process requires work and commitment. Processes are hard to create, hard to maintain, hard to pivot from once established. But if there's one crucial thing I have learned as an engineer, it is this: you never go wrong when you value your stakeholders. That always leads you in the right direction.

Iterate on processes, not people.

my values at work ethics in tech processes not people