Standard Operating Procedure, process, workflow… a couple of years ago I thought these were all by words for bloat and the antithesis of working quickly or making progress. It’s fair to say I’ve done a full turn on that one: I now run a process-driven company where how we do everything is built around process.
This post isn’t about that, though: this about how we use process to be a technology-driven service company.
Working with process in a business that relies on humans doing the work is nothing new. Using technology to add scale to those processes is a different and exciting way if doing things.
We work with technology companies, and a common viewpoint is that services don’t scale. Products are viewed as the superior option for their scale. One client even said to me once; “Alex you’re not stupid, so why don’t you make products?”
I see our processes as the product, and building technology around those services is how we scale. We do, of course, need to offer services led by humans and we’ll never dramatically scale beyond the number of hours the team works in a week. But, I suspect how we’ve scaled our processes and become a technology-driven company wasn’t possible even a couple of years ago. I also suspect others are massively under-utilising the methodology we use. This post aims to be insightful and enlightening.
Selling process-driven work
A couple of years ago I remember telling a friend who was asking how business was going: “business is going great, as I’ve accidentally productised our services”.
I accidentally productised services because I had very strong positioning that meant potential clients were coming to me with the same problem repeatedly. I hated writing proposals, so I started copying and pasting from one email to another. Over time, the emails became completely standardised, I moved from a day rate to a fixed price, and my first productised service was created.
“Productised services” are often positioned as a way of taking services and disruptively offering them through a potent mix of low cost labour and technology, all at one convenient price (or more often, a selection of profit-maximising prices).
Maybe I’ve misunderstood, but I always got the impression that this was done with the aim of offering good-enough value whilst maximising profits and letting the business owner move on to something else whilst keeping the income coming in.
That’s not for me, but accidentally productising my freelance work all those years ago was the vital first step to selling process-driven work as it set up a repeatable set of todos with each project. This then led me to start offering other services based on outputs rather than time. This is the key to leveraging technology, as it aligns everyone’s incentives: the customer pays for the value created, and you can look for ways to save time or add more value than one could add if you started from scratch each time.
Recently we’ve started doing some hourly-based projects. They have their place, and given uncertain scopes for example, they can let us flexibly accommodate the client’s needs. Accidentally productising all those years ago, though, was how this all started and an extremely helpful (although not key) prerequisite for becoming a technology-driven service company.
Building process
Whilst it was bits of freelance work that led to me creating our first product, it was our monthly retainers that led to us becoming a process-driven company.
The monthly retainers followed the success of the first product: a set of deliverables each month for a fixed fee.
Over time as we listened to customer needs and identified trends, we packaged up different parts of the retainers and our flagship Content Growth product was created. This led to us doing the same type of work for different clients.
The kicker, though, was that the retainer was month-based: we had to deliver the work each month, and start again at the start of the next month. This became a kicker because the work would start kicking you if you didn’t keep up, and in the early days it started kicking – hard.
This wasn’t a challenge of capacity: we had the people to get the work done. It was a question of process. We needed to build a production line capable of getting high-quality results every time, and we needed to do it quickly as otherwise the work would become overwhelming.
Leading up to the Summer of 2019 was a turning point: I was getting married and planned to take three weeks off for the wedding and our honeymoon. I’m always offline from work when I’m on holiday, but we were going to The Galapagos islands and I wouldn’t be able to get online if I wanted to.
The business was doing reasonably well, but with most of our revenue based around monthly retainers, I didn’t want to skip a month and lose a 1/12 of our revenue. The challenge, then, was to build sufficient processes ahead of the honeymoon to let me take the time off.
I’ve not read The Four Hour Workweek, but I’m pretty sure this is a similar story: Tim Ferriss wanted to take a vacation so he built out processes to handle all the work. In Tim’s case, he never really went back to work. In mine, I came back to work and found everything was just about still working. At this point I’d mostly created a job, rather than a business. It was clear that the processes needed significant work.
Iterating process
Automation is certainly one way to improve the leverage of all types of work. Having machines to help them, human beings can create more output. But in both widget manufacturing and administrative work, something else can also increase the productivity of the black box. This is called work simplification.
Andrew Grove
We spent the next 12 months iterating our processes. In this time we had our first two team retreats, and at these we started to see the value of having a single process across multiple projects: we could troubleshoot based on a potential improvement for one client, and then immediately apply it to everyone.
You can’t start automating your process until you’ve defined it, and you shouldn’t start automating your process until it’s fit for purpose. In this period our process wasn’t sufficient. There was still a lot of specific knowledge required and the process relied on having a capable human monitor production to pick up on the inevitable errors. In the lexicon of High Output Management, we’d built a breakfast factory that was burning toast – but the toast looked fine and required an expert to determine if it was burnt.
Thinking we had everything under control, early in this period we hired someone to run this process. This was our first hire in-house in over a year, and the start of moving Ellipsis from the “explore” to the “exploit” stage. The new hire understandably didn’t have the ad-hoc and extremely specific expertise the process required to keep everything working, so things quickly didn’t work out and they quickly left.
This is, of course, a massive oversimplification, but this prompted us to set out about increasing the reliability of the process. Project post mortems are invaluable for situations like this. The process should need a skilled human to run it, but the human should be able to rely on the process to produce high quality results every time. Doing this work really let us turn a corner and start increasing the quantity of clients we were taking on.
Getting better at our work led to more demand, which was great! We’re extremely human resource intensive, though, so this led to capacity issues. Capacity is a constant struggle for service businesses. This is where the final part of the puzzle comes in: becoming a technology driven service business.
Automation project
An army of robots is freely available—it’s just packed in data centers for heat and space efficiency.
Naval Ravikant
We use Basecamp for all our project management and have done so since the beginning. Basecamp is great: all our communication and docs and tasks are in one place, we can work with clients or freelancers through there, and it means we don’t need to have the constant interruptions of Slack or internal email to work.
Basecamp has some frustrating limitations: you can’t create recurring tasks, which is annoying if you have recurring tasks – such as monthly retainer-based work. You can’t create subtasks either. This meant we’d always used Zapier to create simple recurring tasks, and we used a single “master” task that got moved through the process rather than multiple subtasks. This experience plus the methodology turned out to be ripe for automation.
Basecamp’s Zapier integration is pretty limited: everything needs the right ID, and for most elements there’s no easy way of looking up the ID. If you want to do anything, then, it needs to be fixed – or so I thought. We create around 50 posts per month and I wasn’t going to create and maintain 50 individual zaps.
I thus never thought too seriously about overcoming these limitations and stuck to simple tasks and simple notifications. Crucially, though, this made everyone familiar with automation: “the Ellipsis robot” as I called it, would show up and tell people who’d filled in the contact form. It always said “Beep boop” at the start of messages, which made it fairly amusing. We were used to the robot doing things.
There’s a final piece to the puzzle. As we made our process more reliable, one final problem remained: setting up all the tasks for each month was extremely time-consuming, and occasionally we’d miss things. We also started getting ahead on work for the first time ever, and there was no good way of keeping track of specifically where we’d gotten ahead. I thus set out to get Zapier to create our tasks for us each month.
It quickly became clear, though, that it was possible to run all the extra information we’d been collecting to increase the reliability of the process through Zapier too. It turned out I could create a single zap that would create all 50 tasks each month, dynamically filling in the information on a task-by-task basis. This is when we became a technology-driven service business.
The impact was obvious and immediate: I built a “looping zap” which we use for all our process-driven tasks. The zap dynamically looks up the client and client-specific information in our master Google Sheet and then surfaces it at relevant points. The zap now handles:
- Creating the master task internally
- Identifying the right freelancer (if applicable) and creating a draft task for them (this helps freelancers see what’s coming up)
- Creating a Google Drive folder for the task and sharing with the relevant people
- Creating the Docs we need for the task, based on a template but dynamically feeding in all the client-specific info
- If we’re creating new content, a draft outline is created which includes custom client requirements
- Setting up a client-facing reporting and updating our internal reporting sheet
- Preparing analytics for monthly reporting
- Washing the dishes
It took me maybe 6 weeks to get this working. The troubleshooting of getting the Basecamp IDs dynamically took me down a rabbit hole of trying to learn Python and at one point sending a friend a screenshot of code I couldn’t get working (with no context – he did not appreciate the message). Eventually, though, it started working and it started working reliably. reliably.
This opened the floodgates: the team immediately understood the value this could bring, and opportunities for automation showed up everywhere. Our process management was the first target, but reporting was next: we improved the quality and cut the time from about two days of team time per month to… a couple of hours? Really not long at all. I spent weeks at the end of last year getting everything in place.
Now, we’re a technology-driven service business. Nothing gets missed, it’s easier for us to deliver high-quality work, and we’ve used technology to add more capacity whilst making jobs easier. It really is the promised land.
Lessons and next steps
Part 1 of my automation project is complete. We’re continuing to make minor improvements but the basics are solidly in place. It’s diminishing returns from here onwards, but I look forward to identifying those opportunities and getting the work in place.
Honestly, once you start working like this, you can’t go back. We’ve effectively added another team member to do repeatable tasks perfectly. When people talk about automation and the future of knowledge work, this is a future one can advocate for: where automation makes jobs easier and gives people more time and space to work on the creative parts of their work.
It’s also noteworthy to me just how quickly this is coming together: I am not a developer, and even a couple of years ago this wouldn’t have been possible for me to set up or maintain.
If you’re in a position to take advantage of this kind of automation, I highly recommend it.
