{ Another entry from LinkedIn. Post here, full article here. }
We often walk into professional situations and are surprised at how technology has been implemented. This is the norm if we’re consultants, but it happens equally often on internal teams–you are tasked with collaboration with another team or to resolve a particular long-standing challenge and, maybe 20% into learning about it, the dominant reaction is, wait, y’all did what?
These very common, head-scratching moments where we just cannot understand how someone made those particular decisions are often-missed opportunities. And are often the root cause of hundreds of hours of wasted time and money.
This is all a little abstract, and I apologize for that, but I have seen this pattern in so many different parts of the technology world–software development, process refactoring, digital data management, infrastructure configuration, on and on–that I want to talk about it from a more generic perspective.
I was once helping family members move a bed, and began arguing about some minor point of construction or location (I don’t exactly remember). But I suddenly realized that everyone else was holding up the bed, waiting for me to lift my corner. I quickly apologized and said, I’m sorry. In my rush to be right, I forgot to be useful.
And this is similar to what happens in these moments professionally.
It is especially dangerous for consultants. External consultants are incented to very quickly assess, analyze, point out the existing issues, and provide a solution. And in this demand for speed and immediate impact, again and again, the existing context is missed. This leads to the classic challenge with externally-sourced solutions: they are technically correct, but not fitted exactly to the particular contours–the context (that word again)–of the organization.
Context is a key word for my professional practice, as well as the rest of this article: I use it to refer to the larger problem space, including business drivers; multiple levels of stakeholders; and interrelationships and dependencies with other technologies, other bits of code, and other internal and external groups. So, context looks at a very broad picture.
But it’s equally dangerous internally where we often toss our scorn into the gaping maw of we’ve always done it that way, roll our eyes, and either move on or, if we’re honest, try to steamroll our newer, better, more elegant solution through the process. And steamrolling always, always carries a cost.
The crux of the issue is that, most of the time, the current context exists for a reason. Rational actors made rational decisions to create it. Yes, there are occasions where we are tasked with fixing some piece of idiocy, and while that makes us feel good, those circumstances are, in my experience, less common. The original reasons not only shed light on the existing context but, far more importantly, need to inform our new solution.
This leads to one of my professional touchstones: if I cannot articulate, as fully as possible, why something is the way it is, I am not yet in a good position to propose a solution. Or, more positively, your solution needs to address not only what needs to change, but why it needs to change, and you can only say why it needs to change if you understand why it’s the way it is.
And look, most projects eventually get there. But they get there by missing the original context, beginning to implement a solution, having some meeting with a stakeholder where, finally, the lightbulb goes on and they realize why some particular requirement was so important, re-designing their solution, and reworking some of the implementation in light of the new knowledge.
All of which could have been avoided by moving more slowly and more deeply through the context, listening more closely for why the current system exists the way it does.