Process. It gets such a bad rep. Just like reorgs.
You probably know engineers — or maybe you are one — who say they don’t like process because they just want to get stuff done. Process is often equated with the sense of dread when you have too many meetings, multiple trackers to update, and someone constantly asking you to break things down into smaller tasks. But you’ve probably also worked on teams when everything just clicked. You knew what you were working on, you felt empowered to make decisions, and there was very little friction to just do it. Surprise — that’s process too.
Process is the tactical framework by which work gets done. It can be skeletal or extremely granular. Whether or not you call it process, it’s there, implicitly or explicitly. On a two-person team, the process may be turning to each other when you both get in, and saying “good morning, I think I’m going to try to get this PR merged today 👍.” On a twenty person team, it may be daily back-to-back sub-team stand-ups, weekly all-hands and email updates, and Jira/Asana tasks for each ongoing project.
The thing is, there’s no one-size-fits-all. This is a surprise to people as they take what worked in a team that clicked and try to apply those same tactical tools, meetings, and updates to a new team that looks roughly the same. That’s the project management equivalent of parents saying, “Hey, don’t do all these things. I made those mistakes when I was your age, so you don’t have to make them. You’re welcome.” There are good starting points, but what will really make a team click is the process by which process evolves. Respecting that is important.
The best example I have of really embracing a collaborative approach to team process (or you might say, process process 😂), was from my time at Medium.
A few years ago, I was on somewhat of a rogue team at Medium with katie zhu working on Publications. We decided on setting weekly goals, and one of us wrote it up on the whiteboard behind our desks. We had very low overhead in team communication, so we made quick progress towards some substantial features. We also had no designer, so we just did whatever we felt looked good enough.
A few more engineers joined, and we introduced a weekly “tactical” meeting, which was the standard meeting for all teams at Medium (note that we didn’t have this when it was just two of us). After a few weeks, we found that we really missed the focus of weekly goals, so we added a 15 minute segment for weekly planning to our meeting. Katie would come with a proposal for things we might work on the next week, and as a team, we pruned it down together to roughly 3–5 items, and people volunteered for them on the spot.
The whiteboard experienced a little upgrade too. Each item started off the week with a red dash. When an engineer started working on it, they changed it to a yellow dash, and when it was complete, it was turned to green. At a glance, anyone walking by could see how the team was tracking towards weekly goals.
At some point, another engineer suggested we do a “retro” every week. In order to minimize multiple team meetings, we smooshed it into one hour-long meeting (30 min tactical meeting, 15 min retro, 15 min weekly planning), and officially called it “Publications Franken-meeting.”
Within a few months, as engineers switched teams or people sat in different meetings, news of the amazing Franken-meeting spread, and soon all the product teams had their own versions of Franken-meetings, a heavily-facilitated mishmash of whatever it was the team needed at that time. Some strategic teams saved a 20 min slot for a special topic discussion, and some allocated time for demos or design feedback.
In my five years at Medium, and many more years building product, that team stood out to me, because the way we approached process was extremely collaborative and we iterated on it all the time, based on feedback and suggestions from the team.
Process is constantly evolving, which is why the title of this post is misleading. There is no Goldilocks process, no prescriptive out-of-the-box solution for teams with 3–5 engineers, and another for teams with 5–10 engineers. There are cookie-cutter solutions that are good starting points, and it’s worthwhile to figure out what that is, so you’re not re-inventing the wheel every time you switch teams. But the secret sauce is really in how that evolves over time. Here are some best practices:
Collaborate
Process is often introduced as overreaction, like holy-shit-we’ve-grown, now we’re going to track all our tasks, and break down everything, and let’s add all these meetings while we’re at it. When your team kicks off, include everyone and get input into a lightweight process to start. Engineers will feel far more ownership and commitment to a process that feels dynamic and homegrown. Enlist team members and delegate some of the setup work — creating new slack channels, calendar invites, trello boards — but please be careful who you assign office housework to. As an engineer, identifying and filling in a gap in a team’s formation can be energizing!
Consider the physical
The joy in the physical act of crossing something off a whiteboard as you complete it just hasn’t been replicated in a web browser. If your team is co-located, get a whiteboard and use it wisely. Use it for stand-ups to see if people are on track for their weekly goals, draw a launch calendar on it, or just write out the team’s high-level purpose. It can also be a powerful way to casually communicate goals and priorities with the company.
Optimize for the Do-ers
When a team transitions from “low-process” whiteboard life to Jira/Asana/Trello, engineers often experience a huge loss of ownership. The virtual tasks may start to be created and assigned by PMs, and it can feel like the work spent keeping those tools up-to-date are for the benefit of higher-ups, rather than genuinely something that streamlines the work. If you’re a manager on a team, be clear about what it is you need to do your work (perhaps having an easy way to know if the team is on-track towards a milestone), but then let the do-ers fill in the rest. Instead of micro-managing small tasks, provide high-level alignment, start from a place of trust, and coach people to communicate well.
People vs Process problems
Don’t solve people problems with process! When you think about introducing something to your team’s process — say, an extra checkpoint before shipping — ask yourself if you’re really trying to solve a people problem. Do you need to have an uncomfortable conversation with an engineer about sloppy quality issues? Do that instead. It’s way easier to add process than remove it, so be wary.
Prune your process
Just like houses accumulate clutter, so do processes. Take a step back every once in awhile to think critically about the value something is providing. It may be worth experimenting with the weekly update to the company that takes you 2 hours to put together each week. See if something more concise serves the same purpose, or try every other week. See if two team meetings can be consolidated into one, or if one can be removed altogether. Ask for feedback and check in with the team afterwards to see if it is missed.
Pay attention
Heavy processes introduced over time can gradually wear on a team’s intrinsic motivation, and lead to people feeling like a “cog” rather than a valued member of a team. Engineers become conditioned to just work on the next task, without understanding how it fits into a team’s purpose. Or they may stop taking initiative on their own. But it takes a fairly self-aware engineer to pinpoint process for that lack of motivation. Pay attention to energy levels on the team and in one-on-ones.
Also pay attention to what other teams in the organization are doing, and if there are ways to integrate best practices into your team.
Earlier today, I asked this question on twitter, and got a few responses.
Please add your stories as responses to this post, or reply on twitter!
If you’d like help scaling your team or developing yourself as an engineering leader, email me at jean@jeanhsu.com.
