You may have heard about the five monkeys experiment, a cautionary tale sometimes used to illustrate how we can get locked up in an organisational harness without sufficient hindsight, power or leeway to change the way things are.
This comparison may sound unflattering, but I have seen similar situations in previous lives, where a process I don’t understand is enforced, and I simply end up complying and assimilating it as normal. No-one is really responsible for that process, it may not even be relevant anymore, but it’s still there and is so much part of the habits that nobody thinks of questioning it, or the ones who do get dismissed with a “that’s how it is”.
Of course not all processes are like this. All organisations have frictions, and introducing processes or rituals is a sensible answer to some of them. When well thought out, good processes can avoid outage, enforce continuous improvement, ease up newcomers’ onboarding, pay out tech debt… Bottom line, they can help save time, secure the future and improve customer satisfaction.
So we’ve tried to formalise below a few basic rules that should help building a good team process.
People will apply it more easily if they understand where it comes from. Making sure everyone knows what the process achieves, for whom, and the context in which it emerged will ease up a great deal the team’s adhesion to it. It’s therefore the manager’s responsibility to carefully onboard a newcomer on the existing processes, so they can adhere to them.
For instance, in a consulting company, when you’ve gotten a glimpse at the work of an accountant who needs to bill the clients at the end of each month, you’ll be much more inclined to fill your timesheets thoroughly.
A corollary to the previous point is that a process will be even better understood if the team that ends up applying it contributes to its definition. Even if the initial need is not theirs, it’s much more empowering and deemed to succeed if the team members actually comes up with the solution by themselves. The underlying need must first be stripped from any assumed solution. It can then be well explained and discussed beforehand, so that the team can fully appreciate what it’s about, and come up with the best solution to address it in their day to day context. Sometimes the solution may even appear to be much easier and more definitive than expected.
Team retrospectives are often a good opportunity to identify a friction that could be addressed by a new or updated process. It’s also ok to get inspiration from elsewhere, but beware of cargo cult. Don’t parachute new tools or processes into your organisation because you’ve heard about the results they’ve achieved somewhere else. Understand what they’re trying to achieve and how to adapt them to your specific context.
A process addresses a need at a given time. This need, and its context, will very likely evolve, possibly to the point where the process is no longer the best answer to a changed situation. So every now and then, it’s always healthy to discuss it, reassess its relevance, improve it or remove it altogether. A newcomer’s arrival in the team, providing a fresh perspective and some different experience, is often a good opportunity to challenge the status quo and make sure the team still has the best fit processes with regards to their tasks.
For instance, we have daily stand-ups with the whole dev team, so we can keep up with the other squad’s ongoing works, identify mutualisable effort, and ask for / offer help. This used to be done in a big conference room with the few remote workers connected to a meet, and that worked pretty well at that time. After the first Covid lockdown and related furlough, though, some of us were working part time, most of us fully remotely, and this format soon proved unadapted to this new situation. Instead of forcibly maintaining this ritual as is, we iterated on new formats until we reached the current one where we’re having synchronous fully online stand-ups twice a week, and async written stand-ups every other days. That works well now, and may change again as the situation evolves.
It can already feel cumbersome enough to comply with some processes, so you should make sure you do everything possible to make it as seamless as possible. Automate everything you can, make sure the team members are reminded of the process when the time is right, document all useful resources, links and details in the reminder, and provide all the possible tooling that can help complete the process in an automated fashion. The automation also saves the manager or the stakeholder the painful task of manually chasing up the people involved in the process. Ideally the tooling is also flexible and accessible enough for the team to update and improve it by themselves as they get more familiar with the process.
The tooling must be helpful, and thought out to support the process ; the process must not be bent to suit the tool. Most recent softwares expose APIs to ease custom tooling. As an example, we built many custom integrations between Slack, Github, Bugsnag, New Relic, Google Suite… so that most unnecessary overhead is automated, and only the human added value is required from the teams.
The key take-away here is for the team to own the processes, instead of letting them own the team. Start with the need, get the people who will end up addressing this need to help, figure out a solution and its tooling together, and iterate over it whenever the necessity arises.