LinkedIn Profile - probably a bad example

I spent a lot of time contemplating what should go as my "About" summary for LinkedIn, it's quite tough actually.

So I had this written down below for about 18 months as my profile, and I'm about to change it to just keep it simple and brief. Looking back, it's too much waffle..

Helping Africa's largest PayTV company build an internet TV platform, building local African engineering team & skills. This platform serves 50+ countries, multi-tenanted, multi-product & content packs. Scaled platform 6X through nurturing teamwork, MAU on a steady increasing trajectory, overall site traffic growing nicely YoY.

CTO for DStv Now, Box Office & Content Discovery Recommendations Tech stack, managing 100+ engineers: Enterprise Architecture, Software Delivery, AI/ML Scientists, Agile PMO, Infra/Networks & Ops/Site Reliability engineers.

I'm NOT strictly a builder anymore though. I haven't written code in ten years, but was once an expert coder. I don't do architecture anymore, but used to love models, abstractions, API design & authoring technical documents. I don't write or review test cases & test plans anymore but instead drive innovation & optimisation in automation & DevOps continuous delivery. I don't review code or do systems integration anymore but can write (have written) treatise on these software engineering topics.

Yes, I'm building an E2E tech stack commanding a v.large budget, in a fast-paced VUCA world.
Yes, I handle tech conversations & make tough decisions, engaging and challenging C-level executives.
Yes, I do write technical papers.
Yes, I can indeed get into engineering detail too...BUT...

I CHOOSE to LEAD through PEOPLE: empower, protect, listen, steer, guide, groom, mentor, coach, train, show & tell, nurture-to-catapulting NextGen leaders we so desperately need today...

Some people call me a turnaround specialist - rescuing distressed projects & teams...
Others have said I have a knack for making the complex look simple...
I've built full stack software from device firmware, middleware, apps to server-side systems.
I was once an expert technical project and program manager, but that too is no longer who I am...
I was also a scrum master, agile coach, devops & agile delivery release manager too...I was also a senior management consultant...

So who/where am I now??

I am now a builder of LEADERS, who happens to be a senior engineering guy with PI-shaped skills, who loves to solve perceived intractable problems and thinks big: org, people, radical ideas, disrupting, transformation.

I'm known to challenge status quo, ruffle feathers & doing things differently - radical candor. Sometimes seen as a threat to old-school thinkers.

Autonomy & Trust is where I thrive - democratising the workplace!

But I tend to get bored easily if I'm not stetched or challenged enough. Typical cadence is 3 years before changing! 

On: Never fight a battle you're not prepared to win

A topic that's been on my mind of late...

The thing with "Pick your battles"...

Everyone says, "Pick your battles," and they're right. But usually they only mean "Pick your battles based on whether or not you have a good chance to win." That's fine, as far as it goes. But we think you should be even more pickier. 

Only pick battles that are:

a) winnable

b) important

c) battles for which you're fully prepared to pay the price to win

d) battles you're damn sure you can afford to win

-- Quote from "Buck Up, Suck Up...and come back when you foul up" by Carville & Begala

So think and reflect on that deeply. Remember other anecdotes "If you want to fight, you have to get into the ring, it will get bloody messy but you can't stop until you give it your all". 

Which battles are you fighting in your head?

What's keeping you up awake at night, causing you sleepless nights?

This could be personal or professional, or a professional work scenario that's starting to negatively impact your personal & family life, possibly causing anxiety and borderline depression.

Before diving straight into battle mode, it might be prudent to find a quiet space to brainstorm.

Mind map each scenario and use the four criteria above to map pros/cons, upsides/downsides, apply some rationality to the process. 

It will be hard to fight the emotions, but you got to try.

Be critical.

Be meticulous.

Be objective.

Play devil's advocate. Is it just your ego being bruised?

It's not about being safe and taking the easy way out, nor is it about being risk averse. It's about being sensible, a matter of calculated, smart survival tactics, at the expense of giving into emotions.

Sometimes one has to lose a couple of battles to win the war.

It's about the long game - envision a future where your current troubles disappear and replaced with victory & triumph. Keep doing this as often as you can to get through the dip.

But...sometimes, if not most of the time, emotion & gut instinct are indeed right! After thousands of years, we humans still have our lizard brain, the instinctive reflex of "fight or flight" has served  and continues to serve & save us.

My gut instincts have saved me more times than I can remember, so it might be perfectly okay to react too.

Going with your gut, embracing the emotion (anger, disappointment, betrayal, rejection, doubt, etc.) can be very powerful motivators for change...

These, coupled with your closely-bound value system, can be the only key indicators for you to decide to get into battle...when you do get into it, you need to be prepared for various scenarios...especially when the impact of going into battle has far reaching consequences other than yourself: you family, friends, loved ones, colleagues, your own reputation, etc. 

Another tool is to seek out close confidants, mentors and guides - the counsel "Shura" of other trusted parties can generally help you seeing things that you might be currently blind to (since all you can think about are the battles raging in your head).

After all of that, once you've processed the noise in your head, sought counsel, go back and ask yourself: What am I willing to walk away from??

Then....

Take a deep breath...build up courage....and take that first step (battle or not) and never look back...

another #thismightnotwork post

On 20th work-anniversary

This month marks my 20th work-anniversary as an engineering professional. Twenty years with the changing landscape of MediaTech PayTV Software Systems.

Looking back to how it all started: It took a few nervous months to land my first job after graduation '99. Getting anxious by-the-day after previously declining a forensics post at Deloitte; declined another Oracle DB admin at Vodacom as well, I waited for a pukka engineering role. I wanted to build stuff, my hard slog of 4 years studying electronic & software engineering should be put to good use after-all!

Altech UEC (which no longer exists today but was once SA's engineering darling) finally offered an entry-level engineer-in-training post. This introduced me to the world of digital TV set top box development. A year later, I was off to Dublin Ireland, working with Europe's top silicon & software design services house (S3 Group. now Accenture). 20 months later, off to Southampton UK, working with NDS (was Cisco, now Synamedia), the best engineering & management experience - we built some cool stuff light-years ahead of the times; and ran some massively complex projects. I spent 8 years there in UK, before returning home to SA (as a foreigner nogal!), to work with Multichoice, Africa's best storyteller, helping build NextGen Internet-TV products.

From engineer-in-training to CTO-Head-of-Technology in 20 years... Who could've thought, growing up in apartheid South Africa, underprivileged socially & financially, blue-collar family. Engineering was my 3rd choice, the practical one, the one that made most sense economically, after being accepted to medical school but not having the financial support to pursue...

Truly grateful to many-a-friend, family-member & colleagues for helping me get to see this milestone.

#gratitude shout outs to my past colleagues - you've left an impression I will not forget. #shoutout to all these great people that I've learnt so much from, thank you!

Waldemar Keyser David Siedle Rajesh Madhanlala John Maguire Cathy Guinan Hermann Wakolbinger Liam Friel Steve Taylor James Cunningham Brinton King David Dinsdale Stewart Towler Mike Palmer Salik Miah Gareth Bowen Tom Burnley Steven Coul Matthew Howe Matt Spencer James Wilson David Mandelzweig Shlomi Rosenberg Steve Williams James Field Nick Thexton Gerdus van Eeden Phil Nicholson Anand Govender Mark Rayner Graeme Cumming Bradley Daniels John Kotsaftis Bradley Eliot Farid Essack Andrew Dallas

#careeradvice - Work hard, have grit, patience & perseverance. Always do your best work. Only You can make it happen! Take chances. Take calculated risks. Switch jobs every 2-3 years. Switch domains every 2-3 years. Switch industry every 5 years. Always keep moving forward. I am a product of my time, 20 years is too long to be in one industry, stay a maximum 5 years before moving on....I do feel an itch coming on! My next 20 years is going to be different - 2021 should be the year of change!

On Leadership: Be Like Water

So I took a chance this morning and posted my first article on LinkedIn:

We talk a lot about transformation these days. Executives want to gear up for the future, speak the latest buzzwords"agile, flexible, adapt-to-change, level up for the digital world, challenge-status-quo, call-things-out" etc. All great intents I suppose, but what is sometimes ironic is that these same people are actually unwilling to let go, unwilling to adapt, maintaining the old-school mentality, staying within their comfort zone, symptomatic of being too afraid of conceding their power.

I've been in a state of continuous adaptation for as long as I can remember, my own leadership style has flexed and morphed along the way. It wasn't easy. It's actually very, very hard. Changing habits, value systems and mental models can be straining intellectually & psychologically. Practising self-awareness (i.e. embracing change in your leadership style) reminds me of the epic battle with Gandalf the Grey & the Balrog in Lord of the Rings...

Rigidity is a kin to brittleness. Brittleness leads to breakages. When things break, it's not always possible to put the pieces back together again. Fluidity is thus an important trait for today's leader. If you insist your ways don't need changing, then I'm afraid you'll soon realise "being out-of-phase, completely misaligned & out-of-sync" with the tunes of the current workplace vibe.

Sure, hierarchy will not disappear anytime soon and thus deserves respect. Sure, we need visionary leaders, but more so than ever, I believe we need execs to display courage, courage to be called out now and again, a healthy willingness to stop hiding behind positional hierarchy and instead, listen more, maybe at times be brave enough to step-aside and let things "just flow", being more like water. 

Hence, I am reminded of Bruce Lee's "be like water" teaching:

"Be like water making its way through cracks. Do not be assertive, but adjust to the object, and you shall find a way around or through it. If nothing within you stays rigid, outward things will disclose themselves.
Empty your mind, be formless. Shapeless, like water. If you put water into a cup, it becomes the cup. You put water into a bottle and it becomes the bottle. You put it in a teapot, it becomes the teapot. Now, water can flow or it can crash.
Be water, my friend."
- Bruce Lee

What makes OTT Streaming platforms different to DTH/DTT STB Broadcast?

In the early days of this blog, I shared in deep detail the technical and project landscape of PayTV systems for the traditional broadcast headend and set-top-box (STB) software platforms and projects as subject matter expert in this area.

In this post, I will provide a high level overview of the core differences and challenges between broadcast DTH/SetTopBox systems versus OTT platforms. OTT has become a hot topic, with the nascent rise of OTT (Over-the-Top) internet streaming platforms that many a traditional PayTV operator is now transitioning to, in light of the growing competition for eyeballs & cord-cutters driven by the likes of primarily SVOD (Subscription Video On Demand) players like Netflix, Amazon & the like. The challenge though, is that these PayTV operators tend to trip up by bringing PayTV/DTH thinking into the OTT-world, which is why I felt the need to write about this, because I have, and still am currently experiencing these challenges. Suffice to say, it becomes very tricky to disagree can call out a high level broadcast TV executive's assertions (expecting like-for-like DTH & OTT experience) as not completely accurate when it comes to OTT engineering...

The main aim of this post is thus targeted at senior executives who come from a broadcast world, and may not fully grasp the nuances of an online streaming world, specifically pointing out the spectrum of control of the end-to-end platform that PayTV operators generally enjoyed much comfort in that world, in contrast to the new world of online, where it becomes impractical to expect the level of control previously enjoyed - basically you can't control all the components of the internet, unless you invest in owning a large part of the network, which some operators have attempted & haven't really succeeded!! Simply put, the internet was not designed for Live TV streaming unlike traditional broadcast TV - the internet is somewhat chaotic & messy to say the least. In addition to this level of infrastructure control & lack thereof, an OTT platform is largely software systems designed for internet-scale (i.e. massively distributed server-side backend components) which requires a different skillset and experiences traditionally enjoyed in the closed ecosystem of broadcast & set top box device software development teams.

Another point of this post responds to the standpoint from traditional PayTV executives who may have spent a large part of their work in building broadcast systems with an engineering mindset anchored to a past era that is no longer relevant in the OTT world. Expressing opinions such as "engineering systems either work or they don't, it's either a 1 or 0, no in between states..with an expectation of 100% always-on availability..." in my view is somewhat misinformed & borders on belittling the engineering challenges faced in the online world. Whist every responsible engineer understands such demands and expectations of any system, a key point to remember is that broadcast TV has benefited from many years of refinement, standardisation, systems & processes specialised for the domain of TV - and when it comes to the internet - well, it was never really designed for video consumption, the speed of innovation has outpaced the development of standards & so is a much more messy world compared to traditional broadcast TV (satellite/terrestrial).

Disclaimer: This post is not about downplaying the broadcast engineering world, in fact, a lot of OTT operations highly depend on the upstream capabilities from PayTV operator's existing broadcast engineering infrastructure. Broadcast engineering systems are a marvel of engineering in its own respects, systems are highly complicated & superior engineering. OTT systems, and the point of my post, is to show the extension of the value chain, highlighting the new software & systems engineering challenges that present itself in the OTT world, that will be new concepts for existing broadcast engineering teams to learn & appreciate.

Key points for TL;DR folks (especially the PayTV Exec CXOs)

• It's not a simple thing to compare OTT platforms wearing hat of a traditional DTH broadcast guy, it  is not simply a like-for-like comparison.
• Don't be naive and pass value-judgements just because you were an engineer in the broadcast TV world (Headend or Set Top Box) does not necessarily make you qualified to understand OTT engineering domain. You can't bring broadcast/STB-thinking-mindset to the world of OTT.
• PayTV operators have historically enjoyed a high level of end-to-end control, not so in OTT world. The internet is outside the PayTV operator's control.
• There are far more components in the value chain of OTT than broadcast (backend, frontend and device software stack is more complicated in OTT than STB software).
• High level of device & platform fragmentation in OTT that a traditional PayTV operator must consider.
• The internet was never designed for TV consumption & has innovated at a much faster pace than traditional broadcast TV, the internet is a messy place, broadcast TV is somewhat cleaner and more determinstic.
• OTT engineering teams have different challenges compared to traditional broadcast & set top box engineering.
• PayTV operators need to plan carefully the convergence (DTH & OTT) of engineering teams and be prepared for a "clash of worlds".
• Set Top Box software systems enjoy far more security control & protection than its OTT sibling.
• Peak events & load challenges are unique to OTT platforms compared to broadcast DTH STB (scaling challenges don't really exist in DTH/STB).
• Redundancy, Fast Rollbacks, Failover & Disaster Recovery are easier to achieve in OTT than in broadcast DTH/STB systems.

On using metaphors for Tech Ops

I like finding metaphors from other worlds outside of technology or engineering that can help simplify concepts for business people. Using such comparisons "is like a..." can actually be quite a powerful way of connecting or contextualising, especially when these people (business stakeholders mostly) are not interested in the technical details at all. All these folks care about, when there's an operational issue impacting business/customers, are: "What's the issue? Why did it happen? When will it be fixed? I need 15 minute updates please. Not interested in detail. Just want to know when it will be resolved. And don't forget Root Cause Analysis RCA document & Consequence Management!" When I get these remarks,  I'm like...left dumbfounded...and decided to find another way of communicating to manage expectations better...

Enter...
#draintheswamp
#ICU

#draintheswamp

Despite the term being popularised by Trump last year, which was incidentally around the same time I introduced the term - in the software engineering community, "draining the swamp" is used to describe some refactoring and possibly restructuring of code and architecture, to address key bottlenecks, instabilities and optimisations. This could also mean revisiting original design & implementation decisions. Some people in software might put this under the bucket of "paying down technical debt" whilst others might just put this down as a natural part of the software evolution.

I used this term to prepare business people on the impact of the changes we planned to make. This was in response to a business ask of anticipating the biggest load of the tech platform stack - will the system cope with a "Black Friday-like event"? The simple answer was NO, not in its current form, that we would need to make some aggressive changes to the platform - like scaling out to multiple datacentres. The stack was built as a monolith (multiple services & components, some micro services, running on traditional VM infrastructure, not containerised, etc.) and so the best chances of scaling for load was to move the stack to run off multiple data centres, where we could scale up on each datacentre as well, but still had bottlenecks with share database cluster off one primary datacentre.

Suffice to say, this stuff goes above the heads of the business people. So I said, it's like draining the swamp. When that happens, we are bound to find some nasty things lying beneath the surface, things we don't see today, and can only see when we start draining the swamp. When this happens, and we hit some boulders or some unforeseen monsters of the swamp, we are bound to experience downtime and an outage or two. Don't panic, this is expected, given our working constraints, that is, make the changes on live production environment.

#draintheswamp went down pretty well with business. They got it. Left us alone. They trusted us! They managed the customer & business impact when we needed help, and our tech teams worked heroic hours to get the stack running off multiple datacentres, just in time for the biggest event of the business for the year (2018), our user numbers reached record highs, and the platform did not fall over! So round one of #draintheswamp was done, but the swamp was not completely drained out...

Until earlier this year (2019), when we kicked-off another round of #draintheswamp to start the migration to cloud stacks, starting with containerisation...which led the platform to suffer a series of outages at the most inappropriate moments...customers were pissed, business impact teams were on the back-foot, social media was killing us, the changes for #draintheswamp was starting to kill the platform...when I resorted to introducing another metaphor: #ICU. Folks, the tech stack is in some severe TLC, we are instigating #ICU mode. Life support is initiated, vitals are not great, but patient is surviving, and needs high level of critical care...

Technical Operations / Site Reliability Engineering is not so different to running a hospital's ER Emergency Department...at any time, despite monitoring vital signs of existing patients (system components of tech stack), or doing day-to-day operational management of the ward (infra maintenance), an event could occur that can just spike, like a natural disaster, accident or terrorist attack (hardware failure, critical component dies, database crash unanticipated, etc.)...ER staff have to triage quickly (Tech Ops also have to triage), make life/death calls (Tech Ops when to call a P1 incident & inform business), decide on severity of the injury (requires immediate attention, operate now, or can wait??)...the same holds true with bringing back a technical platform from death to living healthy operations...so why wouldn't we want to reuse medical terms?? I think it makes perfect sense!


#ICU

The gist of this metaphor is simple: ICU/CCU means Intensive/Critical Care Unit. When a patient is in ICU, it is serious stuff, urgent priority, focused attention to monitoring, diagnostics & multiple treatment options, using whatever means necessary to enable a positive outcome for the patient.

The typical flow to recovery to health looks for these transitions:

• Start in ICU/CCU, remain there until a period of time where interventions applied & life-support is no longer necessary, then...
• Transfer to High-Care facility, remaining close to ICU, but stable enough to warrant reduced focus and attention as compared to being in ICU, but be prepared for surprises, so best be close to ICU ward and not far away...wait until doctors give the green light to move on to...
• Normal / General Ward...the last stay before checking out to go home. Vitals and all other required checks all pass before discharged for home...

Although being in #ICU is rather stressful for everyone, there is a high sense of urgency, and the pressure to respond to business is quite intense (especially when Risk/Governance demands "Consequence Management"), we can draw additional parallels from medical ICU, like:

• Remaining calm, address the topics / unknowns in logical manner, using tools of diagnosis you've trained for (Technical tools like Five Whys, etc.)
• Running tests, take blood samples, etc. (Tech/Data forensics, logging, test hypotheses, etc.)
• Call on other medical experts to bounce diagnosis / brainstorm (Involve as many tech experts to offer new perspectives)
• Implement treatment plan according to hypothesis, wait for new results (Fix something, wait, analyse result, before making additional changes).
• Communicate clearly to patient's stakeholders (Communicate to business stakeholders transparently without hiding or being defensive...come clean).
• Pray :-)

Unpacking the medical terms...

According to Wikipedia, an ICU:

An intensive care unit (ICU), also known as an intensive therapy unit or intensive treatment unit (ITU) or critical care unit (CCU), is a special department of a hospital or health care facility that provides intensive treatment medicine.

Intensive care units cater to patients with severe or life-threatening illnesses and injuries, which require constant care, close supervision from life support equipment and medication in order to ensure normal bodily functions. They are staffed by highly trained physicians, nurses and respiratory therapists who specialize in caring for critically ill patients. ICUs are also distinguished from general hospital wards by a higher staff-to-patient ratio and to access to advanced medical resources and equipment that is not routinely available elsewhere.

Patients may be referred directly from an emergency department if required, or from a ward if they rapidly deteriorate, or immediately after surgery if the surgery is very invasive and the patient is at high risk of complications

When a technical platform goes into #ICU, we do the following:

• We're on red alert - life threatening to business (customer experience is tanking)
• Stop all other development work, or reduce planned work as much as possible by pulling in all the people we need to help (speaks to higher-staff-to-patient ratio)
• Pull out all the stops, bring in experts, tool-up with advanced resources and equipment
• Communicate daily to all business stakeholders
• Perform multiple surgeries if needed (hotfixes, patches, etc.)
• Run multiple diagnostics in parallel (think Dr. House)

According to Wikipedia, a High Care/Dependency Unit:

A high-dependency unit is an area in a hospital, usually located close to the intensive care unit, where patients can be cared for more extensively than on a normal ward, but not to the point of intensive care. It is appropriate for patients who have had major surgery and for those with single-organ failure. Many of these units were set up in the 1990s when hospitals found that a proportion of patients was requiring a level of care that could not be delivered in a normal ward setting.^[1] This is thought to be associated with a reduction in mortality.^[1] Patients may be admitted to an HDU bed because they are at risk of requiring intensive care admission, or as a step-down between intensive care and ward-based care.

According to HealthTalk, the last point to recovery is General/Normal Ward:

People are transferred from the intensive care unit to a general ward when medical staff decide that they no longer need such close observation and one-to-one care. For many people, this move is an important step in their progress from being critically ill to recovering..

'Nuff said, IMHO the similitude mentioned above should be more than self explanatory ;-)

Experiments with XL: Extreme Leadership (Paired Management)

I recently (in early June) took some time off from life and work, decided to be completely unplugged for ten full days, with no access to any electronics whatsoever. This break from work coincided with the last 10 days of Ramadan, a practice called Itikaf, which is about secluding (surrendering) one's self to God by living day/night within the precincts of the Masjid boundaries, where one is engaged in various acts of worship, including self reflection, self-awareness & meditation. Itikaf is about leaving it all behind, including your own family.  I had actually made my decision sometime in April, a feeling that suddenly inspired me as something I just needed to do, without too much thought or planning. I immediately fired off an email at 5AM informing by boss (the CEO) of my upcoming intent, not really seeking his approval - I merely informed him that I'll be away from the office, completely unreachable for 10 full days, a personal life quest I needed to fulfil...thankfully, the boss didn't get in my way ;-)

When people, both friends and colleagues included, found out about my leave plans, they immediately enquired how I was going to manage the work topic. I lead a technology team responsible for an online video platform for DStv (providing live/linear streaming channels as well as video-on-demand Catch Up services, we also support a major part of the business with a full digital/web platform infrastructure). Around that time, my teams were working flat out to stabilise & scale the platform for increased load, in preparation for the FIFA world cup. We will only be ready to "freeze" a week before world cup - how could I possibly leave the team at such a critical period??  On top of that, my division was part of an ongoing group-wide organisational restructure, in those two weeks, there was much HR work to do, including rationalising job roles across various technology divisions, job grading, role & people profiling, as well as one-on-one consultations. How could I leave the team leaderless through this period?? And to add a cherry on the top, whilst I would be on leave, the group's yearly Ops Review would've taken place, I would need to input into this stream as well.  As if this wasn't enough, there were concerns that my leadership team was fairly new, people had some doubts...

I wasn't really concerned by these, instead I saw it as the perfect opportunity to test my leadership team. Whilst a fairly new team that's been only recently formally announced, they are still in between the storming/norming phase (even though it's been over a year since they're under my leadership transformation). I wanted to test out a few things:

Update: Reflections on my career in Software Engineering & Management

Two years ago around this time, I explored my progress with respect to my career choices by performing some self-reflection, by asking myself some searching questions. Later I shared my findings on this blog, in this post: Reflections on my career in the hope my story could resonate with people who may be experiencing similar challenges. I'm glad I did so since people did actually reach out, thanking me for the post & providing feedback.

Anyway, two years have since passed since I last shared the cross-road I found myself at, since I'd started my journey with this path in mind...

a) Software Team Lead -> Software Manager -> Senior Manager -> VP -> Director -> CEO

b) Principal Engineer -> Senior Principal -> Technical Director -> CTO -> CEO

b') Principal Engineer -> Architect -> Senior Architect -> Director -> CTO -> CEO

c) Technical Project Manager -> Senior Project Manager -> Program Manager -> Director -> CEO

...but instead found myself being in the technical project management space for too long, that people started naturally profiling me as the "rockstar program manager" (check out my LinkedIn recommendations and you'll immediately see why). Whilst this is a great place to be (don't get me wrong, I think a career in Project Management is one of the most versatile, lucrative and flexible professions out there, I highly encourage the move), for me, I felt I'd learnt and experienced enough, that I didn't see myself doing that for much longer. I did enjoy the project leadership, but I wanted more. Another factor that was causing me anxiety was that my role as a management consultant was getting a bit boring, what I imagined it to be versus the reality were not fully aligned. My time was fully consumed, leaving me little time to explore my own ideas to look at new ideas/products (my own start-up), I might as well have been a permanent employee - I was living an illusion, in reality I was basically a "perm-tractor". I had built up enough personal equity, credibility to enjoy a decent level of referent power to indirectly influence outcomes in my favour, I still wanted more - I wanted to feel more alive than being a neutral facilitator (which in itself I found quite rewarding but also quite energy-draining).

So what did I do? I went back to my RAGE model, here's what I had for my persona as a professional:

• As a software professional, I would like to learn & grow, seek out individuals, companies and interactions, to reach heights of excellence, so that I can not only enjoy the profession, but take me to new opportunities & experiences. I want to surround myself with people that motivate me, journey together to grow to the next level.
• Want to work with inspiring, motivated leaders that I can learn from. Want to surround myself with deeply technical, bright people. Want to work with people who know what they're doing or unafraid to take chances. Want to work with disruptors, people unafraid to push boundaries, challenging status quo. Want to work with people who are equally, if not, more motivated than me. Want to learn from people so that I can grow and do my own thing one day. Want to be with fellow professionals that will help take me to the next level. Want to work on projects and products that are interesting and cutting edge, not "me-too, copy-cat products. Want to stay at the cutting edge of software, be involved in the next wave like cloud services, mobile app development, car infotainment / self-driving cars, drone software, cloud, etc. Want a chance to start-up my own business in ideas in product development, services-space like crowd-based testing, etc.
• As a professional, I want to run a company, lead my own division. I believe the experiences and skills acquired over the years puts me a good position to do this, regardless of technology stack. I haven't been successful in launching my own start-up, so the best place would be to go back to corporate, be part of story much bigger than myself, and get the experience I need.

I also came to the conclusion that being a specialist is not a bad thing, so I'm now settled with the fact that I'm a Digital TV Technology Specialist, so I should just focus my energy in this area. I can still keep abreast of new technologies, but the road to my continued success is to build upon this experience - the rest is noise - if an opportunity comes my way for investing or if there is something truly exciting with a lot of upside, then I still might consider it ;-)

So what's happened in the last two years?
I made a decision to leave project leadership behind. I explored opportunities that aligned with my aspiration of running my own division. I took a chance by breaking the perception that I'm the guy to call in to rescue failing projects - landing an engagement as interim GM/CTO. A year later, I decided to leave consulting (248 weeks consulting) altogether and enter the corporate world as a permanent employee, taking on a CTO/Head of Technology role :-)

So my path has indeed played out a little different but now seems to be back on track:
Software Engineer > Senior Engineer > Technical Project Manager > Senior Project/Program Manager > Principal Engineer > Program Manager > Management Consultant > CTO (now) > CEO (next)

Lessons learnt / myths busted?

Who says you can't change tracks in between (especially switch to project management) and switch back to technology leadership? It can definitely be done!

Be prepared to Leave it All Behind as long as you believe you're heading in the general direction you seek (maintain your guiding compass always).

Take time to process your situation with Life/Work by investing the time in self-reflection & planning. I found my RAGE model to be a constant source of guidance. It does take some self-control, but it will be worth it in the end, just keep at it...

It is indeed possible to start from humble beginnings and change your life for a better outcome...

On Managing Change: Damped Sine Wave

I recently read a piece from the June edition of ACM, Q&A with Erik Meijer, which I found quite apt as it speaks to my current situation at work. Whilst Meijer talks specifically to software projects, we can apply this to any kind of topic, be it personal or professional, work & life - everything we encounter when it comes to dealing with change & uncertainty (career, new teams, family, new projects, etc.).

This is especially relevant to the period I'm in now, a leader driving change - i.e. changes to the way we working, kicking-off a focused management war room, and the recent announcements around delivery priorities for the next three months. This is a large corporate, multi-million dollar industry, the amazing part is that things are so fast-paced and always changing that one can argue that the only constant in this company is one that of Change!

So we need to deal with this reality, it's not going to go away anytime soon. My experience is pretty much aligned to Meijer: try to manage the level of uncertainty (balanced by one's appetite for risk) as quickly as possible through communication & stakeholder engagement, converge on well-bounded known-knowns based on the information we receive, agree to execute & deliver within the binding time constraints. Add to this is a sense of measured calm and patience, start practising ways to control your default responses too...

Courtesy: ACM

Below is the excerpt of the Q&A:

<quote>

What is your team process? How does work get done? How do you communicate status? 

A lot of what you read about process and agile has very little evidence behind it. I don't believe a lot of process is scientific. Instead, I define general guidelines about what I want to see happen, and within those I don't care how things happen.

My thinking has two main sources of inspiration: the military and the hacker way.

Over thousands of years, armies have figured out how to get things done and achieve their goals in an environment that is really chaotic and unpredictable. That is the environment we live in as developers as well. If you read the U.S. Marine Corps Warfighting manual, and replace the word war with software, everything in there holds true.

So how do you deal with uncertainty? When people attempt to solve with process, they are trying to fight or control uncertainty. For example, someone can say just adopt zero inbox and your life will be awesome. In reality though, that isn't really the case.

One of the things I like about Facebook is "the hacker way". It is an approach to creating software that involves continuous improvement and feedback. It is about computational thinking: how do you program the system, and how do you make the system do things that no one thought possible?

Being agile is about communication.

The process needs to change with the situation. You have a big picture of where you want to go, but any plan or process will shatter immediately when you hit your first bug or something happens out of your control.

In most projects there are two phases: an exploratory phase and an execution phase. Your project should progress like a damped sine wave, where the amplitude gets smaller over time (see picture above). You have to figure out what to build, and figure out what question you are trying to answer. In the beginning you want to increase the vertical velocity to get the uncertainty under control, and then you want horizontal velocity to increase when you get into execution.

With prescriptive processes. people are looking for a silver bullet to solve problems, but it doesn't exist...the world is super-confusing, and you have to embrace it and work with it.

</quote>