It takes a village to scalably build kick-ass software

I recently engaged in a robust dialogue with my favorite senior-level Quality Assurance specialist, Barbara Ziel [ ] , about an idiosyncrasy of the software development business that might just be the single most dramatic differentiator between technology enterprises that can scale — and those that cannot.

Means of Production

I’ve been in software for almost my entire career, so not sure if this issue is unique to our industry. Regardless, in this business we have a scenario wherein the key hands-on responsibilities for construction of the product fall to just a few members of a larger multidisciplinary team. In software development, it’s the developers who actually build the software. Meanwhile, those developers are [usually] surrounded by a vast assortment of supporting resources charged with adding value to the coding activities of the developer in myriad ways:

  • Designers define the look & feel and usability of the user interfaces, as well as establishing the ‘physical laws’ of the software that allow users to anticipate functionality without poring-over instruction manuals
  • Content strategists ensure that the information and experiences provided by the software is understandable, organized, and relevant to its users
  • DevOps infrastructure specialists, developers in their own right, ensure that the software remains accessible to its users, regardless of the volume of incoming requests and what might be exploding outside of the primary datacenter[s]
  • Product managers interface with the stakeholders and user community, charting a course for the software that maintains allure and relevancy in a complex and chaotic marketplace
  • Data management and analytics resources take responsibility for the streams of information flowing omnidirectionally between user and software, ensuring its security and maximizing utilization by the enterprise
  • Quality control/assurance specialists partner with developers to ensure their code is meeting the breadth and depth of codified requirements, while operating resiliently enough that it doesn’t fold under the force of chaotic inputs

It Takes a Village

While many developers might dream of a Shangri-La without project managers badgering them about deadlines, UX designers mandating user flows, aesthetic specialists running A|B testing around buttonology, product managers mandating feature prioritization, analytics specialists junking-up their code with tags and beacons, the DevOps guy forcing them to refactor for improved efficiency, and that damned QA analyst logging seven new bugs on the feature they thought had finally been put to bed — the simple fact is that all those additional hands make the product bigger and better than it could ever be as a one-man passion play. You might be able to get away with a developer-only structure during the angel-funding round of your start-up, but once your products advance into the big, bad marketplace its time to expand the tent and welcome all the supporting players that make the whole more than the sum of its parts.

Scale or Die

And here is the spot where that guillotine separates those who CAN scale from those who CANNOT. Of course, there are many pitfalls to building a world-class software development shop. But in my experience, one of the key differentiators is technology leadership that understands, appreciates, and respects the value that those supporting players bring to the picture. Demonstrating this attribute is a big-time magnanimity request, as well. Its one thing to share the driving with someone who’s hands are also on the steering wheel next to your own. But it is quite another to have sole control over the means of production, yet still exercise deference to the requests and advice of the other voices in the group.

…One of the key differentiators is technology leadership that understands, appreciates, and respects the value that those supporting players bring to the picture

How many senior technology professionals, most of whom rose through the ranks as developers, have the maturity, the self-awareness, the temerity to operate in that mode? In my experience, they are few and far between. I’ve been lucky enough to work with a few during my own career, including Ira Tau [ ], John Reynolds [ ], Clarence Kwei [ ] , Viiveek Sankar [ ], and Gene DeLibero [ ]. Lucky me. And no surprise that those are the folks who are climbing the ladder most quickly, dodging the Peter Principle in order to step-up into roles with continually greater scope.

To Grow, Share.

There is a management tenet that with every promotion great leaders recognize that they become less pivotal to the daily functioning of their organizations, not more. Perhaps the scenario I have described here is just a software-specific instance of that. If you are a development leader struggling to expand your purview and frustrated by the drag that comes with all the supporting players in your process, I would advise you to step-back and recognize that while you might have sole control over the means of software production, building great functionality actually takes a village. Instead of railing against the non-devs continually trying to exert influence over your build, try embracing them. Building awesome software is a team effort, and the development leaders who go the furthest are the ones who leverage the full potential of the entire team.

BUSINESS PROCESS & OPERATIONAL LEADERSHIP; I organize people, process, and tools to create scalable delivery to the market.