Process is not a four-letter word
Summary
Knowledge workers are often mistrusting of processes for the corporate red-tape they create. But effective processes have their benefits.
They take away the guesswork from common tasks.
They enable moonlighting managers who can focus on their craft.
Team members can step up and support their managers with leadership responsibilities.
The article also summarises four principles to craft effective processes.
Some years back, I worked part-time on an operations team for a tech company. While tech teams often have a bunch of standard protocols, this team took “individuals and interactions over processes and tools” to heart. Tasks would fly around via email and chat. As a part-timer, I’d spend much time scrolling through email and chat, trying to make sense of the work-in-progress. There was no knowledge base for the team’s work content or standard protocols. The only identifiable pattern was to throw out tasks on ephemeral channels and then “brainstorm” the action plan for each. The lack of repeatability meant that we were second-guessing each other all the time, and since I wasn’t always clued in, I spent 50% of my two days a week just catching up on communication. Long story short, it was a mess.
Knowledge workers, especially technologists, often disdain “process.” I shared some of this contempt when I first encountered agile software development. Individuals and interactions over processes and tools? A younger Sumeet would have said, “Take me to church!” and for good reason. Before I worked for Thoughtworks, there wasn’t a good thing I could have said about the processes I’d encountered in my short career. If anything, most processes came in the way of practical work.
Of course, I was naive to imagine that being agile implies a lack of process or leadership. Sure, the process can’t be the end-all, but ignoring processes creates confusion. Everyone imagines the process in their heads, and before you know it, your team feels like the six blind people and the elephant.
Is this how your team perceives your ways of working?
Many modern leaders rightly dislike micro-managing their teams. The best leaders I’ve worked with are moonlighting managers - creators first, managers next. Staying close to actual work helps these managers stay sharp at advising and empathising with people reporting to them. But being a moonlighting manager isn’t for free. If you don’t have a process that chugs along without your intervention, you’ll have no time to get your feet wet.
So, in today’s post, I want to make the case for managing your processes. You must think about them enough, but not as much as you fear you will.
More partners, less resources
Like this website, the corporate world is obsessed with leadership. Starting in the late 1980s and continuing into the 1990s and this century, Robert Kelley, Jon Howell, and others have urged the industry to also focus on followership. Ira Chaleff’s model of followership is one of the more well-known models that describe different team members in terms of how much they challenge and support their supervisors.
Chaleff categorises followers on a 2x2 matrix.
Resources (low challenge, low support): These individuals do the least necessary to fulfil their job requirements. They neither challenge nor support their supervisors. Think of them as quiet quitters.
Individualists (high challenge, low support): These individuals challenge their supervisors but provide little support when driving to an objective.
Implementers (low challenge, high support): Implementers are troopers. They do everything they can to achieve a goal but rarely question or challenge their managers.
Partners (high challenge, high support): Like any other 2x2 matrix, being high and to the right is the holy grail. Partners keep their supervisors honest and back them up to get things done.
Chaleff’s followership model
Healthy teams are chock-full of partners. These partners own the team’s objectives and create an environment that supports moonlighting managers.
Raise your bus factor
On agile teams, we use the “bus factor” concept to measure a team's resilience. It refers to the minimum number of people that must disappear from a team before all work stalls. If you know how to perform your role as a manager, your bus factor is the lowest possible — 1.
Well-defined processes help you reduce your managerial involvement and encourage your team to act as owners and custodians. You don’t need a pesky manager to ask for status updates - the team knows better to keep Jira updated daily. The boss needn’t orchestrate retros - the team cares about continuous improvement enough. The client needn’t nag the developers to develop functionality for which the users are hankering. The team knows how to prioritise work, so they push the highest value increments out of the door first.
A team chock-full of partners doesn’t come for free, though. To get to this level, you, as a manager, must collaborate with your colleagues to demystify your work through tools, checklists, or rituals. And remember, what you don’t write, people imagine. So, once you agree on a way of working, document it. When you improve the process, update the document. In time, the team understands and owns your processes enough that you can get out of their way and do your thing.
Four principles to build team-owned processes
Shared reality is a crucial pillar of TeamOps; well-documented processes drive this sentiment. But if you’re an unassuming manager, you probably dread this idea of process documentation. I’m here to tell you that it needn’t be so dreadful. Enlist your team’s support to start this activity, and you’ll have partners right there. I recommend keeping a few fundamental principles in mind as you iterate through this activity.
Dependability matters. Teams perform well when members can rely on each other. When designing your processes, assume a standard level of professionalism. Here are a few examples.
How early should clients know about possible delays in the schedule?
What level of detail should a ready-for-development user story have?
What’s a reasonable time frame to respond to a pull request?
Who is responsible for documenting a meeting?
Don’t ignore the smells. We often assume good intent and follow the lead of other team members. In most cases, this is a sensible default. But frequently, people follow a particular way of working because they haven’t considered an alternative yet. In these cases, status quo bias can be dangerous. Don’t normalise the problem. Problematise the normal. Here are a few examples.
Ineffective meetings are not OK. Implement forcing functions to get the most out of your time together.
It’s not OK to overwork teams. Consider how you scope and prioritise work so teams deliver value at a sustainable pace.
It’s not OK for new hires to thrash around in a team. Design your onboarding process so a new team member can be productive in less than a week.
Plan for exceptions. Things will inevitably go wrong; if they do, you must know how to deal with those exceptions. Think about how you’ll respond to emergencies, escalations or critical errors. Here are a few examples.
What’s the team’s protocol to deal with urgent issues?
When I know I’ve made a mistake, how can I undo it quickly?
If someone’s not doing their job well, who are they accountable to?
If a production system goes down, what’s the protocol to bring it back up?
Clear the critical path. Last but not least, it’s essential to design processes for flow. Too often, we create bloated protocols that slow us down. People’s disdain for process comes from corporate red tape. Effective teams eliminate red-tapism. Here are some triggers to get you thinking.
How can you simplify decisions so your team’s always making progress?
What are your sensible defaults so you don’t waste time reinventing the wheel?
What percentage of your work can you complete without gate checks or approvals?
“Your system should be as simple as it can be and no simpler.” - David Allen
Effective processes become muscle memory and free us to pay attention to what matters, i.e., the creative work we do. Simple, elegant processes help followers become partners with their leaders. They also enable managers to stay hands-on and not become the annoying pointy-haired boss of Dilbert fame. In a distributed team, effective processes can also foster a sense of calmness. Yes, “individuals and interactions” matter, but “process” isn’t a four-letter word, literally or figuratively speaking!