My Zite reader recommended an article from Shanley called “Building techincal literacy in business teams” — and I have to say, this really hits home as a critical advantage for technology companies.

There’s a trend in the technology industry these days that “everyone should code”. It goes so far that at some startups, the business guys are given access to the codebase and told to check things in — if you care so much about a bug or feature, then go fix / build it yourself. One friend of a friend is a biz dev guy in an internet startup, but he’s learning Python desperately and actually helping engineer the web presence.

In my opinion, this is all wrong. That biz dev guy is going to be WAY slower at coding then a full-time engineer, and while he can certainly learn to code, he simply doesn’t have the experience under his belt. Why have him learn the hard way on the job, as opposed to putting him in front of clients and going after the biz dev job with 100% of his brain?

All of these skills, whether engineering or business, are learnable. Nothing should stop anyone who wants to do a task from doing it. However, I want the guy with the most passion and most experience to do a job. We don’t typically ask engineers to learn key business skills (e.g. forecasting, procurement negotiation, etc.) even though they certainly could — we want the experienced negotiator or the eagle eyed accountant to go for these tasks.

Yet specialization is only good if there is a common language between teams. And that’s where I 100% agree with Shanley’s assertion that you need to build technical literacy in business teams. It’s simply not smart to have engineering decisions get made by someone with no technical literacy; either the business person needs to learn to be technically literate, or else delegate the responsibility to someone who is.

There are 3 examples of where this can be applied:

1. A biz dev guy who is working to get partnerships that result in technical integrations needs to be aware of what/how a technical integration works — e.g. be able to address scope questions from actually knowing what needs to be built. I don’t think the biz dev guy needs to be able to actually do the work, but they should be able to competently answer simple questions (e.g. where is data going to be, what are the tradeoffs between different types of connectivity, etc.).

2. A business-background COO looking at optimizing the new product development lifecycle needs to understand at a granular level what it means to build software. In other words, it’s impossible to select agile versus waterfall unless you’ve actually seen how these processes work, or else trust someone else who has seen them both in action.

3. A business-background product manager cannot make good product requirements if they cannot envision how a system will work. Again, no need to be able to actually build the system, but awareness of certain engineering tradeoffs can have a massive impact on scope, quality, and features.

There are certainly many more stereotypical examples that everyone’s heard about (the PR person who doesn’t understand what they are pitching, the designer who creates uncodable mockups, the Marketing person who promises unbuildable features, etc.).

The technical literacy of a business person is really a way to help bridge the gap between two different disciplines. When there is a conversation between an business person and a technical person,  and the goals of the two parties aren’t necessarily aligned, then the ability for each party to lean on the other through knowledge of either business or technical concepts can be the only successful (conflict-free) pathway to actually getting something done (and resolving that misalignment).

You can get around this problem with one of those few individuals who are really good at both disciplines (e.g. the application architect who has the MBA, or the VP Marketing who had spent a year fresh out of college building websites).

What’s interesting to me is why I haven’t heard a lot about this problem in other disciplines. I know that when I did a research internship at Gilead Sciences (a pharma company), the business leaders all had originally earned PhDs in science fields…

Closing thought: how can we ensure technical literacy amongst business folks? Well, I think rotating into a project team and shadowing folks for a couple days might help? Codeacademy seems like the wrong direction (again, don’t need to actually code / waste time with the debugger — rather, learn less by doing and more by concept). Sitting in on a data design mtg, moving on to a QA test plan review, attending a PRD review — all of these things help show how the sausage gets made. The key is to make sure the business person is there to “learn” and not to “lead”.