Here’s an interesting distinction on work you don’t know how to do.
Thomas R. separates work he wants to understand before having his team do it, from work he doesn’t want to know anything about and doesn’t want his team to do.
Here are his two descriptions of these two different types of work and how he accomplishes them with his OFS.
I have found that I must test a new set of instructions to ensure it gets the result before I can pass it on to others.
A lot of the time I think the instructions should give the result but they do not – a step is out of place or missing etc.
It takes a fair amount of work, but once the system is done, it is an asset for the business and I am not dependent on particular people that “know” how to do the work. Its all documented.
In regards to work I don’t want to know how to do and don’t want my team to do – I think I still need to be clear on what the purpose of the work is and some kind of vision for what the final product is like. A description of the problem the work is meant to address would probably be helpful.
For example, my optin rate is currently sucking on my funnel – I could give this as the problem, the purpose of the work is to create a working optin page with at least a 20% conversion from ad traffic and for it to look professional and like modern business webdesigns.
With that data, I could then seek who could do this work and they would have a reasonable chance of completing the work.
Thomas is doing both insourcing (the first type of task he describes) and outsourcing (the second type).
I’ve also found that testing out instructions myself is really valuable.
After my OFS worked for me for a few years I stopped testing things myself. I let them do the testing. They trust me enough to come to me with problems.