I spent quite a long time in my career hating processes and actively fighting against it. This is a fairly acceptable approach with a small team and as someone who likes talking and saying the same thing over and over again. This is me. I love to hear my own voice and I used this as an opportunity to engage with my team members.
This worked great until two things happened: 1. my organization grew to three teams and 2. I was lucky enough to have a boss that said I can only enact processes that I wrote down. I fought this pretty hard until I realized my team wasn’t getting a single message and I was engendering conflict as different people received different messages from me.
It is extremely frustrating to find out I was the cause of contention in the org I’m trying so hard to build into a caring, constructive, high performing team.
So, here’s my suggestion for building a more sustainable, empowered, and better aligned culture through writing.
Let’s take a detour to empowerment through process. One issue I’ve fought with process changes is the feeling it is handed down from on high with nary a consideration of the lowly individual contributor whose life is actually impacted by this change. This too needs to be addressed.
Step 1: Write down the change you want to make before you take it anywhere near your team. I don’t mean to preclude brainstorming and musing. But keep it away from a wider audience until you can get your thoughts formed enough to write down. Spend the time here to think through the language and grammar of this change. This is a chance to model the behavior we are building to throughout the organization.
Bonus points if your process includes some measurable metric that can tell you whether or not this was actually a good idea. This can be harder than it seems, so don’t make it gating.
Now we test how empowered a culture you are a part of.
Step 2: Put the doc in a place that is visible and editable by your team and prefix the doc and title with ‘Proposal:’ Make sure everybody knows the doc is at the rough draft portion of this endeavor.
Bonus point: Did you detail how you roll out this process change? What day does this start, what docs will be updated? When will employees be expected to conform?
For me that’s putting the doc confluence and dropping it into a chat room #squad-process-changes
Using a wiki or slack is really just tactics. The key is there is one source of truth that can be commented on publicly and even changed by those who are affected. So, give the team a few days, coach them that they should raise any concerns (give a timeline for feedback) and ask for sign off. A manager’s output is only the sum of the team they run so getting buy-in is powerful.
So, in a perfect world, you’ve got a process written down, vetted by your team and it’ll either now be the new way the world works or you will know without a doubt that implementing this is going to be an uphill battle.
All of this is much better than a surprise email your team receives from you about another crazy change they didn’t get a vote on. Oh, and the next time you find your team members arguing about the process they can point at a doc and even change it if it’s due to ambiguity. (But that’s another process change)
Some further reading:
- High Output Management
- a16z Podcast: Amazon Narratives — Memos, Working Backwards from Release, More