You know how when you read something, and after becoming aware of it, you see it everywhere? Yeah, this is one of those things. A few months ago my lovely coworker Sara and I were talking about processes, technology, and people and started wondering: what characteristics do high performing people have that makes them the experts others always seem to seek? Ok, so a little less humbly stated, we asked “why does everyone always ask us to do stuff?” then a follow up “so why do we just get it?”

Around the same time, I was reading the book Developer Hegemony after stumbling across it during an unrelated Google search. I highly recommend it to anyone struggling with the Dilbert Syndrome, though I found the first 3/4 of the book disheartening and demoralizing (but it gets better, I promise!).

The concept from the book that I keep getting reminded of is that developers (and I would argue IT professionals generally) are automators who turn problems into technological solutions. This is complex work, as anyone who has tried to gather requirements, breakdown tasks, and plan in a continuously changing domain can attest. Experienced IT professionals know that in order to solve a problem and produce an implementation that meets real needs they need to be involved at every step to ask the right questions. Traditional organizations don’t work that way. Instead, someone in a silo-ed unit with the best of intentions (but limited understanding of feasibility and possibility) identifies a technical solution to the real problem. This solution is handed down to the code monkeys developers, who incorrectly identify the solution as the problem to solve. Then while we try to turn the abstract solution into discrete 0’s and 1’s, cracks appear in the solution and it breaks down. Most developers want to be the hero, so we troubleshoot and eventually deliver a mangled implementation of the technical problem’s solution. All the while oblivious that there is a simpler implementation, if only the developers were aware of the real problem they were solving. Repeat ad nauseam.

Now that I’m aware of the developers are automators concept and agree that we need to see all the details of a problem in order to provide a better solution, I see examples of it everywhere. Situations which could have been better solved had I been involved in the conversation earlier. And this is where the ramble comes back to my conversation with Sara. So why do we just get it? Because we ask “why?”: Why do you need this? Why is this process so complicated? Why won’t this other technology work?

The best automators ask why.

Looking back on my career, I learned with experience that asking why (and similar deeper diagnosis questions) of surface problems reveals fundamental problems. Solve the fundamental problems and the surface problems resolve as a result, often thrilling the customer. Obvious, isn’t it? Sure, in concept, but I’ve found that it’s rare in practice. I have a customer who is technologically savvy and when we first started working together, she would bring me detailed solutions to problems she was having for me to simply implement. When I probed into a particular request for a new workflow, we discovered that what she was requesting was an easier way to manually create an email. I suggested “why not have the application generate and send the email automatically”? To which she exclaimed “it can do that? Yes, please!” Many “why”‘s later, she now brings me the problems, trusting my experience. I now also understand more about her processes and why she needs the application, to the point where I was able to identify (and solve) a need before she was even aware of it. I asked her why she used to bring such detailed solutions and she replied that the previous programmers she worked with required it — they wanted what, not why. I think this is a learned behavior of the environment — the programmers are just used to being given technical requirements from the business, rather than being involved during investigation and analysis as the experts in automation.

If I could offer a piece of advice for those best intentioned others, it would be to involve your IT people sooner rather than later, preferably at the point where you’ve identified there’s a problem that might benefit from a technological solution. When we’re solving the real problem, we’re good at finding solutions that work. And please try to be patient with all our “why”‘s:

https://www.youtube.com/watch?v=sahSAMj8OIY