No matter the industry your company operates within, the universal definition that applies to all companies is that we are all software companies. The software products we buy and build on top of or develop from scratch are our only real differentiators in the crowded and competitive markets we play in. To remain relevant and in-demand, leaders within companies and industries not traditionally recognized as playing in technology or software – for example, consumer products, hardware, professional services, etc. – need to invest in a strong, expedited understanding of how to build high-quality modern software products and correspondingly how to empower engineering teams to success.
Related to this topic, one of the books I have thoroughly enjoyed and am about to finish reading is Ask Your Developer by Jeff Lawson, Founder & CEO of Twilio. Some of the ideas in this post draw from the book. For business leaders interested in understanding what the next era of excellent software products looks like and those that care about channeling software engineers and teams’ potential, Ask Your Developer is a must-read! And if you cannot get to the book, hoping this piece gets you inspired enough to act. A disclaimer: a chunk of views in this post, like other posts on Supply Chain Sunday, are mine. While influenced by Ask Your Developer, this piece on building successful supply chain software products (or any successful software product) and the world-class teams that work on them also references other books and is a melting pot of my different experiences and learnings.
Every company is a software company. Therefore, every company should have a strong in-house product, experience, and engineering team.
Even if the bulk of your company’s applications are purchased from outside vendors, building chunks of code on these inherited APIs help you differentiate and compete. Nobody knows customers’ needs and your internal operations better than employees within a company. While Lawson’s book heavily emphasizes a build or die philosophy, not all companies can afford to staff teams with enough talent to build or even assemble from scratch. Budget aside, often strong differentiation can be successfully and more easily achieved sitting and coding on top of vendors’ APIs. To get the best of both worlds, investing in in-house engineering, experience, and product teams is a must, even if they are small teams to begin. These teams design and develop the layer of differentiation and instill the culture and thinking required to better engage with software vendors and drive change within their organizations.
Software is no longer a cost center but a profit center; analog processes, hardware, and physical objects are increasingly software.
For many decades, IT and software departments in non-software companies were cost centers. Across banking, insurance, energy, automobiles, and more: software departments managed data centers and handled vendor relationships. The perception of a software team has transformed, and the software center is now a profit center and the heartbeat of operations across even traditional industries. I love the section in Ask Your Developer describing the ascent of bunq, a remarkable example of how software has transformed the P&L in legacy industries. bunq (brand is spelled in lowercase) is a digitally native bank with 200 employees. This post has a presence across 30+ countries, operating mostly through a mobile interface and a recently launched web version: no retail presence, zero, nada. A modern software product has allowed this new-age bank to operate like a lean, mean machine compared to banks with similar operations requiring tens of thousands of employees.
Shopify has similarly helped democratize access to a frontend software portal for millions of direct-to-consumer brands. These companies can now control the supply chain and e-comm experience with their customers through Shopify’s mobile and web applications and eliminate the need to maintain expensive retail outlets and associated payroll overhead. Shopify’s tech stack allowed millions of online brands to thrive in 2020, while on the opposite end, COVID-19 decimated the lifeline of brands that were dependent on physical stores.
Going back to Ask Your Developer, I cannot end this section without summarizing Tesla and Apple TV’s examples. These companies have converted hardware to software, lowered costs, and improved profits. Tesla has significantly reduced controls inside the car, moving most hardware dependent buttons on other vehicles to software functions in a Tesla – car upgrades no longer come from the factory floor, but rather from a new engineering release. Lower costs, higher profits, higher revenue.
Same with Apple TV – we were once used to a remote control with an abundance of plastic buttons. That remote is down to a few buttons, as most of those functions are now converted to software feature sets. Every upgrade happens while you sleep, no need to buy a new hardware device. Analog processes, hardware, and physical objects are converted to software, further proving that software departments are no longer cost centers.
Anything customer-facing must be differentiated and ideally built in-house. Anything non-customer facing but that still impacts financials should be bought and enhanced.
This is one point where we will have to differ slightly from the Build or Die tenet in Ask your Developer. As mentioned above, recognizing that not all companies can afford to develop products from scratch, that competencies can take time to build, and that often build internally is not the only recipe for success. Having said that, the internal teams, even if tiny, across product and engineering are critical to making that enhancement layer on top of off-the-shelf purchases. The enhancement layer is the differentiation. How to do this effectively? Perfect segue into the next point.
Build by patching together microservices, and build your version of a digital supply chain.
Like a physical supply chain is a combination of different suppliers and participants, building a quality software product today is an art and science of assembling microservices from various software vendors. A microservice is a patch of code that can work independently, connecting and operating with other such microservices. Each of these microservices typically does one thing well, and that you can connect with or into using their API. You have a cloud data center in AWS, a data warehouse in Snowflake, a cloud communications platform in Twilio, etc., and more. As you think about building or enhancing, it is much easier to do so by leveraging best in class microservices’ providers instead of reinventing the wheel. You could never replicate Twilio successfully in cloud communications, for example, without investing tens of millions of dollars, and success would still not be assured. Focus your build or enhancement on the part of the software supply chain you cannot buy off-the-shelf and the aspects of your business operations only you understand the requirements.
Product, engineering, and UI/UX teams must be joint at the hip and earlier so in the process.
In his book, Inspired: how to create tech products customers love, Marty Cagan issues a call to action for better collaboration between engineering, UI/UX, and product teams. Superior software teams recognize that UI/UX informs functionality, and functionality informs UI/UX. Product requirement documents should be co-authored by both the UI/UX and product teams. In most cases, product teams hand a product requirements document to UI/UX and engineering, resulting in mediocre products and mediocre user experience. Further, involving the lead software engineers earlier in the requirements gathering phase and making them a part of the solution is directly proportional to the probability of a higher quality product outcome. This leads us to the next point…
Give the engineer a problem to solve, not a task to complete.
Developers are often handed a task to complete, not a problem to solve. I pull from my own experience as a software engineer academically and having started my career coding. I enjoyed my day more when I would be brainstorming through the problem statement with the business analyst and product manager before I set to code because I knew what I would need to code. We do not want coders only to be brainstorming and taking them away from their Zen place of coding. But allowing participation in problem-solving and user flow discussions, allowing space to create and iterate, freedom in general, and freedom to fail are all required in a successful culture that is authentic about empowering developers.
MVP as minimum viable prototype versus minimum viable product; the best teams constantly push out MVPs at an average of 20 a week.
In his book, The Lean Startup, Eric Ries popularized the concept of the MVP or Minimum Viable Product. An MVP is an early/beta version of a product or portion of a product that could be developed fast and did enough to warrant shipping/release, and hence could gather feedback to flow into the next iteration of the product. Inspired, I love that Marty Gagan further breaks the MVP down as a Minimum Viable Prototype, an even scantier version of the original MVP that may not require development. It could just be a mockup dashboard or a super mini carveout of the planned next product release. Again, enough to test and gather feedback before the next iteration or going back to the drawing board – depending on which direction the feedback leads. The best software teams churn out an average of 15 to 20 MVPs a week, which is intuitive when one thinks about it. The more agile and nimble teams are testing, iterating, and failing, the better the success ratio.
Like salespeople, know which engineers hunt and which ones farm.
Finally, rounding off with one of my favorite sections from Ask Your Developer, Lawson says engineers can be divided into hunters and farmers, much like salespeople. Some engineers excel at bringing to life innovation and new feature sets. They love being part of solutioning through a unique problem statement. Other engineers thrive in ensuring what has been developed is consistently enhanced while continually fortifying the foundation of the early code base both by killing bugs and reducing technical debt. Understanding each of your team members and knowing which of the two camps they fall in makes for better assignments and stronger products.
