Stop Using "Technical" to Divide Your Teams: A Manager's Guide to Breaking Down Artificial Barriers
Every time someone says "that's a technical decision" or asks if you're on the "technical side" or "business side," they're perpetuating one of the most harmful myths in modern workplaces. The word "technical" has become semantically meaningless—a linguistic sleight of hand that artificially divides teams and creates unnecessary hierarchies where none should exist.
Let's start with the obvious: every job in a modern organization is technical. The marketing manager who builds multi-channel attribution models in Google Analytics and configures complex audience segments in Facebook Ads Manager is doing technical work. The finance director who creates pivot tables, writes SQL queries, and builds Monte Carlo simulations for risk modeling is doing technical work. The project manager who orchestrates dependencies across seventeen different systems while managing stakeholder communications through Slack integrations and Jira automations is absolutely doing technical work.
Yet somehow we've collectively decided that only people who write code in certain languages get to claim the "technical" label. This arbitrary distinction serves no purpose except to create an artificial caste system where developers get to dismiss other perspectives as "non-technical" and everyone else gets relegated to supporting roles in their own expertise areas.
The absurdity becomes clear when you consider what actually makes something "technical." Is it complexity? Marketing automation platforms are staggeringly complex systems requiring deep understanding of APIs, data flows, and behavioral psychology. Is it specialized knowledge? Financial modeling requires mathematical sophistication that would make many programmers' heads spin. Is it the ability to troubleshoot systems? Ask any sales operations manager about debugging CRM workflows across multiple integrated platforms.
The real tell is how selectively we apply the "technical" label. When a developer writes a Python script to parse log files, it's "technical work." When a data analyst writes R code to perform statistical analysis, suddenly they're "business-facing" or on the "analytics side." When a designer codes custom CSS animations, they're still somehow not "technical." The determining factor isn't the complexity of the work or the tools being used—it's proximity to traditional software engineering. This linguistic gatekeeping has real consequences. It creates artificial barriers to communication where developers assume they need to "translate" concepts for their "non-technical" colleagues, often condescending to people who understand the domain better than they do. It reinforces hiring biases where technical expertise in one area (programming) is valued over technical expertise in another (operations, design, analysis). Most damaging, it prevents organizations from recognizing that their best solutions come from combining technical knowledge across disciplines, not segregating it into silos.
The solution is to abandon the term entirely when talking about roles and focus on what actually matters: domain expertise, problem-solving ability, and collaborative skill. The person who understands customer behavior through years of data analysis brings specific domain knowledge to product decisions. The designer who knows how users interact with interfaces brings specific domain knowledge to user experience. The operations manager who optimizes supply chains brings specific domain knowledge to business strategy.
Every modern role requires mastering complex tools, understanding intricate systems, and applying specialized knowledge to solve problems. The word "technical" doesn't distinguish between these competencies—it just creates arbitrary hierarchies that make collaboration harder.
We'll build better products and stronger teams when we stop using meaningless labels to divide ourselves and start recognizing that expertise comes in many forms, all of which are necessary to solve complex problems.
Here's the reality check your leadership team needs: every role in your organization is technical now. That marketing manager optimizing conversion funnels through complex attribution models in HubSpot¹ isn't doing "soft" work—they're manipulating sophisticated complex systems. Your finance director building Monte Carlo risk simulations in Python² isn't just "crunching numbers"—they're doing computational work that would challenge many software engineers. The UX designer at Figma³ creating interactive prototypes with conditional logic and component variants is absolutely doing work that requires specific expertise.
Yet somehow we've collectively decided that only people writing backend code in certain languages get to claim the "technical" label. This arbitrary distinction serves exactly one purpose: creating artificial hierarchies that make collaboration harder and decision-making worse.
As managers, we see this play out in daily team dynamics. Developers dismiss product insights from growth marketers who've spent months analyzing user behavior data through complex analytics platforms. Engineering leaders exclude customer success managers from architecture discussions, even though they understand user pain points that directly impact system requirements. We separate "technical" and "business" stakeholders in planning sessions, then wonder why our solutions miss the mark.
Consider what actually makes something "technical". Is it complexity? Marketing automation platforms like Marketo⁴ require understanding APIs, data flows, lead scoring algorithms, and behavioral triggers—concepts that would overwhelm many programmers. Is it specialized knowledge? Financial modeling requires mathematical sophistication that makes most coding challenges look straightforward. Is it systems thinking? Ask any DevOps engineer at Netflix⁵ about the expertise required to manage global content delivery networks while maintaining 99.9% uptime.
The absurdity becomes obvious when you examine how selectively we apply the label. When a software engineer writes a Python script to analyze server logs, it's "technical work." When a data scientist at Spotify⁶ writes R code for music recommendation algorithms, they're somehow "business-facing." When a designer at Apple⁷ creates custom animations with precise timing functions, they're still considered "non-technical." The determining factor isn't complexity or expertise—it's proximity to traditional software development.
Breaking Down the Barriers
This linguistic gatekeeping creates measurable problems for your teams. It reinforces communication silos where engineers assume they need to "translate" concepts for colleagues who often understand the business domain better. It skews hiring toward valuing programming skills over equally technical expertise in operations, design, or analysis. Most damaging, it prevents organizations from recognizing that breakthrough solutions come from combining technical knowledge across disciplines.
Smart managers are already abandoning these artificial distinctions. At companies like Stripe⁸, product managers are expected to understand API design principles because payment processing is inherently technical work. At Datadog⁹, customer success teams dive deep into infrastructure monitoring because helping clients requires genuine technical expertise. These organizations succeed because they recognize technical competence comes in many forms. But it's important to remember that no one person can know everything; it's not bad for some of the product managers to have a heavier concentration on systemic management and some to have API domain knowledge, just like it's fine if CS teams have members whose skills fall into the People Domain rather than into infra expertise. Teams are strongest when they are diverse and when that diversity encourages collaboration.
Instead of dividing your teams with meaningless labels, focus on what actually drives results: domain expertise, problem-solving ability, and collaborative skill. The growth marketer who understands user acquisition through cohort analysis brings their knowledge to product strategy. The operations manager optimizing supply chain algorithms brings their knowledge to business planning. The designer who understands human-computer interaction principles brings their knowledge to user experience decisions.
Every modern role requires mastering complex tools, understanding intricate systems, and applying specialized knowledge to solve problems. The word "technical" doesn't distinguish between these competencies—it just creates barriers that make your job as a leader harder.
Your teams will build better products and work more effectively when you stop using arbitrary labels to divide them. Start recognizing that domain expertise exists across your entire organization, and your decision-making will improve immediately. The marketing manager analyzing conversion data, the finance director modeling business scenarios, the customer success team troubleshooting integration issues—they're all doing "technical" work that directly impacts your company's success.
The question isn't whether someone is "technical enough" to contribute to important decisions. The question is whether you're "technical" enough as a leader to recognize expertise wherever it exists in your organization.
¹ Senior Marketing Manager, HubSpot
² Director of Financial Planning, Stripe
³ Senior Product Designer, Figma
⁴ Marketing Operations Manager, Adobe (Marketo)
⁵ Site Reliability Engineer, Netflix
⁶ Principal Data Scientist, Spotify
⁷ Human Interface Designer, Apple
⁸ Product Manager, Stripe
⁹ Customer Success Manager, Datadog
