Showing posts with label Work. Show all posts
Showing posts with label Work. Show all posts

Tuesday 29 August 2023

Be the leader you wish you had

BE THE LEADER YOU WISH YOU HAD

I use this saying often in my 1:1s with my directs and in my private coaching sessions. It is a powerful way to make one pause for a moment, reflect, adjust to the discomfort, then embrace the excitement of a new energy that is created.

Adopting this mindset has transformed me from standard "manager" to empathetic "leader". Reading Seth Godin's "The Song of Significance" reinforced my instinctual leadership practices. 

Quoting from "13. Let's Get Real or Let's Not Play", Seth says this:

<quote> No one goes to the gym to willingly get punched in the face by the senior vice president of boxing. But some folks eagerly pay for a sparring partner when it's time to get better.  The difference is obvious, but we've forgotten to say it out aloud.  No grades, no check marks, no badges. I'm not in charge of you, and I'm not manipulating you. I'm simply establishing the conditions for you to get to where you said you wanted to go.  You tell me where you're going and what you need. You make promises about your commitment and skills development.  I'll show up to illuminate, question, answer, spar with, and challenge you. I'll make sure you're part of a team of people who are ready to care as much as you do. We can get real. Or let's not play. </quote>
This is not some leadership mumbo jumbo. Some time ago, I developed a model for personal development that borrowed concepts from agile product management by way of user stories (search RAGE tag on this blog). I then used the same methods in the way I work with my direct reports. HR people might call this "contracting with the employee" but I take it further. I get real. It's not about objectives, KPIs & deliver results. I put myself on the line. I reach out. And so when it comes to performance reviews, my reviews are a two-way conversation. My direct also evaluates Mo's performance - because as a leader, I believe leaders mirror & contribute to the performance of their direct reports. 

What's my mechanism then?

I ask each person to write a user story in this format:

In order for me, [Name] to do [XYZ] (e.g. my job | grow | be inspired | learn | etc.) I need my manager (Mo) to support me by doing [....insert your wish-list here] so that I can ....

So I start the year with level setting on our contracts together, and in our 1:1s, we check-in and inspect, comment, re-calibrate, adjust.  

Guess what? 

This mechanism might seem simple but it's quite challenging for people. Usually, it's the first time they're experiencing a manager doing it this way. There's hook both ways. Often, it takes a few iterations to get the user stories crafted in way that is mutually relatable and agreeable. My mechanism goes beyond the standard business SMART goal setting. I make it human. Real. Personal. For me, this is my song of significance.

Here's some real-world examples in play, from senior managers that report into me - See how doing so puts me, Mo, on the hook?

* In order for me to do my job, I need my manager (Mo) to support me by throwing me in the deep end and exposing me to as much as possible so that I can quickly learn and understand this business

* In order for me to do be inspired, I need my manager (Mo) to support me by leading by example so that I can learn from his vast experience

* In order for me to do grow, I need my manager (Mo) to support me by pushing me out my comfort zone so that I can grow in all directions.

* In order for me to do my job. I need my manager (Mo) to support me by throwing me in the deep end and exposing me to as much as possible so that I can quickly learn and understand this business

* In order for me to grow my skillset, I need my manager to support me in blocking out time on my calendar so I can complete the ‘make great hiring decisions’ course (5hrs)

* In order for me to get promoted to L7, I need my manager to support me by identifying key opportunities so that I can start building a roadmap of promotional milestones

Wednesday 31 May 2023

Why I never ran a program without a Project Charter

Lessons on large-scale delivery program management ...

I continue to dig into my past artefacts to showcase my work portfolio. I'm using a multi-pronged approach here: 1\ Showcase my work to prospective employers; 2\ Openly share my work so that others (people I coach, my colleagues and boss, etc.) can benefit; and 3\ Act as my own living knowledge repository.  

I spent a decade climbing up the project management ladder, in the same way I climbed up the software engineering ladder (from junior engineer to principal engineer) - I first started project managing small software product development (2-4 teams with 10 services), then scaled up to large middleware services (20+ teams, 50+ services) as lead delivery owner, then up to full stack systems integration (full stack of all major components: kernel, middleware, integration layers, applications), then program managed a full go-to-market product launch scaling out to including Tech, Business (Finance, Marketing, Supply Chain) & Operations (Customer Care, Retention, Content, Legal, Regulatory) - as senior program manager. I also owned the full plan of starting a business from scratch to launch (a video streaming company) in 8 months. I did a stint in management consulting, running the top 5 business projects for a $3 billion run-rate business, which some companies might call Tier 0/1 initiatives - where I co-ordinated these large-scale programs, as Chief Program Director - delivering through multiple business lines, multiple project management offices and multiple product and engineering teams. In a sense, I served as the CxO program manager, advisor and delivery owner.  

It is with this experience and knowledge, that I dare to share about my work experiences - and I'm not making these things up - you can check my LinkedIn recommendations page for proof.

During my tenure as the lead program director mentioned above, I often found myself picking up and repairing distressed programs - and along the way, I'd help improve team processes and coach the management teams as well. I also ran new business & technology initiatives from scratch, start-to-finish-then-handover. So with this diverse experience, I developed a simple method that helped me navigate both types of program scenarios: either resetting or starting from scratch, the simple, powerful mechanism of a Project Charter document. To this day, I'm surprised to see many program & project managers failing to use the Project Charter in the way it was meant to be used (clarifying the essence), and often find less-experienced, newly minted PMP/Prince2 certified professionals, doing it "by the book". My approach to project charters went much deeper than that...

So what do I mean by using the Project Charter in "clarifying the essence" then?

A seasoned, experienced project leader, chief program director, end-to-end project manager, senior technical program manager, etc - call the roles what you like - in my view, is not about just putting a plan together, working backwards from a deadline or target completion date. No, I believe as senior program leaders must apply their minds to appreciate the bigger picture and create a program structure that becomes the north star in guiding and leading multiple delivery teams. I never started a program without first establishing my project charter, which at the top level, focuses on the following:
  • Start by understanding the why. Why is this program needed? Why is it important?
  • Move on to understanding the who. Who are the sponsors, stakeholders and teams impacted? Who will be working on the program? "First who, then what"
    • A program manager must be sufficiently well-versed with all the roles expected from the program, and work hard to secure the roles needed. Yes, this means the program manager must escalate to get the people needed for the program (on the bus, as well as off the bus). A responsible program manager would raise all these risks & concerns up-front, before officially kicking off the program.
  • Clarify the what, including calling out what's missing - Set up the mental model for the program. What is this program about? What is it not about? What's in scope? What's not in scope? What workstreams make up the program? How do all pieces come together?
  • Agree, Align, Action - The 3 As of project execution involve agreement on the deliverable, alignment of all parties involved which includes acceptance of their workstreams and ultimately agreeing on the action plan to execute.
Project charters don't necessarily have to be communicated in a written document, a slide deck is more than adequate to communicate the essence. Depending on the business environment and culture (for example, some business cultures prefer slide decks over detailed documents to save reading time, whilst others like Amazon, insist on detailed text narratives). So a seasoned project leader must adapt their style to suit the particular business need & culture of the teams.

In this post, I'm sharing a version of a Project Charter as a slide deck. In a future post, I will share a detailed 50+ page document project charter that involved the launch of a consumer electronics device, the program covered a mix of engineering, business and operations workstreams.

Example Program: Transform Digital Self-Service of a $3 billion run-rate business

I was called in to help reset and kickstart an overarching cross-cutting program to improve a selection of key metrics that would result in increased usage of digital self-service channels, improving customer satisfaction and overall reducing operational costs. This program covered the full value chain delivering the service: 3rd party technology vendors developing phone "mobi" apps using USSD, iOS/Android self-service app, Website, Payments, a hardware kiosk station, set-top box interactive application, integration with internal & 3rd party CRM/Billing systems - and resulting business workflows: finance, customer care & banking channels. Technology teams were spread between the CTO/CIO lines (3 IT pillars), and business teams reported separately to the CEO. The program also served the needs of Group Strategy, Risk & Regulatory. Bringing all these things together requires a steady hand, a tactful negotiator, a strategic and business mindset as well as a strong technology leader. This is why I enjoyed such challenges as these programs were never boring, limited to only tech/engineering.

Enough said, let the slides talk and let me know what you think in the comments!

Sunday 9 April 2023

How I scaled engineering ops excellence to ±10X with Mission Control


Continuing with me sharing my experiences as CTO, in this post I share the actions I took to help improve an engineering organisation's operational health in our journey of scaling an online video streaming platform from 1X to 10X, from May 2017 to October 2020. To get to 10X improvement takes a journey, which I achieved in under 3 years, and after reaching the goal, I decided I'd learnt enough of the CTO experience and exited, after having set up a strong succession leadership pipeline in place. 

To get an idea of some of the major themes that I tackled during this time, as a leader I had to lead from the front, back, left, right setting the direction of my managers to follow (as all of these interventions were new to them), whilst doing my best to respect what came before:
  • Establishing the team despite constant re-orgs going on at parent company - getting the right people in the right roles at the right time
  • Transforming a rag-tag undisciplined team to a disciplined, clear-headed, focused organised unit 
  • Introducing laser focus on product engineering by unbundling non-core video apps to other businesses
  • Being critical on the technology platform by establishing a baseline of the architecture, using third party auditors to rate the scalability of the platform
  • Improving physical infrastructure: networking, compute, storage and data centres. Move away from self-hosted and self managed data centres to partnering, shutting down data centres as needed.
  • Build an industrial grade networking stack and leveraging modern peering facilities and overhauling the server infrastructure
  • Setting the roadmap for cloud by transitioning first from single region data centres, to multiple data centre deployments, to running multiple stacks simultaneously, introducing containers and microservices then finally getting ready for cloud and leaping first into serverless paradigms
  • Embracing cloud partnerships with big players: Akamai, Microsoft, AWS, etc.
  • Improving product and engineering delivery by revamping and overhauling the agile work processes and backlog management.
  • Introducing communications mechanisms that helped remove doubt and earned trust across the many different business units and teams (we were known as the online pirates doing their own thing)
  • Improving risk, governance and security - bringing it to the top, raising awareness
  • Creating strategic partnerships internally and externally to leverage skills and expertise I couldn't get in-house or afford to build or manage ourselves
  • Introduced technical operations controls - Mission Control, more active management of operations daily, 24/7 with increased focus, planning and prep for peak times, like weekends and major events planning.
  • Aggressively reducing costs on key platform components whilst capitalising on gains through economy of scale
In this post, I'm going to share some of the early context and interventions I introduced in my first 3 months on the job, that remain effective to this day, more than five years later: Mission Control Ops.

The dreaded 403 We're sorry, something went wrong

I took over a team that weren't prepared for the intense discipline needed to run and operate a highly available 24/7/365 platform. There were many reasons for this which I might touch on in another most. I recall coining the term "Bloody May" as the month of so many outages, that I wondered: 1\ What on earth have I taken on? 2\ Is my life going to be consumed by work from now on? 3\ Is there any hope for this platform? 4\ How am I going to turn this platform around? 5\ How much is the job worth to me?

It turned out there was going to be many more "Bloody Mays"in 2017 whilst my team set about improving stability. In 2017, the platform experienced outages that racked up about 20 days of downtime in one year. This equates to ± 95% availability, which is unacceptable for a video streaming platform. When I left the team in Oct 2020, we had turned around the platform to reaching 99.5% availability trending higher. Today, 5 years on, I'm told the availability is much higher but their usage profile has drastically changed (reduced the number of concurrent streams to one device only, also reduced their devices supported, moved most of the services to AWS). 

Sunday 19 March 2023

An example of resource planning a 100 person technology team

Here's an example of how an engineering leader can go about managing headcount and resource planning to deliver on both the technology roadmap as well as business goals. For context, this is a resource plan for a 100-person size engineering organisation who had end-to-end responsibility for building and managing a live-streaming and video-on-demand online video platform "Delta". 

I was the CTO responsible for managing everything, pretty much a CIO in my own right, overseeing: 1\ Physical Infrastructure services: Datacentres, Networking, Compute, Storage; 2\ Internet backbone transit links; 3\ Cloud integrations and peering; 4\ Telecoms integrations; 5\ Software development & testing; 6\ Video broadcast & streaming infrastructure; 7\ CDN management; 8\ Personalisation & Content Recommender systems development; 9\ Agile Program Office; 10\ Technical Operations Command Centre offering 24/7/365 first/second/3rd line support; 11\ Enterprise & Solutions Architecture; 12\ Security, Anti-piracy, Risk & Governance; 13\ Platform Intelligence Dashboards & Analytics; 14\ Vendors.

Whilst I had my own technology strategy to deliver for the underlying platform to serve the scaling needs of the business, as we were aggressively targeting a growth phase - my teams had to also continue to build out product features and enhancements for all devices we supported (sometimes the apps varying by user experience depending on the device itself, e.g. Smart TV versus iOS vs Web app), we also had to deliver new business product offerings and deliver across group-wide projects and initiatives as shared goals.

With these challenges, an engineering leader must have a firm handle on the "resource" allocation. Sorry, agile folks - I myself cringe at the mere mention of "resources" - but heck, since joining Amazon, I was amazed of how natural the term "resources" is used by management. There are two camps, people who belong to "I am NOT a resource" and "I am a resource"!!

Anyway, I digress. As a leader, you have to keep an eye on your workforce. Based on on your existing headcount allocated to you, how do you best organise your people and plan around the various delivery demands placed on your team? How do you show your stakeholders where your resources are allocated? How do you motivate for additional headcount or escalate a change of priorities if you don't have the data that accompanies your story? How do you show that although you might have 100 people under your org, the capacity for doing project work is only 80 or less, because you need to account for management, team leads, shared service work and other internal projects? See below pivot summary table:

As tedious as it might be, an engineering leader has to do some "management" work - no matter how boring it might feel. This stuff is important. The finance folks need this information. The business owners need to have a view of what impact their projects have on your teams. 

A resource allocation plan can be a powerful tool - my advice - use it often, maintain it and let it become a key mechanism for you to have productive, collaborative conversations with your stakeholders.

Yes, I maintained my own list, accounting for each person in the org. 
No, I don't always support the notion that people are fungible resources, can be chopped and changed or "allocated" using numbers on a spreadsheet. I also don't believe the fractional numbers help either, but they are meant to be rough allocations to help with accounting - which I'm afraid is unavoidable - part of any software managers job really.

Below picture shows what goes into headcount planning / forecasting for the year, trying to keep the headcount to 100 people due to the hiring freeze. Just imagine, a 100-person size team responsible for building the full infrastructure and consumer applications for a streaming video platform that served the whole African continent (50+ countries)! Amazon has the Frugality leadership principle - we were frugal on people but wise on partnerships, using another of Amazon's LP - Invent & Simplify.



As an experienced engineering leader, my advice to software managers: If you're not maintaining a resource allocation plan, you're missing a vital tool of software management. Be careful!!

Saturday 18 March 2023

Visualising a technology roadmap and year plan on just one page

Here's something that other engineering leaders might find useful: Showing all the work under one's ownership, a technology roadmap on a single page that nicely prints to A3 paper.

In this example, I capture everything that was important to me as the leader responsible for what was at the time, one of Africa's largest online video streaming platform (Live TV + VOD). I was responsible for the full platform end-to-end:
  • Physical Platform Infrastructure and Networking - Data Centres (Compute, Storage, Networking)
  • Cloud Services commercials & workloads
  • Software Engineering  - multi-platform, multi-device software development & testing
  • Enterprise & Solution Architects
  • Video Streaming Hardware & Software infrastructure integration & management
  • Recommendations & Content Discovery Engines - AI/ML scientists and engineering
  • Agile Program Management Office - Agile Specialists
  • Technical Operations & Integrations - Command Center & Mission Control 24/7/365 support
  • Security, Anti-piracy, Risk & Governance streams
How do I show on one page, the focus areas for the above teams in terms of our year plan, showcasing:
  • The themes that categorise the work so non-technical customers & stakeholders can understand
  • The cadence of releases for product feature delivery for product & marketing teams
  • The key KPIs our work drives - growth targets for monthly active users
  • The key events happening during the year that would put a strain on the platform load/stability
  • Show what the tech team will be producing month-on-month
  • The owners and points-of-contact for each work stream
So if you're a CTO or Head of Engineering responsible for an overarching technical platform, and you're not visualising your work in your own roadmap view, then IMHO, you're missing a trick. I used Excel to craft my roadmap because I was being scrappy - but it is possible to create such views if you invest in a solid product/program planning tool.

Click to enlarge: An example of a technology leader's roadmap / year plan

Thursday 16 March 2023

How I led the turnaround of a tech platform from 1X to ±9X in just 3 years

In a previous post, I shared how I ended up transitioning from a program manager to being the leader of a large engineering organisation as CTO. I then followed up another post sharing my context in this leadership position that was beset with highly volatile, uncertain, complex and unambiguous challenges - the world of online video streaming. A dynamic, tough, competitive space, especially as Africa was only then waking up to the streaming video wars that started in 2015.

[Disclaimer: I write about my past work experiences, this post dating back to 2017-2020 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 share my learnings and experiences to teach and mentor people on a similar path to me; with the side benefit of showcasing my professional work portfolio to current and future prospective employers & head hunters, through my writing].

In my 3.5 years as CTO, I would see the business change executive leadership multiple times - I think by 2020, we'd been through at least six changes in executive leadership (CEO/Exco-heads). This meant that almost every year, I had a new boss, who's strategy shifted to suit their new vision as they aimed to leave their mark on the business goals of an an aggressive growth strategy.

From a CTO perspective, I had to navigate different expectations of these new leaders, who didn't grasp the nature of technology and engineering challenges. Quite often, my team would be compared with the big players like Netflix, Amazon, Hulu - citing the incredible numbers of concurrent users (millions), comparing against our fledgling platform built in Africa, by Africans, for Africans - a platform that emerged not natively online, but an extension of the existing PayTV broadcast ecosystem. Despite whatever truths be valid or not from the engineering perspective, my job as CTO was to manage expectations upwards as best as I could whilst working with my engineering team on the necessary upgrades to scale the platform accordingly.

Once an app is live and already being used daily, with a steady increase in monthly active users - despite technical debt and platform instability - customers expect to receive feature updates and when it comes to consuming video, a stable viewing experience. Add an aggressive marketing and acquisition strategy, my technology team didn't have the luxury to pause, stop and fix things. Business goes and and IT tech folks just have to get on and deliver, smartly.

One of the first things I did with my team, in addition to resetting their mental model - was to create a simple graph of our state - not so dissimilar to Amazon's infamous flywheel. Based on the business growth strategy, the key drivers impacting my technology team pivoted around two fundamental missions: 1\ Increase the number of active users (growth) and 2\ Increase Engagement. So I created this map, as our North Star - that would remain, un-erased on the whiteboard for 3 years since creating. This picture would become my constant reference during my management meetings (reminding my directs and technical leads why we exist, what areas are important) as well as my all-hands updates:

Technology Strategy Map - North Star / Key Focus Areas

A video streaming business is about reaching as many customers as possible, providing engaging content that captivates their users to return and consume more and more content, staying longer on the app, remaining more engaged. The app user experience needs to be seamless, easy, intuitive and on-par with other well known players (ala Netflix). The tech platform then becomes core in providing the experience. What the picture highlights are the key pillars, which became the driving force for our improvement goals. I focused our attention to execute on these and only these: 1\ Product development (software delivery of app features across as many devices and platforms as possible); 2\ Streaming & Networking infrastructure - CDN & cost optimisation; 2\ Platform Scaling challenges (big area of technical debt - transition to AWS cloud); 3\ Platform Intelligence (don't fly blind); 4\ Content Discovery (AI/ML recommenders); 5\ Telco partnerships (we didn't own the full network). Controlling all of this, was technical operations excellence, something I called "Mission Control" - active, preventative and proactive monitoring of the live platform (technical alerting and social media monitoring).

A large part of this challenge was managing cost. Based on the business growth targets, the cost to serve the technology platform per customer had to remain low. In parallel with me turning around not only a distressed platform whilst keeping the integrity of the engineering teams together (because of layoffs and re-org), I had to work on delivering cost-savings whilst armed with my own sizeable budget. We could no longer be operating on a shoestring budget anymore, and at the same time, we couldn't afford to be wasteful - frugality was still top-of-mind. My budget over my tenure would amount to R1.5 billion (±100 million USD) covering people, capital expenditure, and operations expenditure (video streaming businesses is a costly game), aligned to a Buy / Partner strategy instead of Build-your-Own.

As a result of this strategy, my team were able to execute year-on-year, exceeding expectations and turning around what was once a platform on the brink of extinction, rebooting and refreshing in 2017 to deliver a nett ±9X improvement on active users and availability of the platform:

Platform growth over 3 years under my leadership


As a result of this experience, I wrote a white paper that dived quite deep into the technical challenges a CTO in the online video streaming business must not overlook - check it out here.

My engagement as a CTO was timeboxed from the start - I wasn't expecting to work longer than 3 years as I'd set myself the challenge of learning and setting up a leadership succession plan that would continue to lead the team and deliver on the technology transformation strategy I created. At the end of that experience in 2020, just around Covid times, it was clear I needed to reset myself, and after 20+ years career in video technology, I sought a change...and decided to leave the TV world behind.

Looking back, more than two years later, I somewhat miss the thrill of high-stakes leadership, and the intensity of the experience. More so, leading a large group of people (150+), rallying them to raise the bar and turnaround their tech platform (that I had no prior experience in building, nor was I familiar with the code) and also themselves, in trusting me to lead them - and get past their stigma of not trusting a business program manager... 

My next posts will dive deeper into some of the streams on how we got to 9X, covering some hits and also some big misses too!!

Wednesday 15 March 2023

How I communicated a CTO's 3 year plan through writing

In my previous post, I shared my method for applying visualisation in simplifying complex technology migration programs, communicating effectively by way of one-piece-of-paper. I also shared how I communicated progress updates for a plan with multiple programs using a simple slide show. Before getting to the stage of summarising complex topics through the powerful, simplifying visual means, one must do the deep work of critical thinking, reflection & reviews. This process usually takes the form of written word which serve as inputs into the visualisation and storytelling stage.

[Disclaimer: I write about my past work experiences, this post dating back to 2017-2020 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 share my learnings and experiences to teach and mentor people on a similar path to me; with the side benefit of showcasing my professional work portfolio to current and future prospective employers, through my writing].

How does deep work happen then? Well, through writing narratives, of course! I love writing. Even before joining Amazon, I was rather Amazonian! As I reviewed the content I produced over my past work experiences, it became clear that what I was doing way back then in 2016-2020, was actually preparing for my future work at Amazon!! Amazon is infamous for its writing culture. Powerpoints be damned! If you aren't able to articulate your thoughts and ideas through writing at Amazon, then you're not going to get much traction!

In this post, I share what I wrote back in 2018, basically reflections that I'd written for an audience consisting of ExCo (Group CTO & CIO members), my senior engineering direct reports as well as some non-technical board members who expressed some curiosity on the learnings from our journey to date, since the massive re-organisation of the business and resetting 2017 strategy (as I shared previously in my experience as CTO in  my first 100 days). 

The situation in 2018 at high level, executive board level: 
In Q1 2017, I was tasked to build the future online video platform (Delta) for the group. By the end of 2017, the group inherited another business unit, bringing its own video platform (Sierra) into the mix. The parent company created a new business unit as a result, consolidating a new operating model, bringing all entities servicing online video customer segments into a single operating business unit. With two different product portfolios, serving different market segments and powered by two different technology stacks, Sierra & Delta. Sierra was borne in the digital world from day-one cloud-native, with Delta having evolved from the traditional broadcast PaytTV world, pre-cloud. So you now have two independent CTOs (separated by continents apart) responsible for two different tech platforms, talk about ambiguity! From a high-level cost accounting perspective, it looks like there's much duplication going on surely!? Simply put: both organisations build apps that consume video, why don't you guys merge into a single platform? :-) 
I thrive in thinking big and looking around corners. I also enjoy solving what seems at first, to be intractable problems. I also love to cooperate and collaborate - always seeking out the best interest for the business in the end, even at the expense of my own career (I was never one for empire building). Setting all personal differences and healthy tech competition aside, I chose to focus on building bridges, looking for reasonable compromises. I also set out to describe the situation in terms that both technical and business stakeholders could understand. So I created this doc, to share my thinking into a 3 year technical strategy would look like, taking into account the learnings from the conversations to date. 

I'm sharing this with my readers as an example of what is expected from a senior engineering leader when it comes to strategic thinking and planning longer term - you have to do the deep work, confront the brutal facts of the current reality and set clear goals and aspirations for a future state. 

Incidentally, the contents of the doc is not so dissimilar to the content one would find in the Amazon Operating Plans (OP1/OP2):

Tuesday 14 March 2023

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?

Monday 13 March 2023

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


Saturday 11 March 2023

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.


Friday 10 March 2023

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. 

Sunday 5 March 2023

How I switched from Program Manager to CTO

During the first quarter of 2017, I was wrapping up a massive digital transformation project "VOD Wars" in its second year of running and nearing completion. A program that I led from inception in the capacity of Chief Program Director (for Multichoice Group) as some classic corporates call this role, Amazon has a similar role called the  Single Threaded Leader (STL). 

I was responsible for co-ordinating multiple programs and workstreams  that cross-cut multiple businesses. Each business had their their own heads of technology, engineering, program & project offices, operations & support functions. Each business also had their their our business goals & KPIs and in addition, had to support group-wide goals (Group-wide goals are akin to Amazon's S-Team goals). Whilst my primary stakeholders were CEOs of the various business units, I had to not only keep my eye on the high level (managing upwards and indirectly influencing across businesses that I had no positional hierarchy at all (as I was doing my own thing as an independent senior management consultant), I also had to stay close to the technical engineering, operations, support, marketing and customer experience details on the ground. The program was a great opportunity for me since I'd always wanted to experience every piece of the Video Entertainment value chain puzzle as much as possible. 

Prior to VOD Wars, I'd further strengthened my exposure to all domains of the media Video Entertainment business, by being the chief program director for launching a new video streaming business "Showmax" to Africa, in 2015. This too, was a wonderful experience, launching a business start-up from zero to launch in under ten months, co-ordinating every business (legal, finance, marketing, strategy), technology (buying a new tech stack, integrating new offshore development team, building & customising product features, integrating payment vendors, 3rd party integrators, etc.) and operations (content workflows, infrastructure & customer support). 

And before Showmax, I'd been leading major group-wide initiatives for advanced and internet-connected devices (I was lead end-to-end program manager for DStv Explora, for a small stint delved with the then nascent DStv Mobile), and before that, spent my time as technical program & product manager for advanced set top box middleware software, NDS Mediahighway/Videoguard platforms.

In fact, the last time I was engineering-focused, strictly speaking was in 2010 - when I'd taken up the role of Principal Engineer after inventing a Speaking TV/EPG - a role change, after being involved in project, program and product management before then. And the years 2011-2013, when I'd helped transform the consumer devices division of Multichoice, to use modern software engineering methods of planning, product development and end-to-end systems integration, in getting them to launch their first version of DStv Explora.

Being a rock-star program manager consultant in a niche industry in Africa, did come with its perks! I billed by the hour, and was mostly in control of my time. I had back then in 2014-2017, experimented with 4-day work-weeks, I took personal time off (PTO) for long periods of time (sometimes 2 months unpaid or more). It was around this time that I had started working on my RAGE model for personal development. As I dived deeper into my professional self-reflections, the following realisations about my aspirations started to really gnaw at me:

  • I was getting bored of being a program manager, I felt there was no challenge left and I was no learning anything new any more. I'd been reading, studying, applying and mastering the many forms of project & program management since 2008 and by 2017, I think I'd arrived and was feeling satisfied with my craft, as an expert program manager, a project leader at the top of PM hierarchy as explained here.
  • I felt I reached my goals of understanding how to run a full blown video entertainment business as I had experienced by then, every single aspect of business, technology & operations of the Pay-TV value chain.
  • I had my program management work mechanics down to an art form: I had a repeatable process, had built templates for structuring program charters, communicating progress, etc. There wasn't much more I could learn from the mechanisms needed in program management and was operating at the highest level of project leadership. A lot came naturally to me, operating on instinct most of the time.
  • I felt could run a Project Management Office (PMO) with my eyes closed. I'd started mentoring and coaching other project & program managers but I was not interested in specialising in PMOs.
  • I learnt the secrets of engaging and managing high-powered senior executives, I was confident in discussions, meetings, presentations and contractual negotiations.
  • I was not sure I could continue being a consultant without having skin-in-the-game, or having a seat-at-the-table. 
  • I had failed to land other consulting engagements outside the scope of Video / Media - so my "business" AS3 (Africa Systems & Software Services) was a one-man show, tied to one big corporate without hope of branching out of video - so why remain a consultant when I could have a seat at the table if I wanted to?
  • As a consultant, I'd developed my own prime directives of knowing when to offer advice, opinion or put a proposal together. Consultants serve a purpose, they can lead through indirect influence but also need to remain humble and fully aware, that they don't really have any clout or say in strategic decision making. Something, if I'm completely honest with myself, I wanted to influence directly, I wanted my ideas to be heard, I wanted to be directly responsible for change, and influence strategy and change the status quo, if given the chance. I could sit on the sides and offer advice and witness slower pace of change, or get in the ring, get my hands dirty and experience true ownership, accountability and responsibility. I yearned for an opportunity to experience being a senior executive, responsible for a big organisation.
  • I felt I'd drifted too far from the technology domain - and needed to get back to the core. After all, I built software myself in the early days, and have degrees in Engineering and a masters in Computer Science. I wanted to get closer to the tech teams building modern apps, internet scale. 
  • I wondered if a Program Manager could switch back to being a Technology Leader - looking at people around me in executive roles, I felt I had more than the requisite experience and technical know-how to adapt and do the job.
  • I needed to experience what it meant to be a manager with direct responsibility for people and bottom-line P&L. No more assisting from the sides.
With those reflections in mind, I explored new opportunities in the tech space, landing first an Interim CTO/GM (fractional CTO) role, still as a consultant for the first year which then later converted into a permanent role as Head of Technology/CTO for DStv Digital Media, Online Video Platforms, which then later became Multichoice Connected Video. I would spend the next 3.5 years intensely immersed in the role of CTO, learning new skills and soaking the experience all in: VUCA, big organisation of 150+ people, handling large budgets to the tune of R1.5 billion, growing people, making decisions with the seat at the table, navigating and surviving corporate politics and most importantly, getting my hands dirty with technology development again, turning around a distressed platform and reviving an engineering team...I decided to leave again as soon as I felt it was time for another change...however, I'd like to think I'd left the place looking better than I first found it. I'm going to share some of my experiences of this journey as and when I feel inspired to do so, like today. 

Getting to apply for a CTO role was nerve-wrecking at first, even though the job advertised was a General Manager - Technology & Platforms.  I felt like an imposter, full of doubt - classic imposter syndrome. I was vocally self critical so much so that I analysed and critiqued the original role guidelines advertised and provided a deep dive of my self assessment with regards to the role's expectations, benchmarking myself against what I assumed was the high bar for the role. I wanted the hiring manager to be fully aware of who I was, what my experiences were, and what my aspirations were as well before going into the interview. 

Looking back, I was only able to gain this trust based on my previous work as a program manager with a reputation for getting the job done, delivering results by earning trust, that the executives entrusted me with the role. 

One executive who is now the CEO of a large business, once stopped me in the hall-way and said "Mo, I don't know how you do it - but you have a remarkable way of making the complex look so simple!" 

Below is the original self-assessment I shared with the hiring manager for the role. I remain truly grateful to him for the opportunity and trust afforded to me. Here is the doc with my self-assessment. I'm sharing this with you because I believe it could be useful for your own professional review. When applying for a new role, even if it's outside your immediate comfort zone, it helps to take the time to analyse, commenting and rationalising how your present or past experiences can help you delivering in the new role. You don't necessarily have to lay all your cards open to the hiring manager as I did (because I'd already built up the trust relationships over previous years, so people knew me as a program manager but they weren't necessarily aware of my tech background). The prevailing advice you'd find in most career counseling is understand your current reality (be brutally honest about your current reality whilst being positive about your future aspirations) and look for ways your past skills and experiences can speak to the gaps in the role you seek. Every job spec asks for more than what's realistic, so don't give up without at first trying. Every new role comes with an opportunity to learn and acquire new skills, why else does one seek to level up, if not to learn? 

Friday 30 September 2022

My Amazon/AWS Work of Leaders Profile


The last time I had a detailed psychometric assessment done was in 2015 as I was stepping up to executive management (C-Suite) roles, the Enneagram report, seven years ago.

It's now 2022 and I'm working at Amazon Web Services in a leadership position where the focus is on scaling myself, my team and my business. As part this journey of leading to scale, I completed a new kind of psychometric based on the DiscProfile focused on the "Work of Leaders". 

This Work of Leaders psychometric is different because unlike other DiSC reports, which emphasize understanding the differences between people (like the Enneagram model), Work of Leaders focuses on understanding how your tendencies influence your effectiveness in specific leadership situations.

Here's is decent walkthrough of the assessment:


My Assessment Results
My dot style is Di
My shading style includes Pioneering, Commanding, Energizing and Affirming (which isn't characteristic of the Di style(!)\

My Reflections on my Disc Report as shared with my Manager