To manage software teams, take a page out of the baker of breads

Software management metaphor - Another one of those "This might not work" posts...

Last night I woke up from a deep sleep, to the sounds of the howling wind outside, the tatter-tatter of light scattered rain hitting the window, whooshing branches of the garden palm tree against the roof & telephone cable, at about one in the morning, and the sounds of an indecisive impending thunderstorm about to break - when a thought came to me: that managing software teams is just like being a baker who bakes bread! 

And if you're going to coach software teams, you won't do a great job unless you've been through a few projects yourself, in say maybe three different products...just like a baker should never profess to be a a true baker of breads if he/she only knows of just one type of bread :-)

So let's build on this metaphor

There are no doubt a wide variety of breads, over two hundred according to wikipedia. Each bread appears to have its its own unique characteristics, not just from outward appearances, but also sometimes, unique ingredients as well. 

Though most breads may share a common pool of ingredients, they will vary in terms of process & methods.  Some doughs (infrastructure code perhaps or engineering methods?) must be repeatedly pounded,  some need to reach a different points of elasticity, some need varying amounts of time to soak, just in preparation time, and some might be best served a day later. 

Some breads need a tender touch, care and extra attention, whilst some breads are rough, solid and can take on a few dents and bruises here and there. Either way, the baker understands that balance and care are needed to get the best bake out of the ingredients, methods and process - just enough and not forgetting, the baker's intuition, experiential wisdom all play a huge part into what makes a baker of breads, a great baker of breads...

The baker of breads is no doubt expert, finely attuned to the methods and processes that must be applied to each bread to get the desired result: beautifully baked, well worth the time, effort, energy and most of the time, patience.

Any shortcuts taken, or hastily applying a different method based on some other bread type could result in failure, or perhaps a mutation of sorts. The end result is likely not a very good bread, far from edible.

In pretty much the same way, a software manager (coach, consultant, etc.) needs to approach each software team with care, take time to understand its own unique character, culture and drive for success, applying possibly unique methods to "bake" the teams to reach their desired goals and outcomes. And this outcome in my view, is one of delivering value, keeping customers happy.

So to end the metaphor, a software manager must become a master chef, a baker of breads. Understand each bread is unique, invest in appreciating this uniqueness which may need you to change your own behaviours and biases. 

And revel in the the taste of variety...

Then I went back to sleep...

The PayTV Platform VS Product Debate

This post has been on my TODO list for four years. It started as trying to clarify the role of the STB: Is it a Platform, or is it a Product?? I now feel this debate needs to be extended beyond the STB domain, and instead focus on the bigger picture - the end-to-end video technology stack. And in order to do this, one has to start right at the beginning - understanding the future design of a PayTV business...This blog post is a work in progress, my thoughts are not fully structured and far from complete...I needed to get this thing off my Trello TODO list because it was starting to burn a hole in my screen, so here goes...

The topic of what drives innovation in software companies in terms of understanding the differences between a Product versus a Platform is not a new one. It has been discussed since the early 90s in lead up to the evolution of PC Operating Systems & Applications, early 2000s on the dawn of the Internet age, mid-2000s on the rise of mobile platforms and the resurgence of Apple. Citing a few articles that discusses this topic of Platform/Products, by Michael Cusumano, a leading expert on the subject:

• The Evolution of Platform Thinking
• The Platform Leader's Dilemma
• Platforms and Services: Understanding the Resurgence of Apple

However, in the context of Digital TV, Pay TV or what the market is now calling "Video Entertainment", I feel not much has been written about this subject. This is probably because of the largely historical nature of these technology & architecture platforms being proprietary, in what has been quite a much-guarded and competitive landscape by technology vendors traditionally in the Set Top Box middleware space.

I believe the very same challenges that existed twenty years ago in the PC-world are really no different to the challenges Pay TV software systems face today. Whilst Pay TV exists to generate as much revenue from its subscribers as much as possible (one really can't argue with that bottom-line), one cannot ignore the fact that there is an enormous amount of software systems that power the business (consumer devices, broadcast systems, security & encryption software, billing & subscriber management systems, and more recently internet-backend services that deliver digital services on additional devices other than just set top boxes) so much so, that one could even argue that Pay TV is fundamentally, a software technology-driven business - and since this is pretty much the reality of today, then the topic of Product v Platforms in PayTV is all the more relevant!

Historically, the medium of consumption of PayTV, was through a device called a Set Top Box (STB). A piece of hardware that allowed a customer access to the content broadcast. The STB offered rudimentary user interface (an application / electronic program guide) that primarily allowed users to find content to watch - and this basic use case can still be considered the primary use case for PayTV, despite the bells and whistles that come with flashy graphics. The interface exists to allow users to find and watch content, period.

I believe the STB, in terms of software architecture, has to evolve from the once historic notion of being viewed as a standalone product, to instead becoming part a platform ecosystem, just like any other modern operating system (iOS, Android, etc.) that exposes a set of capabilities that allows for re-use of software components across devices. That, with the increasing convergence of mobile/internet/broadcast, the STB can no longer be considered its own island, with its own unique software stack (some might argue that these stacks are archaic), somewhat silo'ed & isolated from more modern technologies as in the case of platform software driving pretty much the mobile (smartphone / tablet) devices.

I have worked in the STB world for pretty much most of my career. I've always felt that we were really reinventing software systems, architectures and design patterns that was pretty much known since the sixties (really). In the last eight years, we started moving to the converged world, merging broadcast-and-internet TV, and in doing so, the constraints of the STB world start to reveal itself, especially when it came to inter-networking features, light-weight components and services-based design patterns and the challenge of essentially re-using software components across different devices. I've seen companies and teams struggle to adapt to this new challenge, especially when it came to the topic of truly understanding what it means for differentiating a Product or a Platform?

Is the Set Top Box a Product, or is it a Platform??

An example STB Platform

I believe the days of the STB as a unique device for viewing content, the primary means of interaction, and the constraint of being stuck in the world of broadcast TV - are over.

Customers don't care what a PayTV operator labels & markets its device as. The STB is simply, a means to an end - a thing that lets you connect your TV to access a world of content provided by a PayTV operator through a transport medium (satellite, terrestrial, broadband, whatever). And that in the connected world of the internet, customers expect to access the same experience on any mobile device (because it is possible and it's expected).

So initially, in isolation, just looking at the STB alone - I view the STB as providing platform software, just like iOS or Android.
From a hardware perspective, the STB device hardware too, is also a platform that allows the PayTV operator to incrementally add features over time. The hardware usually shares future-looking capabilities that STB software can realise over a period of time (usually 5-7 years, but this time is being reduced to more like 3-5 years shelf life).

This may sound like commonsense, because it is what consumers are used to with more modern  iOS & Android platforms, right? Yes, but in the world of PayTV, I've seen how technology implementations can go wrong, costing PayTV operators lots of time, money and energy, lost opportunities, lose market share, etc - due to not taking time to properly assess the nature of their products and services as well as the underlying technology ecosystem needed not only to satisfy their current business needs, but also the systems to power & drive future growth (at little cost, avoiding long development cycles, re-work and silo'ed ring-fenced deployments making maintenance a nightmare).

I also believe that we need to go further than just thinking in the STB-world - we need to think about a platform world, a world of re-use. The same applications and user experience must exist on all devices, regardless of technology domain. If the customer is expecting this unified seamless experience, in the same way the software components need to be shared across the architecture domains. I don't expect there to be separate application development teams per device. What usually happens is a PayTV operator has separate vendors, with their own stacks, a development team for STB, another development team for iOS, another team for Android, another team for PC/Web - all implementing pretty much the same thing. And similarly, separate infrastructure services teams (broadcast headend, internet online backed teams) usually fragmented, working in silos, often with duplication of services.

So the question for me has evolved: it is no longer about the STB being a product or a platform. It is about the End-To-End PayTV Technology Platform - how should a Video Technology Ecosystem be structured today?? Out with the old, in with the new is what I say ;-)

Why understand the difference between a Platform & Product?