As a “wine geek,” I am always on the hunt for an innovative wine – one that redefines my understanding of what a wine category like California Chardonnay or Italian Barolo can be. Some winemakers, such as Matthiasson and Gaja, have reputations that are built on innovation and quality. But many others travel down a different path. Some cutting-edge brands go too far and produce a wine that is more interesting than actually good. Still others play it safe and deliver an acceptable, but uncompelling wine.
I see the same dilemmas constantly being played out in the domain of software development as well. Engineering teams face this tension between innovation, quality, and dependability throughout the course of a software project. Innovate and deliver on brand execution. Or take a more expedient route to deliver a serviceable solution, but one that does not fully execute on the brand.
Delivering innovation in a services business is daunting because so many forces seem to conspire against it. Regardless of the industry, type of app/website, or parties involved, we encounter four common challenges on most any engagement.
1. Requirements with Strings Attached. The realpolitik of the services industry is that business requirements will almost inevitably trump technology considerations. Experience will teach engineers: that’s to be expected. But the snag is when these conditions push technical decisions in ways that become a stumbling block to brand execution. Sometimes the constraint is being forced to build upon legacy infrastructure that isn’t up to snuff. Other times it’s having technology choices handed down to engineering based on concerns not directly related to the project itself. Perhaps it is the comfort level of the stakeholder or maybe an entrenched partnership with an inferior service provider.
2. Fluidity. I have been around software development projects long enough to know that project requirements are probably best described by a play on a familiar line from Pirates of the Caribbean: “Requirements are more what you’d call ‘guidelines’ than actual rules.” In other words, requirements are set in stone – that is, until they change and change again. From a business perspective, this fluidity is certainly understandable. In the length of time it can take to deliver a software product, internal priorities and external environmental factors can shift radically. So too, schedules can so easily shift in an attempt to accommodate a key press event or the unexpected meeting with C-level execs.
While volatility may be business reality, the more requirements shift and change, the greater the challenge that engineers face to deliver innovation. Well-crafted architectural and implementation decisions made at the start of a project can become instantly compromised by timeline surges or last-minute feature requests, pressuring the development team to implement a rushed, tacked-on solution that becomes technical debt to deal with for years to come.
3. Pace of Others. Innovation can also be challenging as we collaborate with and are frequently reliant upon tech partners that can operate at a much more languid pace than we are accustomed to. We think in days or weeks, but it is not unusual for other organizations to think in months by comparison. The culture clash can be jarring – much like trying to pair up Usain Bolt with a group of marathoners for a relay race. In such a scenario, Bolt would have a fundamentally different way of executing on the race than would the more conservative, slower paced long-distance runners.
4. Tension Between Quality & Speed. Undoubtedly, the greatest challenge that engineering teams grapple with in delivering innovation is the inherent tension between quality of delivery and speed to market. Innovation, by definition, demands both: a quality product that is slow to market is a could-have-been while a hurried, immature product is a should-have-been. Engineers can become distracted from executing on the brand and simply deliver to the deadline. The mastery comes, not in balancing the two, but delivering on both quality and timing.
As a technology leader, I need to do everything possible to lesson and mitigate these tensions for my development team. But our ability to execute on the brand is not going to be realized by trying to change the realpolitik of the business landscape. Instead, it is done by responding to those tensions in ways that overcome them.
First and foremost, being able to successfully deliver innovation is done through the assembly of the right engineering team. Individuals need to be smart, savvy, and creative, but they also need to be highly adaptable problem-solvers – a quality that can be surprisingly rare to find among even skilled developers.
Beyond individual developer qualities, however, you also need to assemble the right composition of skills across the full team. A temptation that I see many companies falling into is lumping engineers into the same category. You would never charge a UI developer to build out your cloud infrastructure. But, in the same way, you shouldn’t assign your backend engineers to build a compelling, nuanced user experience that your brand ultimately hinges upon. That’s a different skillset, even if the engineer knows how to put things together. And yet we see that happening all of the time around us.
Being able to successfully execute on the brand is also achieved by the engineering team working closely alongside the design team. The stone-age practice of “throwing over the wall” between these two groups just will not cut it. Instead, organizations need to foster a collaborative environment for iterative development and cross-pollination. At MAARK, we have been working to fuse the groups together in new ways – with the clear objective of being better positioned to deliver a compelling user experience.
At the end of the day, engineers want to create cool things that last. We see ourselves as craftsmen and artisans skillfully creating value in the world of UX and software architecture every bit as much as our pre-digital forefathers did with their hands. However, when our deliveries are almost invariably under duress and innovation is compromised, this can inevitably have an impact on the engineering team’s moral. Some can develop an almost PTSD-like mentality, while others can become too jaded to even try to deliver innovation under such conditions. Still others flee to less demanding pastures. The ultimatum for technology leaders thus becomes cultivating a team of engineers that can rise above these tensions and, in fact, relish these challenges.
In the end, whether the stakeholders or engineers realize it or not, the “innovation vs. serviceability” dilemma is bare for all the world to see. Frankly, every visitor to your website or user of your app can see it. I can look at a host of apps on my iPhone with household names attached to them and know with certainty that, for whatever behind-the-scenes reasons, their engineers took an acceptable, but ultimately uncompelling path. Conversely, I can look at a well-designed, intuitive, fast-performing app in the App Store and tell exactly the innovative manner in which it was crafted. At the end of the day, that is successful brand execution.