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?

Reflections on my career in Software Engineering & Management

I was going to keep this post in my own internal reflections journal, but then decided not to, and instead, take a leap and make this public, since it may be of use to people who find themselves in a similar situation as I did, that is - the choice of branching out from software development path into the project management path.

So in sharing my experience, I hope it could help and benefit others, seeing that recently I've been approached by a few engineers about switching from a technical path into a project management path, which is the path I've been exposed to - and a path, that I myself am now, again find myself at a juncture, where I'm considering about what to do next(!).

Courtesy (link)

I am by nature, what you would call a Switcher (previous company even made a "switcher video" for people who moved around the organisation). It is probably down to my wiring, my upbringing & challenges growing up, experience of reality and my internal motivations that drives this behaviour - my own biases - that kick in and call for a change of some sort.  It is a state of restlessness that can only be resolved by a change, which I now find myself in, having given myself till March 2017 to implement my next transition.

The rest of the post is set as a series of Questions & Answer session that I had recently with myself, as part of my own introspection, as I took a long walk in the park, on a beautiful winter morning, just after sunrise, and did some soul-searching...I was the only walker, so I had a verbal conversation with myself:

Why did you choose a career in Software?
Why did you switch within software engineering roles?
Would you recommend software engineers to switch domains?
Why did you leave Software Coding and switch to Project Management & not pursue a path in Software Management?
What happens to your technical skills, are they still sharp?
Do you think it mandatory to get a PM Certification?
Do you regret the choice you made into Project Management?
Do you believe you've met your aspirations from Project Management path, looking back from where you started?
Given your PM journey, do you still consider yourself a Project Manager?
Given your experience, what next lies for you in the path of Project Management Career? Where to from here?
So what is this thing called "Project Leadership" then?
Where to from Here? After Project Leadership, what's next?

Life logging LIFE-WORK balance May update

I am continuing my experiment to find the LIFE-WORK balance that I set out earlier this year, when I created my RAGE model to track my personal & professional aspirations, goals, expectations against my current reality. We are already into June, where does the time go?! 

At the end of April, I decided re-calibrate some of the Personas, thus updating my persona rankings. Going forward from start of May, for the next three months, my focus was aimed at these, major change bumping up my coding time (which was non-existent for a many years):

Looking at the big picture summary for May, across my new top 10 personas, here's how I'm progressing:

Nothing red, but still not good enough - I should be able to do better, but where is my time being spent then??

Life-Work Balance?

So in the grand-scheme of things, if I was to take the fifty thousand foot view, and look at whether my life is balanced or not, this is what I see:

Roughly, I follow the generally accepted norm that we sleep for a third of our lives!

And the remaining time is split, almost equally between Life and Work.

And in a nutshell, it appears, at face value that my life is pretty balanced - hooray!!! Wohoo!!

But why do I feel like it's just NOT enough?!

Can I get my WORK to actually be part of my LIFE?? This is a topic for another day, however, I need to continue tracking and quantifying myself to drive the behavioural changes I need!

Lets keep going. How is my LIFE and WORK split?

Insights  - Playing with the Levers

May was not a particularly great month for me:

• My working hours as a consultant increased, which had a direct impact on my own personal pet projects like new ideas & innovations (e.g. Personametry did not get any airtime in May)
• I made a start with learning to code again, started with Javascript & AngularJS. Coding time ate my blogging time, although I did manage to write two blog posts in May, and my blog hours increased nicely.
• It is clear as day, that either my day job becomes a job where I innovate on new ideas, or I have to take time away from consulting and create the space I need to just follow my passion for new ideas. I still aspire to cutting down to a 3-day work week, but it's proving challenging.
• On the life-side, maintaining it fairly steady - although I've had trouble on the Health & Fitness stream, that has seen a decline. 
• Figure out how much sleep I could do with - can I go with less than six hours sleep? For how long?

So it's a game of levers...I don't think all the bars will end up balancing out, but I can strive to get close to levelling a few...the experiment continues!! Which lever(s) should I pull next??

Consulting, Star Trek Prime Directive & My Simple Rules

DISCLAIMER: This is another idea or concept that just might not work, or people might find it a bit edgy...but it's been on my mind of late, and so I needed an outlet, hence this post, likely to need a few iterations :-)

In Star Trek, there is this philosophy called the Prime Directive, where an advanced civilisation, when either coming into contact with, or observing from afar, a culture or civilisation that is less advanced, or, the culture is at an early stage of growth / innovation / expansion, the rule is one of non-interference. Interfering or exposing advanced technology (or a culture) to a somewhat less-advanced civilisation might end up causing more harm-than-good, so it's better to stay away (as a right of non-imposition / interference).

Can this concept be applied to consulting, or even your workspace in general?

Star Trek
As the right of each sentient species to live in accordance with its normal cultural evolution is considered sacred, no Star Fleet personnel may interfere with the normal and healthy development of alien life and culture. Such interference includes introducing superior knowledge, strength, or technology to a world whose society is incapable of handling such advantages wisely. Star Fleet personnel may not violate this Prime Directive, even to save their lives and/or their ship, unless they are acting to right an earlier violation or an accidental contamination of said culture. This directive takes precedence over any and all other considerations, and carries with it the highest moral obligation

My Own Prime Directive (Simple Rules)

I believe some parts of this philosophy can be applied to the subject of consulting, coaching or projects that touch on change & transformation, for example: agile-transformation, or even the reverse, going back from "wrong agile" to a structured, predictable waterfall, classic command-control-central-planning methods...the situation in my context: coming from a world of advanced software engineering into a world just starting out, without having an actual mandate for intervening on changing process & methods (even though you know there is a better way)...or in the project world, how to work with people still entrenched in methodology dogma, instead of seeing projects as a people leadership activity, run by conversations & commitments and less so on Gantt-chart-style, date-status-checker-are-you-done-yet project management...

Being a consultant, at least in my experience, you need to have one or more prime directives of your own, some simple rules to guide you along a path that not only protects you as a professional (as well as a person / individual), but more importantly protects the clients (civilisations) you encounter during your formal engagements, including adhoc interactions & connections.

You could say I've been a consultant for the last five years, even though from a job title front, it is going on for 150 weeks and counting, nearing the three year mark. Before returning to South Africa, I had worked for international companies that specialised in Software & Systems Design & Engineering. I had the privilege to work with a few great teams, engineers, managers and leaders where I learnt the arts and secrets to some fairly sound, tried-and-tested Software Development & Project Management methods, including large-scale agile frameworks (which I've written about previously). Leaving the UK I'd just come off one of the largest, and most intense projects in my career to date (read here) - it is the kind of project that essentially kick-starts your career into consulting, it was my Everest where I knew instinctively that that project was as good-as-it-gets, and the probability of experiencing another similar monumental project in my future was going to be pretty low...

So when I started with my next project going back five-years ago, the landscape of the company, the product roadmap & projects portfolio was almost a copy-and-paste of my last project but tuned down by a factor of say 20 notches or so. I saw that as an opportunity to leverage the wins (and learn from the pain-points) of my Everest project, looking forward to create something similar but evolved...

It turned out it wasn't going to be that straightforward in reality...this particular civilisation was only just starting out, so I had to be mindful of the state & maturity level (new team, new to agile, new everything) just as when our Star Trek Explorers come into contact with less advanced civilisations and need to reference the Prime Directive. And the role I played wasn't grand divisional manager, but a role limited to program delivery (leaving the technical & rest of development processes in the hands of the respective managers). Even though I had come from a world of great industry, here I was faced with the challenge of working in a world just starting out...the choices:

I could go in all gung-ho guns-blazing (I'm the professional, I'm experienced, I've got years of experience, what you're doing is so minor in comparison to my last project, just listen to me, I'm the Expert, You listen-and-follow-me, I'll fix your entire division up even if it's outside my world of Project Management, I'm a generalist, I've seen it all...), heavily & dogmatically prescribe a blue-print, cookie cutter process, and do what-it-takes to enforce (bulldoze-through) the adoption;

OR

I could pick and choose the core concepts to focus on (in-line with the organisation's state of development i.e. similar to how a civilisation has advanced technically/socially/culturally), that would incrementally lead to the organisation's goal (deliver product), but at the same time forge the road ahead on which their teams would grow, learn, develop & empowered to own the problem-space (allowing them to make mistakes along the way).