In the beginning…
I started Cofruition on my own.
At the beginning I would essentially do all of the roles in the company (apart from the audio editing) which meant I was often switching between tasks. We didn’t have much cash coming in, and so the trade off was my time.
This was always a stepping stone though – I knew that I would hire others who were better than me, and so I documented the repeatable steps I was doing.
In the Myers-Briggs world I test positive for INTJ, and so not only do I naturally think in systems, I inherently enjoy breaking down complex projects into smaller chunks, and seeing the dependencies between them.
Once we began to get steady revenue into the company, I made my first hires and essentially delegated the processes I’d been doing (e.g. how to produce a podcast episode; how to make social media assets; how to onboard a new client).
The handover process was a version of “I do; We do; You do” and before long, a lot of the delivery side of the business was being done by people much better than me which meant I could use my headspace to focus on growth.
v1: This how to do it
When I did my handover I would have a very detailed process.
As in, 10 steps on precisely which buttons to press and what name to give the image files and folders in Google Drive.
The result at first was that things would get done exactly the way I wanted them to be done which, at the time I felt like I was being an excellent manager (“Look at how much clarity I’m giving!”).
However with time, I noticed that things would begin to slip.
People came to feel like the process steps I’d written were sacred, and tried to follow them at all costs, even when it led to bad outcomes.
I came to realise that there are downsides to well-documented Standard Operating Procedures…
Empowerment by ownership
The root of the issue was the people following the procedures would just follow steps and not really think about what they were doing.
As such, when work passed through the production line, an error at one stage (e.g. a typo in an episode description) would go unchecked when it was then published.
The result: we published an episode with an error (that we later fixed).
When this happened I’d get frustrated, and my natural reaction was that we need more process (“Let’s include a step in the checklist to check for typos”) however I think this actually creates a bad dynamic that stifles the critical thinking I want from people.
You can’t anticipate every problem that could arise, and so empower your team to solve it on their own
In practice, this means setting the ideal outcome, and then making the person doing the task responsible for it getting done.
From what I’ve seen, this leads to much better outcomes, as the team feel involved in the ultimate outcome, and so are more interested in achieving that, than ensuring that all of the boxes have been ticked.
Not throwing the baby out with the bathwater
Don’t get me wrong, I still think systems and documentation are important and really valuable.
For all of our key deliverables in the business we have a process that documents the key steps that we’ve found have led to the best outcome. When we notice something could be done better, we update it, which means next time we do it even better.
What we’ve changed though, is incorporating much more flexibility into the “messy” parts of our processes.
For example, when we onboard a new client, there are various administrative tasks to do to get things set up operationally (dedicated email address; set up Google Drive with correct permissions; copy over relevant templates; update client details etc.). I think these are perfect for systemisation, because they often get overlooked, but are important to ensure we have streamlined operations.
But when it comes to the order of how we take a new client from kick off meeting to publishing their show, we’re much less prescriptive. We have various workstreams we know benefit from being completed in a certain order, but we instead let the account manager use their judgement as to how to manage things.
The result has been that our account managers feel more empowered (“Am I doing it wrong because I’m not following the checklist?”) whilst we still have a system for documenting and referring to best practices.
v2: out of the weeds + into direction setting
Now that Cofruition is growing, it’s bad for the company if I’m stuck in the weeds of giving feedback on particular projects.
There are a couple of practical things that I’ve instilled to ensure this doesn’t happen, but that we still maintain our high standards.
No more (active) Quality Assurance
The incident last week clarified that I really shouldn’t be spending hours of my day getting stressed that someone hasn’t named an image in the way I wanted it to be done, and get back to the more strategic things.
Our organisation looks a bit like this:
My new rule of thumb is that if there’s a project I’m leading, I’ll do some thinking and then hand it over to one of the employees (this tweet by Lauren Roeder neatly explains the mindset 😅). The employee is then responsible for converting my ideas into something that they, or another team member, can feel empowered to run.
This is how I would do it
The systems thinker in me still defaults to thinking of things in step-by-step processes and I think there’s value in me sharing how I’ve thought about it, rather than giving people a blank piece of paper.
What I try to do now though is a combination of being more specific on what are the important aspects of a new process, and how I would do it.
For example
- “Name the image files in this way and put them in a subfolder in the episode folder with this naming convention” becomes
- “It’s important that we can easily retrieve images if we need to find them in the future. One way to do this could be to name the image files in this way and put them in a subfolder in the episode folder with this naming convention”
This gives the person a starting point, but then after a while they might realise that actually it makes sense to put all of the episode images in one mega folder based on asset type. Or that they can be stored elsewhere in our process.
Moving from How to Who + What system
I initially thought my change of getting out of the weeds and giving people more responsibility was a change from “How (am I going to do this)” to “What (is the outcome I want)”.
I then read the From 6 to 7 Figures book by Austin Netzley of 2x.co (which you can download for free here) which I think had a better mantra: instead of how am I going to do this, Who (should do this) and What system (do they need).
In any case, it’s a way to catch oneself as a leader in a business of not getting into firefighting mode, or treating problems as one-offs, but instead understanding the root cause of why something happened and spending your attention there.
Part of giving someone a system to take ownership of is clearly communicating the outcomes (especially the important ones that might not be obvious for them) and so it feels like it incorporates that too.
Summary – v3 coming soon…
I’m sure this is not the final outcome for how me and the rest of the Cofruition team work and that as we go through the next stage of growth, more things will crop up to solve and adapt our practices.
That said, if you’re at the stage where some of these things resonated, then I hope you found this helpful!
Happy to answer any questions you might have based on my experience so far.