Planning or strategy?

After the developer had told me about his unfortunate experiences with collaborative associations, I asked him if these had changed his attitude towards creating e-business solutions. "Definitely," he replied. "For me it is now Planning, Planning and Planning". This response intrigued me because I would have thought that his experiences with the defections would have convinced him that you couldn't rely on planning.

I knew he was responsible for some very large projects with major companies, so I asked him how many people he employed. "None", he replied. "There is only myself and a partner. We have found it to be too inefficient to employ people on a permanent basis, so, we outsource everything to subcontractors and freelancers". He then went on to explain that besides the massive overheads involved in maintaining a permanent technical staff, employees working at the cutting edge of technology are prone to leave at the most critical times and if they didn't leave they were subject to burn out.

I asked him what he meant by burn out and he told me that the most talented employees seemed mainly to work in bursts of energy and enthusiasm. They'd be brilliant for a few weeks, working all hours of the day and night , but, would then suddenly seem to lose their enthusiasm and find it difficult to concentrate. He added that besides exhaustion, this was often because they hated anything repetitious, so their interests quickly moved off into other areas.

"So if you subcontract all the work, you can't actually supervise what they are doing?", I asked him. "Good heavens, no", he replied. "I specify what they have to do and give them a strict deadline for completion. If they don't perform well, they are out and I get somebody else to do the job".

It was then I realised that we were thinking along similar lines, except he was describing it as planning and I was describing it as strategy. Our differences were only semantic. He was in fact breaking up his "plan" into steps and reassessing the situation at the end of each step.

I asked him how many projects he had going on at that present time. "Nine", he told me. "Just my partner and myself handle nine separate assignments and they are all perfectly controlled and we always come in on budget. It may not seem efficient to work this way because we often make mistakes, but, it is far better than working with a large managed staff. It's not that this is a good way to work, its just that any other way is vastly inferior."

It is interesting to note that this developer was working in the role of an auteur as opposed to an entrepreneur. He was not responsible for the overall strategy of the core businesses, only in the implementation of the interfaces to the connected world of the Internet. In this way he was using his knowledge, experience and contacts to find solutions for companies who wanted to explore the potential of the Internet to enhance their businesses.

The developer in question had built up a relationship with his customers over a number of years. He was in a position of trust whereby they could rely on him to create a suitable strategy to handle their e-business solutions efficiently.

It struck me that even though he might work efficiently, by his own admission he made mistakes. I wondered if his clients relied only on him, or, whether they used a more complex strategy and were using several different people, each providing separate solutions that could be measured against each another. That would seem to be the most appropriate way to work, but, it seemed that all of his clients had chosen him as the single solution provider - and hoped that he'd get it right.