On Project Management

In the last couple of years, I've had people approach me from different areas (technical and non-technical) to teach about project and program management. I've had some senior management ask me to guide project managers (that were close to being fired that needed an intervention to turn them around), engineers seeking guidance on how to get into project management, and heads of PMOs tell their people to shadow me to learn how "Muhammad does it", so much so, that most recently, most of my style of project documents, reports & ways-of-managing-meetings have formed the basis of "how we should do things here" templates. This year, I was asked to teach a course and was even offered a potential future coaching opportunity to help a PMO reach their desired levels of performance (which plays nicely to my aspirations of improved life-work balance and creating more time for myself, like working 3-day weeks).

This might sound like great feedback, something to be proud of, and a rather nice side effect of the work that I have come to "just do" automatically. I had no ulterior motives for recognition and reward. I never once professed to be a grand professional project manager.  Heck, I am not even certified (even though I've been on training courses and I am quite well read), I don't even promote PMP / PRINCE2 / Agile certifications & methodologies, and I've hardly used MS Project to run projects - and here are people who already have all the certifications in place (and arguably more proficient with project tools like MS Project), coming to me, asking for guidance and to be taught!! 

In truth, this recognition (and sometimes public endorsements) makes me more uncomfortable to say the least and has increased my own self-awareness, because I'm actually quite acutely aware of my own limitations. What is it that my customers see in my work?? Do they realise I'm not even currently a certified PM?? How can I help transmit what I've learnt in my experiences (acquired wisdom & intuition) in project management, that people don't already know, that they wouldn't already have picked up in PMBOK certification courses anyway? 

Recently I completed Any Hunt's "Pragmatic Thinking & Learning", where I came across the Dreyfus Model; and earlier this year, I read Donnie MacNicol's "Project Leadership" which made me realise that I may just be at the level of Expert/Mastery (Project Leader) skill level on the Dreyfus model for most (but not all) of the skills for project & program management. In a future post I will share my own PM-skills diagnostic when viewed according to the Dreyfus model. This will be a useful self-discovery exercise especially after watching a talk on Ego is the Enemy by Ryan Holiday.

So as an experiment, I decided to create a rough mind map of my own PM Knowledge-base. When I start a project, what framework do I use that helps me navigate the project minefield? So I created the picture below - a very rough dump from memory. This could potentially serve as a rough outline of a coaching course I could do for project management. If I were to write a training plan, how would I structure it? If I were running a PMO, what would I focus on? I could just about write a blog post on each of the topics (and over time, I could have training material emerge, who knows!).

My PM Mind Map

Rough Mind Map

My PM Knowledge Base

Whilst I have to date, kept away from acquiring a formal PM certification (see this post that explains my reasoning to shy away from certification), I read a number  of books and material on the subject. Below is my library that has helped me in my quest to master the subject and sharpen my toolbox. This list is in no particular order, although each one has inspired me in some way and has had a direct influence into how I apply my knowledge in applying my project management roles (I've got another five more currently reading, the list will update as I finish more in future).

On mapping your realities

Earlier this year, around March/April some time, I came across this TED talk, about drawing your life / aspirations in terms of current reality (current state) to desired new reality (future / desired state). At the time, I had just finished working on my own version of personal journey mapping, which I coined as the RAGE (Reality Aspirations Goals Expectations) model. This TED talk made me think and experiment with my own sketch, which I actually attempted, immediately after watching the video. I found the picture lying on my desk, so decided to post it on this blog, and to share with others (who may find themselves in a similar situation as I). I hope the picture says it all, suffice to say, I've been making some headway in my own personal journey tracking (which I plan to share in a future post, called On Self-Awareness). If you want to see what I've been tracking this year, check it out here.

Here's the TED Talk:

And here's my very own version 0.01, of my life picture, snapshot from March/April:

And back in Jan/Feb I had sketched my general view that led to my RAGE model, which incidentally is my implementation plan to get me from Current -> Desired State:

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?