I have never been just a Software Developer. In every job that I have had since I was young and started my own web development business, I have been put in the sales role performing functions from marketing and business development, to sales negotiation and fulfilling contracts. In every sense of the word I have been an entrepreneur. Working as a Software Developer, I never just wanted to write code. I wanted to build effective tools that made business more efficient and to do so I had to understand the business. Perhaps my experiences gave me a bit of an advantage, but it is an advantage that can be learned.
Not too long ago, an old co-worker of mine and I were having a discussion in which he described 3 types of technologists. The first type – your Level 1 technologists are effectively your soldiers. These are the developers that you can give a set of tasks to and they will march forward and write some of the most brilliant code you have ever seen to do exactly what you have asked them to do in the most efficient manner possible. Level 3 technologists are what you call your visionaries. These are the most brilliant minds in academia or a particular domain who are consistently ahead of the game. They are thinking about technologies 5 to 10 years out and are the ones who drive innovation. Level 2 technologists lie firmly in between and spend a lot of time understanding the business use case and attempting to apply the ideas of the visionaries to today’s businesses cases.
I lie firmly at Level 2 at this stage in my career, and I can confidently say that because of this I write better software than most others at the same stage in their careers. Writing software should not just be about writing code in the fewest number of lines possible. It should not just be about finding the best algorithms for specific problems. All of those things are components of writing software that solves real world problems. We absolutely need those people at the Level 1 stage who can effectively execute when given a task, but in order for those individuals to truly be effective Software Developers they need to be able to understand the business case.
I’ve worked on many projects and one common problem that I have seen is there is always a non-technical requirements team that understands the business case who hands technical requirements to a development team. The end result is usually a software product that the end users did not want. Sound familiar? The motivation behind this is usually because there is a stigma that developers do not know how to communicate with end-users. The fact of the matter is – all of the successful projects I have ever worked on were successful because I went out and spoke to the end users to truly understand their business case.
These projects were successful because when I approached the end-users, I took off my developer hat. I put on the hat of the end-user and fully immersed myself in what they were doing to truly understand the problems they were experiencing. This gave me not only insight into what they thought the problems were and how they could be solved, but also what other problems existed and how those could be solved. As technologists, it is our job to apply technologies to domains to make the life of the end users better – not to show off how you can write a data mining application in python in less that 10 lines. After the immersion session, I took what I learned and put my developer hat back on. What you eventually learn is that most users in across domains have very similar problems, and later you can spend less time trying to understand the problems because you already know them.
It is time to stop building development teams full of only Level 1s who never become domain experts. They have a lot offer to the visionaries who may not be aware of the technical capabilities that exist right there within their own teams. Additionally, when you have the opportunity to become a domain expert by being surrounded by Level 2s and 3s, you start to write better software. I intentionally surround myself with Level 3s in hopes that one day I will become the visionary type that everyone looks to. In order to build better software, we need to be sure that all levels are tightly integrated and understand the business domains in which they work. Otherwise, the software is being written for the sake of writing software.