We techies need to take the edge off once in a while.
As I’ve sought to improve the way we communicate with nontechies, I’ve recognized that we often resort to a surefire way to confound, if not irritate, them: We talk about what I call edge cases.
I do it all the time. Say a colleague makes a suggestion. If the idea sounds good, I start mentally wandering its edges, testing its validity. When I find an edge case where the idea wouldn’t work, I blurt it out, wanting to show that I am giving the suggestion my full attention. To me, the edge case could indicate that there will be things that we’ll need to address that aren’t immediately apparent, or it could help prevent us from pursuing a path that would ultimately prove fruitless.
To my surprise, though, my colleagues get upset. That can be confusing to the techie in the conversation. Isn’t it helpful to pursue new ideas with logic and discover the areas where they might fail? We think it is. But as is so often the case, we just aren’t able to see things the way the nontechnical folks do. As far as they’re concerned, we might as well have just greeted their idea by saying, “Well, it won’t work when there’s a full moon on a Tuesday.” They can’t help but feel that we are being deliberately negative and unhelpful. We seem to be disruptive to the flow of idea generation, dismissive of the potential advantages of the idea and oblivious to the big picture. We come off as know-it-alls who can’t resist a chance to show that we know better.
Of course, you’re probably screaming that technology has to account for edge cases. It’s true. But once I started noticing a pattern in my edge-case statements, I realized that it occurs in all my conversations. I saw that what feels to me like a commitment to completeness and truth leads me to bring in edge cases at inappropriate times — for example, during brainstorming and strategic discussions. When people are in the middle of thinking up new approaches and ideas, edge cases tend to disrupt their flow of thought. And big-picture discussions are about, well, the big picture. Small exceptions are not only unimportant; they also distract from what is important.
The best times to bring up edge cases are when they add genuine value: when it’s time to vet the ideas that came out of the brainstorming session, and when we get to the detailed planning. Edge cases are an essential element in identifying the complexity, costs, obstacles and benefits of ideas. And no idea, no matter how good, has been adequately addressed if we haven’t accounted for edge cases in our plans.
Beyond that, we can take a better approach to the way we talk about edge cases. I’ve noticed that when I’m in edge-case mode, I don’t preface my observations with an acknowledgment that the idea itself has merit. That means the others have no way of knowing that I’m not rejecting their ideas outright or missing their points entirely.
We should also calibrate just how edgy our edge case is. It’s natural for co-workers to assume that attention equates to importance. If you spend 20% of a meeting talking about a use case that represents 0.05% of system usage, they’ll think you’re obsessed with unimportant things. Referencing the likelihood of an edge case happening reassures them that you get the context and importance.
Although completeness and perfection are important in code, conversations are not code. They’re part of human relationships. Learning to use this powerful analytical tool appropriately is essential to working effectively with nongeeks.
Copyright 2012 by Computerworld Inc., One Speen Street, Framingham, MA, 01701. Reprinted by permission of Computerworld. All Rights Reserved.
For more information about how you can leverage geeks to get the technology you want, contact email@example.com or call 310-694-0450.