How to Visualise & Communicate Technology Migration 3 Year Plan

My previous post shared my journey into my early days as a CTO, taking you through my challenges and opportunities in my new role that experienced high degrees and uncertainty, and despite the ambiguity, I had to not only come up with a 100 day plan, but also win hearts-and-minds all-round. 

[Disclaimer: I write about my past work experiences, dating back to 2017 referring to entities that no long exist today (in 2023). Previous mentions of such entities are widely in the public domain through news media outlets, press briefings, launch announcements, etc. I take time to ensure that nothing I share exposes commercially sensitive material. My intent is to rather showcase my work portfolio to current and future prospective employers, through my writing].

Despite the uncertainty with the mothership corporate's complete overhaul of its business operating models, we had to go on as business-as-usual. As such, I had to create a credible three year plan for the technology platform: Create future online video platform V2.0 that replaced the existing V1.0 (let's call this platform Delta) and combined the best of a standalone partner platform (Sierra). 

Both platforms were roughly the same age, with Delta create to pretty-much replicate the traditional PayTV's Set Top Box (STB) experience (via a Satellite broadcast) but over the internet and consumed through devices other than STBs (i.e. mobile phones, web browsers, game consoles, smart TVs). Delta wasn't a truly home-grown, native internet application, being tightly coupled to existing broadcast and satellite workflows. (To understand the world of difference between Internet Over-the-Top video and traditional Broadcast TV systems, refer to my white paper here).

Sierra, on-the-other-hand, was built from the ground-up, as a pure internet streaming platform, but only for on-demand content, like Netflix - but didn't provide live broadcast TV & thus didn't experience the realtime expectations that the Delta platform did. 

Nevertheless, the business strategy was to create a more unified, homogenous viewing experience for the customer, simplify the multiple applications problem by providing the customer (end-users that consume video over the internet), a single container application to enjoy any type of media content, on-demand - i.e. xVOD. From a product and user experience perspective, this made perfect sense. For the technology platforms though, it meant choosing a path forward that involved a technology modernisation program: Build out the new platform, migrate as much as possible, reach parity and provide the new 2.0 experience.

The job of creating this technology strategy naturally falls on the CTO, me. This initiative, to be a success would need the full co-operation of 5 separate commercial entities, impacting the day-to-day work and operations of 500+ people, including 50+ resources from our partners. 

How do I simplify a complex technology strategy & execution plan on a single piece of paper?

How do I ensure the picture shows all the key elements (workstreams) that tell a credible story?

How do I present and communicate progress overall to non-technical stakeholders?

How do I influence stakeholders & bring in a wider audience than just the engineering teams?

My One Page Project Scorecard

Back when I was an independent management consultant, I used to lead very large enterprise-wide programs that cut across multiple business units, each with its own project management office. My job was to lead, direct, coach and deliver through others, without myself having any hierarchical power - apart from referent power as my sponsors were the C-suite themselves. The job itself was interesting as I had to wear multiple hats: dive into the detail working with implementation teams whilst at the same time, be ready to communicate with my higher-level stakeholders, abstracting the detail. But if asked any questions, I must have the answers for them, without differing to the workstream owners.

Typically my programs would entail any number of workstreams, from ten to fifty. Some workstreams (or work packages) themselves would be considered programs in their own right. A program being a collection of multiple projects. Projects being a unit of work usually involving a single group, to deliver a series of tasks. I would be leading and executing through many program and project managers, as well as individual functional managers.

Over time, I'd developed my own mechanisms for structuring and managing these large-scale initiatives. One such mechanism is a simple project dashboard, on a single piece of paper, that shows the full map of all the initiatives, calls out the owners responsible and overall status - highlighting a call to action.

As a consultant however, my role was to guide, raise risks and mitigate as much as I could (within my scope of influence and control), and then escalating upwards for decisions outside my control. What's a consultant to do, eh?

Let me know what you think of this visual?

An example One Page Project Report from 2015: large-scale media workflows automation program

Pearls of Umar ibn Al-Khattab (2)

“Remind yourselves of Allah, for it is a cure. Do not remind yourselves of the people, for it is a disease.”

“A man should be like a child with his wife, but if she needs him, he should act like a man.” 

“The most beloved of people to me is he that points out my flaws to me.”

“Learn the Arabic language; it will sharpen your wisdom.”

“Sit with those who love Allah, for that enlightens the mind.

-- Umar ibn Al-Khattab

My first 100 days as CTO: Resetting the Mental Model

[Disclaimer: I write about my past work experiences, dating back to 2017 referring to entities that no long exist today (in 2023). Previous mentions of such entities are widely in the public domain through news media outlets, press briefings, launch announcements, etc. I take time to ensure that nothing I share exposes commercially sensitive material. My intent is to rather showcase my work portfolio to current and future prospective employers, through my writing].

In my previous post, I shared how I switched from being a high level Business, Technology & Operations Program Director to a General Manager of Technology & Platforms (fractional CTO) - and disclosed my feelings of imposter syndrome at the time.

Looking back, this role helped me immerse myself fully into the fast-moving-pace of "immediate get done now, everything is important" culture, ambiguous and uncertain, competitive, make-a-plan do-it-yourself courage, sheer multitude of technology options, rapid development at internet-speed -- not that I wasn't familiar with the domain before -- but this time, I was in the trenches, with full responsibility to turn the ship around and make something a success. Previously, as a management consultant, I would advise and highlight risks, I would coach and help the business put together some plans - and then coordinate the delivery. But I wasn't accountable for delivery as consultant. I wasn't responsible for people management. I wasn't responsible if the platform crashed and get paged 2am. I had no skin-in-the-game...this time, it was totally different. I had skin-in-the-game - which meant that I was leaving the world of consulting behind, back in the trenches, leading from the front as well as guiding from behind, and at times digging the trenches myself. 

What I'd accomplished in the 3.5 years was largely positive on many fronts with more upsides than downsides - but it wasn't all hits! - there were some big misses too. (A future post will share my hits and misses). But in the end, after my time-box was over, despite embattled with some scars of hard graft, I left the world of TV/Video behind, knowing that I'd met my aspirations...handing over the baton to a very capable 2IC that would end up lifting the team even further.

The Situation - VUCA !

I joined the company at a time of massive change and uncertainty. The group company embarked on a complete overhaul of its business and organisational design across the board. Typical with most corporates in Africa, the company contracted one of the big consulting houses to lead the transformation program. Their intention to create a new operating model that would better set them up for the future, i.e. "future fit the business". As a result of this new operating model, entire businesses were remodelled, some businesses reducing roles (job cuts), whilst new lines of business set up for the future (new roles to be advertised & fulfilled). Some businesses were also merged and thus resulting "duplication" were optimised for efficiency. This FutureFit program started slowly and would run for 18-24 months, with its orbit soon to approach my business unit later that year. 

So joining in May 2017, knowing there's upcoming organisational changes, already started my engagement on uncertain, unsteady ground. So as a result of this uncertainty, I decided to transition first as a contractor (Interim fractional CTO consultant) to wait-and-see what happens with the new business operating model designs; and if/when an opportunity presented itself for a permanent role, then apply. 

At the time, I joined the digital business "DStv Digital Media" (DDM) had already been through change, having merged Mobile & Online businesses into one, focused on Digital Media. The product portfolio was expansive covering 55+ countries in Africa, servicing 5 commercial entities in the areas of: web sites hosting, content management, voting applications, sports app, video streaming apps, set-top-box applications, etc. Servicing these product portfolios was a single technology team, which I was responsible for. The role in itself was ambiguous and sensitive, as I had to take over from the previous leader who decided to hang around as an individual contributor focused on innovation.

Despite the uncertainty and impending changes that could come by FutureFit program, my teams still had to get on and deliver. Our business customers were increasingly losing trust in the engineering's team ability to maintain commitments to timelines - almost every project or product release was late. Further, the end customers weren't enjoying great levels of customer experiences as the platform was unstable. Almost every weekend there were outages, that took long times to recover - sometimes customers issues and outages over weekends would only be looked at the next Monday. The state of the technical platform drove many of the business stakeholder and my product customers to insist on the engineering team improve to becoming "world class".

Their partners (other technology teams within the group) also didn't enjoy the best relationships with this new team I was joining. Lack of trust, failed commitments and constant tug-of-war on systems ownership and capabilities - a clash of the traditional structured "IT" versus the modern, fast, scrappy digital tech pirates. There was always tension, most of it being unhealthy.

The state of my engineering team in terms of morale, motivation and appreciation - was not in the best health either. As a result of the constant pressure from customers and stakeholders, late deliveries, being pulled in multiple directions, having to support multiple projects simultaneously with limited resources, not having enough budget for adequate tooling and infrastructure - being on the receiving end of loud, upset customers...I'd inherited a team in distress. Futurefit was also looming, people had seen their friends leave the company as redundancies (layoffs) were made public. It was just a "matter of time" that the restructure find its way to them. So, yeah, fair dose of volatility there. Add to that, their leader was replaced by someone renown for hardcore program delivery - what did this guy know about tech, and why should they trust him when they still had access to their previous leader?

The outgoing leader was still attending the management meetings, contributing to strategy discussions. I had to tread carefully because the work I need to do, demanded calling out all the problems & issues in a respectable manner. The respected the the principle of "respect what came before", but it was still an awkward interaction to be in, sharing my ideas for getting the engineering team in shape and on the road to being "world class" with their ex-leader in the room.

A further sensitive issue was one of my direct reports, a senior software manager openly challenged me for the position - and was extremely unhappy that I was given the role (as they were allegedly promised the role as being next in line). Not a good way to earn trust on the first week on the job! So I seriously had to earn trust upwards (customers, stakeholders), downwards (directs) and sideways (peers & partners) as well.

Added to this was a level of complexity of the system in the way that newly created DDM business co-existed with a few commercial entities as well as how the technology division (my group), interacted with the wider enterprise technology group body. Engineering platforms for multiple products to run in 55+ countries, with each country having its own unique custom features as well as priorities for differentiating markets - all supported by a small scrappy team with a shoestring budget, adds a different spin to complexity.

With all this, I was still excited to take this challenge on. The experience was going to stretch me initially, take me out of my comfort zone. I entered the role knowing the known unknowns, was fully aware of what I needed to do. 

I was in for quite the ride! My opportunity to turn the ship around...

My 100 day plan

My first 100 days had to demonstrate: 1\ A bias for action to address the burning technical issues; 2\ Earn trust of my customers, stakeholders and people by pitching a credible technology plan in place; 3\ Deliver results that showed positive progress; 4\ Influence Futurefit program with new ideas influencing positive changes whilst protecting the team to focus on delivery.

Here's my morning papers (journal entries) setting out my 100 day thoughts:

Fri 11-May: Morning Paper

This DDM role is seemingly chaotic, need to find a balance and a way of prioritising and managing my work in progress. I can't be working every day long hours, need to find the balance and time for my other interests. Officially my days start from Monday, of which I will enter a countdown from 90 days! I must set myself something to achieve in the first 90 days.

First stab: By the end of 90 days, we should have:
- settled with product management on a common backlog that drives the work
- delivered at least one release of DStv Now
- kicked off a stream and have a concrete plan of action for a Platform SDK API
- have a realistic plan for the platforms improvements
- agreed on roles and responsibilities between the various customers and my teams

Within the first 30 days, I need to:
- workshops with product & planning team
- complete handover with R (1st week of june)
- complete a 360 review based on feedback from DDM & External customers
- complete view of all the people in the division
- a full view of people by skills, competency and career aspirations
- a view of the vision and strategy for the group - Why do we exist, What are our outputs, how we go about it?
- agree reporting from all lines - Architecture / Dev / Platforms
- set clear objectives on delivery
- agree a way of working/transitioning VOD Wars program

Within the second 30 days:
- town hall with full tech team
- objectives, pds, measurements of performance clearly defined and agreed by all

Within the third 30 days:
- publish approved strategy & objectives
- must have delivered some feature increment
- reporting & dashboards in place
- improved working relationships with customers
- platform network optimisation plan executing in full swing
- vod wars program transitioned out

Tuesday, 2 May 2017

Ideas for DDM-GM role

Here's some topics to note if you take the GM role:

• Workshop retrospective - aim is to get people to understand the current reality. Timeline of company showing where they started, turning points and current period
• Map out worlds of interaction of teams - micro and macro worlds. Showing customer relationships and where DDM teams fit within this world.
• Talk through the trust curve and get people to vote into areas of the curve. Where do they think they sit? Need to draw quadrant map.
• Talk about RAGE model. Do a workshop mapping out current reality, aspirations, goals n expectations.
• For each line manager, draw a job card mapped to rage, split by work worlds (DDM, VET, customers, etc.) career and personal categories. For each apply the RAGE model
• Self Assessment. Create survey based on Agile Good Ugly book. Get leaders to rate themselves according to criteria of systems engineering practices.
• Workshop with team to define what "world class" means
• Develop vision and mission for group. Tie back to company objectives. The Why golden circle. Why, How, What. Why does DDM exists? How do we behave to reach the Why? What actions or results to we produce that speaks to the Why?
• Get to know everyone. Radical candor. Review CV, skills and experience. Growth/Performance matrix - who are the rockstars? Who are the superstars? Who likes stability? Who wants to grow fast?
• Discuss the Cynefin model.
• Teach the Dreyfus model.
• Team self-assessment down to each last person (identify gaps, growth, training, etc.)
• Career Ladder - does DDM have one?
• Build authentic relationships
• Build trust from outset
• Do not dictate - listen, embrace collaboration & welcome criticism
• Implement Personal Kanban - time management - teach it?

My first All Hands / Townhall - Reset Mental Model of 150+ People

Despite the uncertainty with the group business redesign, our business unit, DDM still had to deliver the years goals. As the financial year runs from April to March, I joined at the start of the fiscal year, a new division where I had to put together the plans for the year, strategy and guide an organisation through turbulent waters. My first All-Hands was meant to set the major scene for the transformation the teams were about to embark on, with me as their leader. On the day of the event, I was somewhat nervous but confident at the same time. Having worked through the leadership and consulted with them on my ideas, this was going to be the first time I'd be addressing the full group, engineers who I've not had any skip-levels with, not having the time to meet everyone since from Day One, I was immersed in operating, putting fires out. Looking back now, I feel I could have done a few things differently (future post).

Below is the slide deck I used for the All Hands. It was an in-person session, in the campus Auditorium that seated 200 people. I'd previously addressed larger crowds before at the same venue in my big program kick-off sessions. This was my first All-Hands to not only my engineering team but I also extended the invite to core partners (product management) and my manager as well.

My aim was to reset the team's mental model, helping them understand our purpose, where we fit into the system and how I see us transitioning, reminding them on our goals for the year - and finally busting some myths from corridor talks.

More Flux thrown into the mix for fun

Just as I was getting into a rhythm after publishing my yearly operating plan in the All-Hands, around September, 4 months into the stabilisation journey, the parent group company announced a big change to its business structure, creating a brand new business unit altogether, called "Connected Video" which found find DDM and Showmax coming together...this merger brought its own share of angst, anxiety and nervousness into the engineering teams - as now there were essentially two technology platforms providing video streaming capability to largely the same set of customers. The subsequent few months to Q4 of 2017, was me experiencing additional turbulence in the sea of change and flux of making career-changing decisions, contending with people (peers and directs) seeking to lead and emerge as the CTO for the new business. More posts on that later.

Did I deliver on my 90 day plan then?

Yes. Check it out... Whilst my engineering teams were deemed "stable" for the next two quarters at least, I was focused on working the bigger picture: Unbundling the tech stack, removing non-core services not related to video stream (website support, ISP-support, voting apps, sports apps), working with partners on new commercials, and designing for the future Connected Video technology organisational design, even though I was still a contractor and had no control, nor influence, of what the CEOs in the decision-making-seats would eventually decide.

A neat tool to bridge the gap between Product & Engineering: Combined Backlog

I came across this picture as I was browsing my consulting data archives. In one of my engagements, there was growing tension and trust issues between product and engineering teams. This is not unusual when these disciplines sit across different lines of business, or do not fall under a single leader. Often there is not enough transparency and sharing, or not enough mutual cooperation going on. 

Engineering/IT generally are not great at sharing the true nature of their technical challenges, architectural issues or simply, the state of technical debt. Even if there isn't much technical debt, engineering leaders and CTOs are responsible for owning a technology roadmap, usually the platform strategy roadmap which creates enough runway for future innovation. The situation is that the work needed to service both the Technology as well as the Product roadmaps, usually needs to be done by the same group of people - "same resources" - running into capacity conflicts, that drives escalation problems. Focus too much on technical streams, you starve the business / product / customer delivery. Focus on too much product features, you run the risk of crippling the technology stack through lack of innovation, foundational architecture thus creating too much technical debt. Healthy tension should exist - but - hope is not a good strategy. More often than not, introducing a simple mechanism of co-operative planning is a good way of building trust through disciplined execution.

As way to bridge this gap, a common solution is to meet half-way, creating a single backlog that combines both Product & Technical backlog items into a single shared Combined Master Backlog. Along with this, create simple mechanisms for managing the backlog with a regular cadence, and as a team, agree on some common terminology, e.g. understanding the status of a backlog item.