What Business Leaders Can Learn From Developers
Over the course of my career, I’ve found that many people don’t really know what we developers do; mainstream movies paint us as Mt. Dew guzzling teenagers furiously keying millions of lines of code in an effort to hack the Gibson, reroute traffic lights, or break into a government database. Sad to say, the reality is much less glamorous. Really what we do at NUVI, a B2B SaaS company, is to try and make sure customers (users) stay happy while simultaneously pushing the business forward as technology improves. How we accomplish those two feats seems complex but is actually simple. We employ some basic practices that while rooted in software engineering, can actually help business leaders in any organization make sure they are meeting their goals and driving their company in the right direction.
The Unix philosophy is a set of principles or guidelines meant to help programmers be more efficient. Developed in the late 70’s, the Unix philosophy stipulated that a program should do one job really well. As new features were needed, new programs should tackle those additional tasks, instead of attempting to add that functionality to an existing program.
What does “priority” actually mean?
This philosophy aligns with Greg Mckeown’s popular book Essentialism. Basically, Mckeown argues that over time the original meaning of the word “priority” has been corrupted and is no longer accurate. For example, today we talk about having multiple priorities; in fact, it seems like everything is a priority. But taken literally, there can be only one true priority, and everything else is secondary to that one goal.
As I mentioned earlier, there are essentially two goals that act as umbrellas for everything else we do as developers. The first is to keep customers happy. We call that the customer feedback loop, and it never ends. As customers identify bugs or request additional features, we have designated teams that respond to and work on those issues. Through iteration, we are constantly refining the platform in response to customer demand. On the other hand, we understand that in our business, social media listening and analytics, we cannot simply worry about today’s issues. Technology moves too fast and if we aren’t innovating, we fall behind our competitors and quickly lose relevance. While it is important to satisfy the customer’s immediate needs, it is also important to create things they don’t yet know they need.
Every day is a balancing act between these two competing objectives, and yet per Mckeown’s Essentialism, they cannot be equally important. One has to be a priority, while the other is secondary.
Sometimes letting go is tough to do
When I first accepted the offer to step into a leadership position as CTO, I initially struggled to split my time between these two activities. As a result, innovation and implementation of new tech slowed down. I was so busy trying to fix every customer issue, that I didn’t have the time to research innovation. I also wasn’t in the state of mind to process where the business should go in the future or how we were going to remain a leader in our space.
From this, I learned that in order to really steer the company in the right direction, I could no longer split my time evenly between the two roles. I had to hire managers and create teams I could trust to operate with minimal interaction from me. I had to delegate the resolution of customer issues to these teams, knowing that if these issues were not resolved in a timely manner, it could have serious detrimental consequences for our company.
As that team grew and was able to function without me, I was able to turn my attention to the innovation side. I now spend more time researching and thinking about the future than actual coding. My job is to work within the constraints of existing resources to inform future-impacting decisions.
I’ve worked with many leaders through the years who refuse to delegate. Their insistence on keeping control over the everyday minutiae means they aren’t doing the job they were hired to do, and aren’t fulfilling their role. But I’ve learned that it is crucial to do one thing well. This doesn’t mean that I don’t handle other assignments or work on other projects; it simply means that I do my one thing well and I ask my team to do their one thing well.