I recently learned that a former client of mine had passed away, and it brought back memories of the work we did together. One project in particular has stayed with me because, although I didn’t realise it at the time, it taught me something about what it actually means to build a good system for someone.
He wasn’t particularly technical. CRM, funnels, email sequences, workflows and automation weren’t things he naturally gravitated towards. I, on the other hand, could already see in my head how all the pieces of his sales process could fit together.
So when I started thinking about his sales process, I could already see the system I wanted to build. I had the funnel mapped out in my head, along with the automations, integrations and workflows that could connect everything. I knew what should happen when someone submitted a form, how leads could move through the pipeline, what information we could capture automatically, and how the different pieces could talk to each other.
It was a good system. At least, I thought it was.
Then I tried to explain it to him.
I could see quite quickly that I was losing him. It wasn’t because he wasn’t intelligent, and I think that distinction matters. This simply wasn’t his world. He didn’t want to understand the inner workings of a CRM any more than I particularly want to understand the inner workings of every piece of technology I use in my own life. He wanted something he could open, understand and use without having to remember what some automation I built six months ago was supposed to be doing.
That presented me with an interesting little problem, because technically, I could build what I had originally imagined. In fact, part of me wanted to. I like figuring these things out. There is something satisfying about making several systems work together and watching a process happen automatically from beginning to end.
But I wasn’t building it for me.
So I started removing things.
I kept the automations that could disappear quietly into the background. If someone submits a form, for example, there is no reason for my client to manually create a new contact record. The system can do that for him. There are several things like this that technology can handle without requiring him to think about them at all.
Other parts of the process, though, we deliberately kept manual. I created the pipeline, showed him where to go, where to add his notes, what to click and what to update. Nothing particularly impressive. No elaborate sequence of triggers firing behind the scenes. Just a process he could look at and immediately understand.
He loved it.
I’ve thought about that experience a few times since, mostly because it challenged one of my own assumptions about what it means to be good at this kind of work.
When you develop a technical skill, it is very easy to start looking at problems through the lens of what you know how to build. You see an inefficient process and immediately think of automation. You discover that two platforms can be integrated and start thinking about connecting them. The more you learn, the more possibilities you can see.
There is nothing wrong with that. It’s part of what expertise gives you.
But I’m beginning to think another part of expertise is knowing which of those possibilities to ignore.
The most sophisticated solution is not necessarily the right solution. A beautifully automated system isn’t particularly useful if the person who owns it is afraid to touch it. And if a client has to contact me every time something behaves unexpectedly because they have no idea what is happening behind the scenes, I’m not sure I’ve made their business simpler. I may have simply moved the complexity somewhere they can’t see it.
There is a temptation, especially when you work independently, to demonstrate your value through how much you can do. Perhaps there is also a quieter kind of confidence in knowing what you could do and deciding that the client doesn’t need it.
That has changed the question I ask myself when I’m building something.
Instead of asking, “What can I automate?”, I’m trying to ask, “What should I automate for this particular person?”
Those are not quite the same question.
I still like clever systems. I still get an unreasonable amount of satisfaction from making two pieces of software talk to each other and having something happen automatically. I don’t think that’s going away.
But the system isn’t mine when I’m finished with it.
Someone else has to live with it.
And sometimes the better piece of work is not the one that shows everything you know how to build. It’s the one the client can confidently use after you’ve gone.
Leave a comment