To Spur Out of the Box Thinking, Don’t Create a Box

I wrote in my initial post that one of the things about working for my Dad that drove me crazy was that he would give me a job to do but would refuse to tell me how to do the job. It drove me crazy, because at the time (which could have been at any age of 6 years old or older – once you were old enough to go to Kindergarten you were old enough to go to work) I thought there was only one best/right way to do something. If somebody had done the job before then they must know the best way it should be done. I thought: just tell me how to do it and then I’ll get it done.

That’s not how it worked with my Dad.

He was convinced of the possibility that there might always be a better way to accomplish a task than the way it had been done before, and that by only providing information on what needed to be done and not how it needed to be done that you just might be the person to find a better way to solve the problem. He also knew that unless you understood the rationale for doing something – the business requirements – that you could never apply your own creativity to the problem.  Without knowledge of the objective, you have no idea whether a different and more efficient solution will produce an acceptable outcome.

A side effect of this technique was that he didn’t have to be bothered with answering a hundred different questions about whether to do something this way or that way, and this freed up his time to do his own work. If the objective was met he didn’t care if it was done this way or that, and he knew we had our own motivation to optimize things to spend as little time working as possible (we didn’t get paid by the hour, but it was a full ride for room, board and tuition until age 18 or your high school graduation, whichever came first).

As a software developer, and later as a manager of software development, one of the things that drove me crazy was being told how to develop a product feature without being told what the feature was meant to accomplish. This is the difference between technical-level requirements (how to provide the solution), and business-level requirements (what the customer wants to accomplish).

The reason it drove me crazy is that it prevents the technical experts from finding a creative solution. It also prevents them from finding innovative solutions that anticipate what customers will want to do in the future.

I have seen many times where either the end customer or a product manager decides the solution to a real business need is something like “add this new message parameter  and set it based on the value of a new configuration option and …”.

Many engineers who receives such clear instructions will immediately set out to implement the request as efficiently as possible. If the most efficient solution is to spend 6 months of effort, complicate the product architecture and compromise reliability in complex ways – well, if it is the best solution available then this is what they will do. They have completed the task as efficiently as possible.

Alternatively, if the business objective had been clearly articulated, a variety of other solutions might have been identified by giving people the freedom to think creatively about how to solve the problem. These innovative solutions can often be orders of magnitude more efficient in the long-term than a merely adequate solution.

So if you want your R&D teams to  create innovative solutions to real business problems, engage them in the innovation process. This requires clearly articulating business requirements and understanding in detail what the end-user wants to accomplish.

When you bring technical requirements to your engineering teams you are putting them in a box. When you bring business requirements you enable out of the box thinking and create an environment where creative thinkers from across the organization can deliver real innovation.

Engineers – don’t allow yourself to be put in a box. Insist on understanding the business requirements before designing a solution.

Product Managers – resist the temptation to create a box by providing specific implementation instructions. Work collaboratively across the organization to understand and solve business requirements, and creative solutions will follow.



This entry was posted in Dirty Jobs I've Had and tagged , , . Bookmark the permalink.

1 Response to To Spur Out of the Box Thinking, Don’t Create a Box

  1. Pingback: The Art (and Power) of Asking Good Questions | A Few Things I Learned in the Butcher Shop

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s