Engineering Processes

Illustration by Fiona Stabler

Engineering teams can have any number of processes. They have those rituals like stand-ups, retrospectives, planning meetings, and sometimes there are specific steps for raising a bug or fixing one. If I'm being honest, I don't feel too excited by the idea of more process—I usually think "Here we go. Someone at a cool company said this is so hot right now so we have to do it too. When can I get back to work?".

Very occasionally, however, I'll come across a process that I find genuinely valuable and I'll suggest it to the teams I work with, only to hear them say "Here we go. Someone at a cool company said this is so hot right now so we have to do it too. When can I get back to work?".

Finding the processes that work for your team, and those that don't, can take a bit of time to figure out. Your suggestions might not always be chosen. But, it can be worthwhile from a team-health point of view to push through and establish what works best for the team you're in.

Something that took me too long to figure it out is that we can have personal processes too. Hooray! I would even say it's our responsibility to have them if we want to take our careers seriously. These are the ones we follow because they're valuable to us even when the team we're in doesn't necessarily embrace them.

Take personal development, for example. A few years ago, I wrote about what it means to me and how I approach it on the FreeAgent engineering blog. It's something I value, but not every company I work with is going to be OK with me spending an hour a week working on myself. It's still important to me though, so I make time for it out of hours.

When I worked at FreeAgent we were big on our incident response process. When the proverbial shit hit the fan we had a well thought through procedure to follow, which boiled down to:

1. Get those involved on a call
2. Write everything down in an incident doc so others can catch up
3. Fix the problem
4. What can we do to prevent this from happening again?

Not all companies, especially smaller ones, have this figured out and I've seen varying levels of chaos because of it. Having an incident response process is now something that I really value personally. I follow it even if I'm working on my own or if the team I'm working with don't want one. Documenting what went wrong and how it was fixed has been invaluable.

Your career is going to be much bigger than the place you're working at right now and I think it's very easy to forget that. You don't need to read all the books on engineering processes (they're very dry), but what I would recommend is taking a minute to think about your team's current processes. Which of them will you take with you when you leave? Which ones will you try and introduce to the other teams you join?

We talk a lot about ownership in engineering, and we usually mean owning the code we write or the project we're leading, but taking ownership of our career is the foundation of being a happy team member. I think part of that ownership is deciding what we value as individuals.

I've been involved in a lot of different engineering processes over the years. There's no one size that fits all and I've had problems with some of them, but others I've liked. When I come across processes that work for me, I pick them up and I pop them in my pocket for later.