Do you see the scenes or the spiral more?
I have spent a lot of time looking at how developers fit into the culture of the businesses that employ them. The disconnect that often exists is legendary and while there are many myths and opinions about the reasons, the disconnect continues. I often really connect with the business people I work and see their frustration, but also have experienced the frustration many developers feel. It comes down to communication but in this case, the communication needs to be between people who genuinely think differently.
Business people, particularly executives and leaders, are often conceptual thinkers in the sense that they see the goals to put in front of them, and hopefully align the right people and (sometimes) the systems needed to reach those goals without a lot of specifics as to how. Often times they believe something is possible because of a combination of their past interactions with the people and processes in place and sense that new requests of the team will be predictably similar. It is driven by their model of the system and their experience which leads them to believe it will react more or less predictably despite a definition of most of the details. Of course, these predictions are based on nothing rock solid if you look at the details and all manner of devils and dragons may still need to be found and slayed. On a bad day, somebody who lives purely in the conceptual frame of mind may resent having to muddy the concept with mind numbing details that can be contradictory and even force the concepts to change. Sound familiar?
Developers are usually very detailed oriented and are by necessity good at building precise sequences of repeatable actions with those details. People who are very detail oriented are invaluable on a team as projects work towards completion making sure every t is crossed and every i dotted. They eliminate uncertainty from outcomes to the degree possible and to the degree time allows. Without detail oriented people able to grasp and wrangle all the details to actually move work through to completion, your system may well *not work at all* or worse appear to be working, but actually be making major mistakes. A detail oriented person sweats this stuff and gets it right. On a bad day though, detail oriented people can be seen wasting tons of time chasing dead ends because they like to see things get completed or do things a certain way. They may over emphasize unimportant tasks because they don’t grasp the concepts that provide the context for prioritization and may avoid alternate or otherwise more appropriate solutions. At the worst case, they may produce a system that executes without errors but fails to solve the problem or opportunity originally envisioned. Sound familiar?
For a system to work all the way from imagination to completion, I think we can call agree that both conceptual and detail thinking is required. But if people can’t communicate well enough, what can be done? I think every participant in the process needs to possess a share of and appreciation of both conceptual and detail skills or you are in trouble. Everyone should exercise both their conceptual and detail skills. If you can’t deepen your sense of details, or step back to understand the driving concepts of your work you really risk delays or complete failure to deliver your projects.
Here is an example from my own life. I really like troubleshooting. Before I can do any sort of repair or troubleshooting, I have to have a model of how I think the thing works. Against this model, I create a hypothesis of problems that could produce the symptoms I am facing. Then I try to prove the hypothesis with various tests, observations and solutions. If the problem wasn’t solved, a couple of things need to happen.
- examine why the hypothesis was not correct
- improve my conceptual model to incorporate what I’d learned
- create more than one additional hypothesis of the next possible solutions
- pick the most likely hypothesis to try based on my improved conceptual model
- repeat until goal met, problem solved or solution determined
As a troubleshooter, you are often wrong. The way you thought things worked is often confounded by many variables, conflicting bits of evidence and sometimes incomplete vision of the inner workings of the system. Details! Yet, you have to get the thing working. A naive troubleshooter uses only trial and error to go through a list of mostly predetermined courses of action until hopefully the problem goes away. Case in point, “having a problem with your computer, rebuild it”. Results are limited.
It is the deep conceptual model that enables you to think of more possibilities and more accurately dispense with irrelevant details. It is attention to details that allows you to try a hypothesis and really understand what worked and what didn’t and from this improve the conceptual model in your head. These go hand in hand with neither working well without the other. Nearly all projects have the quality of a largely unknown solution to a project request at the beginning, and ever increasing understanding as the project progresses. It really takes your whole brain!
Where are you strong, being able to grasp lots of details, or in being able to think about a system in abstract conceptual terms? There is no right answer, but there is an outcome for you. Work on the one you are weaker in.