Software development is, primarily and in most cases, a business function.

You are either developing applications that will directly serve as a revenue-generating product (web applications, mobile apps, e-commerce, etc.), a lead-generating marketing product (landing pages, advertising platforms, etc.) or a logistic supporting product (something that makes the running of a business or the operating of another function easier) and sometimes, you’re doing all of the above at the same time.

Software developers often approach software-solved problems as puzzles, problem-solving exercises and essentially fun exercises. Their explanations to business stakeholders often approach the problem from this perspective, instead of from the business perspective: “I decided to use FancyDingo framework instead of ObviousElephant because the abstraction is simpler in this or that manner” versus “we faced some difficulty in reaching our milestone due to some significant code refactoring that we found necessary to make the code more sustainable long-term.”

This discrepancy often leads to frustration and miscommunication between development teams, who are “in the trenches” of the problem and are lazer-focused on implementation, and business teams who are looking at business metrics and deliverables more than implementation.

Developer team leads are meant to bridge this gap with an understanding of both the business world and the world of the implementation. They can lead dual-hatted lives in this respect, wrangling disparate herds of cats all aiming for different but not necessarily unaligned outcomes.