Playing around with ChatGPT, my CTO shadow

So, wow - I had put off deeply exploring ChatGPT for sometime until this weekend - after watching the Microsoft Co-pilot launch announcement and later catching up on the conversation with Bill Gates... I wanted to learn more.

In short, like the millions of other people that tested before me, making me quite the laggard... ChatGPT blew my mind!!

I'm still processing - need to consider the implications of this technology. 

Look at my conversation below - it's amazing. I wish I had access to my shadow CTO when I was building the online video streaming platform, so much time could've been saved!! The interaction was conversational, context was maintained even when the chat spanned two days overnight. The thread of the discussion was maintained, ideas could be built on top of previous answers. Take what Microsoft's just launched, and you have a serious disruptor of the workplace happening soon...I posit that life in the workplace would be very different by 2025!!

The future of work is going to change. I can't wait to stop doing drudgery work, what my manager recently called out as "donkey work".  I'd like my virtual personal assistant to reply to emails on my behalf, to provide status updates on projects automatically. Want to check the status of a project? Sure, don't ask me, ask co-pilot! Want to see what the latest performance metrics report is doing? Sure, co-pilot! You want an update on the outage we had last night, sure - co-pilot will summarise the five whys and play out the incident timeline, graph the blast radius and call out the customer impact for you boss, you don't need me to repeat the same (I'm busy fixing issues). You want to check if a project is going off-track, sure, ask co-pilot again. The project manager role is going to change. The software manager role is going to change. I would go as far as saying HR and coaching might fade away...if this ChatGPT technology can comb the entire corpus of psychology, psychiatry and medical knowledge, we can have really good conversations around mental health and well-being, or ask for guidance on handling sensitive relationships at work...we are limited by our imagination, and if that happens, guess what - we can seek inspiration from the AI anyway! 

Wow, it's time to wake up and embrace the power of this tech,

My new best friend, my shadow partner, my confidante ... I can't wait to see how personal assistants leverage this technology, especially when we get close to real-time data & knowledge-streams. 

Anyway, I'm sharing my first deep conversation with ChatGPT below. I started off by wandering about my own options with getting back into deep tech, then veered off into exploring the online video streaming business since I was quite the expert in that field before joining AWS. I wanted to check what responses she (I already given it a gender!) would provide regarding the problems I had to solve as CTO. Just as timely because this month I've been writing much about that.

Providing clarity of job expectations and career pathing for engineers

I cut my teeth during my first decade of my working life experiencing the software engineering job family, starting as a junior engineer in 2000 and working my way up to principal engineer by 2010 (and then spent eight years from PE to CTO, then switching down to engineering manager in 2021). In between senior engineer and making principal engineer, I switched from coding to software engineering management and project delivery. Just before going back to technical, as a principal engineer, I was performing at the level of a senior technical program manager and software delivery owner for a very large software stack. 

I was fortunate to have worked for pure software product companies in that time, focused on consumer applications as well as infrastructure systems. The companies were led by people with an engineering background, CEOs/VPs/Directors with PhDs in the sciences, who had practiced as engineers before getting into leadership positions. As such, the culture of those companies were very engineering focused - leaders took the time needed to develop clear guidelines for career planning and development. The job family framework NDS created was super helpful in level setting expectations with engineers and managers alike. People had a map to reference, removing the ambiguity and suspicion that often comes with promotions. A clear job family framework, in my opinion, is a must-have for any engineering organisation because it provides people with direction to chart their career path. It is an extremely powerful mechanism especially when the company is diverse and allows a spread of career options. Having this map allowed me to experiment with different roles myself, switching between business units and trying roles out, until I figured I'd explored enough or reached my aspirations.

I'm talking about years 2003 to 2011, working with what was at the time, the world's leader in TV software and encryption systems, with offices world-wide (NDS/Cisco/Synamedia). I left that company with solid engineering management experiences and upon returning to South Africa, was well positioned to help raise the bar of engineering excellence. Surprisingly, more than ten years later, working in Amazon AWS, I marvel at NDS's high bar in the early 2000s - pretty much working now for Amazon AWS, I'm  pretty much picking up from where I left behind in NDS from an engineering excellence perspective, I'm glad I schooled with NDS.

When I led one of the largest consumer device initiatives in the history of that company, in 2011-2013 - I was quite surprised that the engineering organisation was missing a vital mechanism for its engineering workforce: The Engineering Job Family guidelines Career Ladder. As a program manager without much direct hierarchical influence, all I could do at the time was provide feedback to engineering leaders about the quality of their engineers and managers, as not meeting the high bar expected from the industry. I influenced quite a bit of change indirectly, helping overhaul the entire technology division's structure and engineering practices that was needed to get the program delivered. However, I couldn't do much about the HR guidelines when it came to job specifications. Instead, I wrote a blog post about my experiences and shared this with the HR/Tech executives in 2013.

Here's some proof of the indirect / referent influence I had as a program manager overhauling the engineering org, that if we didn't do would've cause the project to fail:

When I branched out on my own doing management consulting, I was invited by the business HR & Tech executives to talk more about the technical career ladder framework, which I picked up from NDS days. 

[P.S. I'm sharing material I created as a management consultant. If you'd like a copy of the frameworks, please reach out to me via my contact page.

Disclaimer: I write about my past work experiences to showcase to prospective employers, future clients if I decide to consult again. I'm publishing my work portfolio so that recruiters / headhunters or hiring managers have easy access to my work products, saving you time. If you like what you see, let's talk!]

I created this slide deck to talk about the concepts:

Sense making, apples v oranges, finding a path forward from multiple options by asking searching questions

I've been writing about my experiences as technology executive when I was placed in the midst of uncertainty and high ambiguity that impacted both my personal and professional aspirations in a big way. Making the decision to leave my experiment into boutique management consulting behind, after building a solid reputation as a high-level program manager, switching to a deeply technology role into a business unit that was going through disruption due to both external and internal forces -- was not an easy, straightforward transition to make. I experienced classic imposter syndrome (see this post). Nevertheless, looking back now, more than five years on, those experiences helped shape me to becoming more well-rounded, what some would call a diverse Business, Technology and Operations (BTO) executive - or - as Amazon calls it, a Strong General Athlete (SGA).

My writing this month is on communication methods, mechanisms and tools: 

• How should CTOs (engineering leaders / technology executives) communicate to all groups of stakeholders?
• What tools of writing and visualisations to use?
• How to use critical thinking and the art of reflection to deep dive on the technology strategy - calling out the good, the bad and the ugly?
• How to dive deep to sense make by asking searching questions, that force upwards stakeholder management to engage in guiding the teams on strategy?
• How to find a common ground and build bridges between two (perceived) competing technology organisations?

Questions & Answers Tree - Seeking Clarity from Executives

Let's recap the situation:

In 2017, I took on the role of CTO for an online video streaming technology platform. The business unit was part of a traditional satellite PayTV company, that created an online companion application to supplement its existing TV subscribers to watch TV on the go, initially through web & mobile applications ("Delta" platform) - by investing in digital media division. Not long after this value added service was created, about two years later, the parent investment company, started up a new video streaming business ("Sierra" platform borne in the cloud, no attachments to traditional PayTV like Netflix), completely independent from the existing PayTV business. The two businesses hardly interacted or shared common product, marketing or technology elements for the first two years. When I joined in 2017, there was talk about potential synergies and closer partnerships - which directed my three year turnaround strategy - to modernise Delta closing the gap on Sierra, thus creating comparable modern video consumer experience (Netflix was the bar). A year later, additional complexity and uncertainty came in when the parent investment company, decided to unbundle its independent video businesses to allow itself to focus solely on e-commerce ventures. What happened? Naturally, Sierra business was folded into Delta - create a new business with two product & engineering organisations running in parallel: 2 CPOs, 2 CTOs - tasked to figure out what the future world could look like in creating a Delta 2.0 strategy.

As part of the interactions, still being the management consultant (at the time, I was regarded as independent without any affiliations to taking any sides - since I worked with all businesses before and had existing relationships with all), I helped the executives tackle their options.

The first one - let's understand the assumptions and questions that challenge assumptions. Can executives be clear about their end game? What is the vision? Why are you so caught up about the apparent duplication in tech platforms?

Here's the tree:

Comparing Apples to Oranges: The decision table view

When two engineering teams are challenged about their platforms doing essentially the same thing, especially when the ask comes from non-technical executives, very often engineering leaders become defensive and say "Ah, you can't compare apples with oranges, you must compare apples with apples". Whilst this might be technically accurate, this is not the way to manage communications with stakeholders. Part of technology leader's job is to simplify technical and product capabilities, meeting your customer and stakeholder needs, where they're at. Even if you feel a visual oversimplifies, you still need to tell a story, like the one I used to gain approval that cemented Delta 2.0 roadmap:

Who knew that four years later, I would be digging out the same mechanisms to help AWS executives, (in my first month barely completed onboarding by the way) to decide on a technology stack that my engineering team would need to build/deploy/operate - for providing calls / chats support as their technical call centre platform, servicing one of their highly-regulated, strictly controlled, private cloud partitions? See below decision table, similar oranges to apples story:

How to sell a technology strategy to senior executives

I've started writing about my time as a CTO when I was responsible for turning around and transforming an online video platform to scale 10X as the business doubled down on its growth strategy by investing more heavily into marketing, acquisition and retention drives. As a result, the impact on the engineering team was very high, much higher than when the team built the first version of its platform "Delta 1.0" - and now, under new leadership, I was tasked to take this platform that was lacking in several areas and transform the stack to a future 2.0 vision. It all became more complicated and ambiguous a year later, when another business was merged and we ended up with having two video platforms, offering different product experiences, for different segments of customers.

Despite the technology ambiguity and business uncertainty, the ask from the top was for the Delta product & engineering teams to come up with a plan for a unified stack, showcasing the 2.0 experience. 

I previously shared the technical narratives to help communicate my technology plan. Alas, the docs were too lengthy and detailed for high-level business executives. I needed a way to sell my vision and at the same time secure funding to be allowed to multiple tracks of work running.

How do I show to non-technical business executives, the current state and our future desired state?

What words do I use to show we need to leap from A to B?

How do I convey a story that creates excitement?

How do I gain credibility that my planning is sound?

How do I show complex technology stack layers incl. infra to reset mental model of a "simple app"?

If you've been reading my other posts, you'll learn that I like visualisations, a lot. I also like story-telling - and even way back then, in 2017 - I was familiar with Amazon's future press release concept - and decided to use the future press release headline summaries as a way for me to communicate the release plan. Who knew, that five years later, I myself would end up working for Amazon!?

Here's the anonymised deck that shares concepts you could use, if you find yourself owning a technology platform modernisation challenge, moving your platform from V1.0 to a Nextgen 2.0 state, and sell the strategy to non-technical business executives. By the way, I put this strategy together during my first 100 days into my assignment, in the midst of many other operational responsibilities:

Sharing my writing example exercise from Amazon's interview process

Here is what I submitted to Amazon, as part of their interview process for an L7 Senior Engineering Manager role, in 2020. Depending on the role you're interviewing for, you will get a writing exercise - the one I chose was on Innovation - here's the ask:

Innovation

What is the most inventive or innovative thing you've done? It doesn't have to be something that's patented. It could be a process change, product idea, a new metric or customer facing interface – something that was your idea. It cannot be anything your current or previous employer would deem confidential information. Please provide us with context to understand the invention/innovation. What problem were you seeking to solve? Why was it important? What was the result? Why or how did it make a difference and change things?

Writing Guidelines

1. Write in the style you would use to write a business whitepaper or essay and do not use bullet points, graphics, tables, charts or flow charts.
2. Do not include any confidential or proprietary information from current/past employers.
3. Remember as you write that the reader may not be familiar with specific technical terminology, corporate cultures, and scenarios.  Use language and descriptions in your response that enable readers to fully understand the situation.
4. Please limit your response to 1-2 pages (no more than 8000 characters).

So since I was experimenting going back to being close to technical engineering, I decided to go deep into my past as an engineer, when I invented the Talking EPG:

More than ten years later, a talking interface finally made it to general availability:

Here's the document: Two pages in length, keeping to the written guidelines.