Best Supporting Actor
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 [ https://www.linkedin.com/in/barbaraziel/ ] , 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:
- Project and program managers organize the work, both internally within the initiative, as well as across the multiple initiatives of the organization’s portfolio
- 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
[I’m sure I missed a couple here, but you get the drift. Also, the differing needs of every enterprise lead to a unique mix of resource roles]
We all collaborate our tails off in support of building kick-ass software, and take our roles very seriously. But the stark reality is that none of us are strictly necessary. Developers could build the software just fine on their own, without input from any of us. They are the ones with their hands on the steering wheel. The rest of us are just back-seat drivers.
Indeed, the dream of many developers is to just be able to WRITE THEIR #$%&@# CODE without the distractions of all these hangers-on! We’re not talking about a fringe element, either. Many of the top software development companies in the world, which at this moment in history also happen to be the largest companies in the world, started as stripped-down passion projects by developers working on their own. Larry and Sergey didn’t hold-off on launch of their Google project until some UX people could be engaged and consulted…
There is a real draw to working this way, as well. As a veteran of the dotcom mania of the late ’90s and early aughts, I had an opportunity to participate in a bunch of bare-bones start-ups. Six people, two folding tables, a dream. Some of the most fun and rewarding work I’ve ever done. Yeah — I totally get it. And there is a powerful argument to be made that this is the perfect environment in which to germinate awesome new software concepts.
The only problem is that it doesn’t scale.
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.
I’m not saying that is fun, or easy, or convenient. Because most of the time its not. Longing for sole creative control is simple human nature. What I’m saying is that if you want to follow any kind of reasonable growth curve, its necessary.
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 [ https://www.linkedin.com/in/iratau/ ], John Reynolds [ https://www.linkedin.com/in/rohnjeynolds/ ], Clarence Kwei [ https://www.linkedin.com/in/clarencek/ ] , Viiveek Sankar [ https://www.linkedin.com/in/viiveeksankar/ ], and Gene DeLibero [ https://www.linkedin.com/in/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.
What is absolutely clear to me is that if the leader of a development organization doesn’t passionately and vocally advocate for the importance of the supporting players in the product development process, her devs won’t do so, either. And the organization’s growth will be stunted for reasons that are maddeningly unclear to many outside of the technology team.
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.
Organizing people, process, and tools for scalable delivery — Partner, Digital Practice Lead; NewVantage Partners
Originally published at https://www.linkedin.com on September 10, 2018.
