“I’m not technical” is a self-fulfilling prophecy

Published

April 16, 2020

Arien ‐ Head of Software Engineering NL

There is a costly gap between the world of business and the world of technology. Kent Beck said that one of the goals of the agile manifesto was to “heal the divide between development and business.” Although this article has this touchpoint with agile methods, it's not about that. This article is about when people involved in software development say the words: "I'm not technical." This is a natural reaction to jargon being thrown around. And it is exactly because it is a natural reaction that the divide exists to begin with.

Saying that you're not technical makes it more likely that you will be treated that way. It's an invitation for others to dumb things down. There are two common results. Colleagues will try to simplify what they need to say, which is difficult to do. As a result, important and relevant details will be lost in translation. Another common reaction is to involve the self-proclaimed non-technical person in fewer conversations. This has a hidden cost. Developers may see it as wilfully disengaging in dialog. A software team may start to believe that the person making decisions about priorities and budget is not interested in the details that matter. You can imagine the consequences. Even if you've never said these words aloud, you may still be labelling yourself.

Believing that you're not technical makes it more likely you will behave that way. If you're convinced that you will not be able to understand something, how likely is it that you will genuinely attempt to? "Whether you think you can, or you think you can't - you're right." The truth is that many convictions are not based on fact, and may be harmful. At this point you might be thinking: "Surely you're not suggesting that everyone should know everything? For complex problems, specialised roles are necessary!" And I would agree.

worth internet systems multidisciplinary teams

Get closer

To close the business and technology gap we must accept some overlap. Humans don't exist in these two distinct categories of technical and non-technical. It's not real. On average, two different software engineers, used to different tools and problems, will still share a great deal of vocabulary and concepts. For other roles, however, this overlap is much smaller. And it starts to look like a gap.

This problem requires personal effort to solve. People that are good at bridging this gap are extremely valuable. A strong tech lead, technical co-founder, CTO, or business analyst is likely a key factor in the success of a software project. Think of someone in your company that adds a lot of value to the business. I bet this person has a talent for bridging the gap between several disciplines. As great as it is having these people, putting a dedicated person in between business and development only pushes those two worlds further apart. If someone is good at this job, the need for other people to do it decreases. And so the business and development gap remains.

Saying "I'm not technical" is usually an unprompted and premature disclaimer. At the heart of it lies insecurity and/or disinterest. Losing interest and focus in meetings when things "get technical" is understandable. Especially if the desire to understand simply isn't there. But it reinforces the divide. So then, what's the solution? As I said, it takes deliberate action and navigating into new territory.

What you can do

Instead of accepting or resenting the divide, ask: "Do I need to understand that? Because it's not clear to me now." Confront others with their use of jargon and the fact that verbal communication is generally unreliable. Sometimes people want to impress others with their knowledge, and other times it's the result of the curse of knowledge. Either way, people overestimate how well they communicate. Everyone should realise that not understanding something precisely the way it was intended, is the norm. I recommend everyone involved in software projects invest some time researching Domain-Driven Design. Make it a point that you, and your colleagues, work towards a shared language where business and technology meet.

Get in touch

We'd love to
hear from you

This field is required
This field is requiredThe email address is invalid.
You must consent to the Privacy Policy

Thank you

We will get back to you as soon as we can.