In the software industry, project managers and marketers want to get things done quickly, without the complications of bureaucracy. They want the business to grow, money to pour in and more and more new things to be implemented and revolutionize their company. Some of them want to become rich and famous, well – at least in their well-delimited sphere of marketers and managing staff.
Developers on the other hand want to focus on one task at a time, write amazing code that changes the web and servers, be challenged and tackle some of the most difficult computer science issues and solve them, and especially – not get constantly interrupted and distracted by endless trivial requests. “Programming is best done “in the zone” — a (pleasant) state of mind where your focus on the task is absolute and everything seems easy. This is probably much like “the zone” for musicians and athletes.” says Morgan Johansson who calls himself a “professional software tinkerer”, senior.
A while ago on Quora someone asked programmers what they thought when hearing the phrase “I just need a tech co-founder.” A lot of rage almost instantly started pouring on from there as more and more techies joined the thread. “The[se non-tech founders] just care about equity,” commented cynically one developer. A couple of comments down, a CEO calls programmers “arrogant”, to which comes the response that non-techies should stop being so defensive, and everybody has ideas, let’s see how we put them into practice or rather, who puts them into practice for us.
Soft Skills Aren’t Lesser Skills
As newer startups have commenced building more diversified teams with an increasing overlap in capabilities, there still remains a sense of mistrust between tech and non-tech, a confusion about how to assess a person’s “soft skills,” attributes that enable them to interact effectively and harmoniously with other people, the widespread assumption that these skills are inferior to “hard skills” – specific, teachable abilities required occupationally.
If programmers are able to understand “soft skills” as competencies, they may be more likely to appreciate their value and the potential of having a non-tech person on their team. Capabilities of this sort may be the ability to make difficult connections, among ideas and concepts that are at least apparently unrelated, an understanding of one’s place in the world, the ability to critically assess how systems work (and fail), an openness to learning, a “mental playfulness” as Bill Watterson calls it that allows one to “wander into new territories” even if unsure of what they may find.
Many in the tech-world undervalue soft skills: this is most evident in the belief that artificial intelligence (extremely capable at hard skills, but not so much at soft skills) will be the solution to all mankind’s problems. Google’s Director of Engineering Damon Horowitz, who studied artificial intelligence with a specialization in natural language processing, said that it was while studying philosophy that he came to realize that no matter how much he improved upon it, the AI system itself had its limitations and the changes would not be incremental. He says his focus then shifted from assuming that machines could resolve all of our problems to looking at how they could “facilitate human problem solving” instead.
One can argue that this expansion of the mind is also connected to the ability to have a broader or “macro” view of things. For instance, Reid Hoffman, founder of LinkedIn, said that through studying philosophy at Oxford, he wanted to “strengthen public intellectual culture.” Caterina Fake, founder of Findery, knew she wanted to create something around the idea of community and the sharing of stories through art. The acknowledgement of different kinds of capabilities is a necessary first step to bridge the trust gap between tech and non-tech.
What Do you Wish Your Boss Knew?
Most likely the director of your company is a non-tech figure. The manager who’s the people’s person / with people’s skills – or so you’d hope at least – and who’s really good at marketing the product and getting it out there, in the eye of the storm. But you, the dev, have your ideas and contributions too, to the management of the business – at least internally. Some of the best contributions a developer could bring to the non-techies’ team and managers to bridge the gap would be:
Empowering the non-techies to do technical work by teaching them or encouraging them to learn tools that are easy for anyone to learn. From how to use Photoshop and Illustrator Essentials down to using tools such as FormKeep to generate forms or bringing minimal edits to the stylesheets, these situations are win-win. Win for the developer which won’t have to come back on editing and re-editing or correcting typos that can be identified and fixed in a second by the non-tech, win for the non-tech in terms of adding hard skills to his trade. It might seem such a tiny thing, a change of size of the typeface, color, or other tweaks that may seem irrelevant and yet save you from having to dig through miles of code, while someone from the non-tech team that has stumbled upon the discovery while doing the QA testing could edit it there and then.
Helping them understand that perceived output is not the same as actual output. A poor developer will write unsustainable code, and then jump around from one bug to the next, spending nights and weekends in the office and impressing their superior’s. A good developer will spend time thinking about the problem (which from an outside perspective can look like daydreaming). They’ll write clean, stable code, clock out at 5pm, and appear lazy in comparison to the first developer. Yet the latter developer is infinitely more valuable to the company than the former. Unfortunately, this can be very difficult to perceive from the outside, especially for those not already tech-oriented. Engaging in discussions with developers about these issues can help to understand what it is developers do all day, and help form a good instinct for evaluating employees.
Problem pattern matching. Getting your boss to learn coding is a big ask, and takes away from more important things they could be doing. Getting your boss to learn how to think like a coder, on the other hand, is beneficial to everyone. Thinking like a coder is more often than not a simple game of matching problems with known solutions, and knowing when to apply which solution. With enough involvement in project details, your boss will eventually come to know the most common solutions.
Assist with the interviewing. This one is really a direct corollary of the contribution right above. Your developers might just be the right figures to help you select new personnel, especially when it comes to positions that can be difficult to understand from the outside. Although developers and designers, for example, can often be at odds with each other, a good developer can identify a designer they’ll get along with, and vice versa. Involving the developers can ensure you’ll have the right questions to ask to figure whether the interviewee is a good fit or not.
Recognize merits. Recognize when non-tech makes efforts to learn about the tech world. A little bit of gratefulness goes a long way, and it’s important to positively reinforce any behavior you want more of. If your manager is learning HTML, or the marketers are learning Photoshop, that helps communication between you and balances the workload. If they have trouble, help them out in a way that lets them learn for next time – don’t just speed through the job while their eyes gloss over.
Learning to Think – An Independent Task
If you are a non-techie, odds are you might have more initiative towards taking tasks that push you out of your zone of comfort. Therefore perhaps the approach of Caterina Fake, oil painter and linguist turned techie entrepreneur, doesn’t seem so alien after all. She wanted to “translate” her training as an artist onto the web, and in the end programming languages, apart from being logical and mathematical are, precisely how their name goes, languages. More than learning to code, the long term goal for non-techies is learning how to think like a coder.
Developing a sense of logic in fact is not only mathematical – a science logics was a part of the human sciences for thousands of years, a branch of philosophy. It teaches and involves the use of precise and formal methods of thinking, such as abstractions, boolean logic, number and set theories so you can solve problems in an air-tight manner. One of the best ways to understand the human mind is to try to replicate it. Topics like AI, machine learning, natural language processing are not just part of computer science but also biology, psychology, philosophy, and mathematics. Damon Horowitz, Director of Engineering at Google, suggests that most of the evil in the world comes not from bad intentions but from “not thinking.”
What developers want most of all – to solve problems – could be the key to solving this gap. Creative problem solving is a skill considered both “hard” and “soft”. As such, it’s a key part of the lives of both tech and non-tech. Understanding that both camps are using the same skills in different ways can help the communication across the gap. The big difference is that while tech uses creative problem solving to solve technical problems, non-tech uses it to solve human problems.
That said, the best programmers are those who use creative problem solving to solve both technical and human problems at the same time. They’ve realized that the software that they’re writing is for people, even if it’s just the back end of a complicated system or a protocol that no one but other developers will ever use. They write documentation because it’s important. They help people use their code. They’re willing to go the extra mile and deal with a bit more complexity to give the people using their software the right solution. This is the point where techies’ and non-techies’ best intentions should converge, in the People First Axiom, because this is the goal that can ultimately bridge the gap.