The trap of technical wedge issues
From which coding language is best, to discussions about how to pronounce ‘GIF’, technical wedge issues run rampant in dev offices and tech forums alike.
Some technical wedge issues are light-hearted and can lead to a fun debate. Others, meanwhile, are often more of a trap than they are a treasure. They’re easy to fall into, but don’t provide value to your team or your product.
Here, we explore the trap of technical wedge issues. What are some of the most divisive discussions in the tech office, and how can you avoid falling foul of them?
What are technical wedge issues?
A wedge issue is a political or social issue that, due to being particularly divisive or controversial, is a popular topic for debate or discussion. They often create a clear divide within a target group.
In technology, wedge issues refer to a variety of tech topics that cause a divide within a group of people. For example, in artificial intelligence exists the wedge issue of whether AI will be our downfall or our saviour.
Technical wedge issues exist anywhere tech meets people. For instance, there’s the common debate of what programming language is best. Should you build a solution or buy it? Which is better, web or desktop development? What editor should you use? What colour should your call-to-action button be on your website? The list goes on.
In a nutshell, a technical wedge issue is a debated topic where there are two polarised sides to the argument.
The trap: why they’re a problem
Technical wedge issues are ridiculously easy to fall into. They’re a large (or at least loud) part of the tech industry. Most people will have a preference or strong feeling for one answer over another when it comes to a wedge issue relevant to their field.
The problem is, falling into these debates on the development floor is rarely helpful. Rather, technical wedge issues can quickly drive a wedge between your team. Discussions on these topics, if mishandled, can devolve into an ‘us vs them’ mentality.
Discussing technical wedge issues, then, isn’t always conducive to collaboration or innovation. Viewpoints are often based on opinion and personal experience or preferences. As a result, they rarely lead to the sharing of new ideas.
Plus, debating wedge issues is unlikely to provide a valuable outcome. Teams are divided over a subjective argument about which framework to use, for example. Meanwhile, the most productive and useful questions for your product — those involving the choices that will affect your end-users — are forgotten or ignored.
Build bridges, don’t deepen the wedge
So, how can you avoid technical wedge issues dividing your development team?
Soft skills such as open-mindedness and the ability to compromise are key. These skills promote exploration into new ideas and options that exist between the two sides. This could lead to innovative new ideas as well as a strong sense of teamwork, rather than irrationally split camps.
But that’s treating the symptoms of technical wedge issues. When it comes to avoiding them altogether, we need to change the questions we’re asking and reframe them to provide value. This value might be considering the needs of the end-user, or weighing up the future implications of a decision. (For instance, to avoid technical debt.)
So, instead of asking ‘which programming language is best’, ask ‘which language makes the most sense for this project?’ Instead of sparking a debate over whether it’s better to build or buy, consider the objective costs and gains. Then, use these considerations to decide which choice is right for your company.
By monitoring the questions that we ask, we can make sure we’re chasing answers that will provide the most valuable insight into the project.
Not always avoidable, always manageable
The nature of technical wedge issues means that they will come up from time to time. They wouldn’t be hot debates in tech if they weren’t related to commonly met questions. The key to avoiding falling foul of their traps is to remain pragmatic, objective and open-minded.
Rephrase the questions, look for middle ground, and remember to keep your end goal, user, and future product in mind.
Useful links
The build or buy debate in software engineering
