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

Year 2019 in Review, Welcome 2020!

I'm now entering my fifth year of time logging and keeping track of all my "life & work"-streams in an effort to make sense of my time sinks, cross-checking my aspirations & goals with reality, in the hope of tuning, re-calibrating areas to be more in harmony with my purpose / value system, sometimes triggering some decisions that could take my life-and-work in a different direction altogether. So I've become a bit of geek with the #quantifiedself so much so that I log almost everything all the time. This habit developed naturally as I spent five years consulting, needing to keep track of all my hours and tasks for billable hours. So I took this all the way into treating my entire life as one big project with multiple tasks that needed accounting!

In 2015, I spent a lot of time soul-searching to make sense of not only what I want out of my life but my work/career aspirations as well, since a major part of my life involves my occupation in the software industry. So I came up with a model called RAGE (Reality, Aspirations, Goals, Expectations). The way the model works is to split yourself into "Personas" sliced into Personal and Professional streams. Using some tools from Agile, such as user stories, you describe for each of your personas, your aspirations, reflecting on your current reality, then setting goals and expectations. Your personas are prioritised by value, which is basically an instinctive, gut-feel assessment of the value/importance of the stream, in comparison to the others. I'd created template and a matrix tool that allowed for easy prioritisation, and a template to help others on this journey as well. My hypothesis still remains valid that tracking time is one way of understanding where my time is being spent, proposing "I will naturally spend most of time dedicated to the persona streams that are of importance to me" - but the reality can sometimes be quite surprising!

In this post, I continue with my annual ritual of starting the new year by analysing what went down the previous year (2019), and how/what I would need to re-calibrate to get me on track with my life's journey-mapping into 2020:

• Recap my personal value system - persona matrix & priorities
• Snapshot of tracking my RAGE progress by milestone reviews heatmap
• Performance appraisal - Did I achieve my intended outcomes / goals set in Jan 2019?
• Quantifying every hour of 2019 - where did I spend my time, what did I do?
• Does it look like I have my life-work balance under control?
• Am I working too much, sacrificing my personal and family streams?
• Am I enjoying my current job?
• What are the main things impacting my future personal & professional aspirations?

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.

Open letter to Business & Tech Leaders

Dear Business & Technology Owners...

Have you ever stopped to reflect on why is there always tension and conflict between business stakeholders and technology providers? Instead of there being a "healthy tension" between the two partners (assuming you take the terms "partnership" seriously and not just paying lip service to the term), the relationship is often clouded with doubt, suspicion & mistrust on all sides?

I've been in this technology software business for all of my professional life (~20 years), spending the first half working on technology product & platform development (company run by engineers & not accountants), and the latter half on the other (dark?) side - the corporate business - with in-house technology / IT "service" divisions, where business (accountants mostly non-technical) people run the show - an environment where there is often just a complete lack of alignment, understanding & appreciation for what goes on in both worlds: technology-and-business-worlds alike.

[Bias disclaimer: Yes, I do I have a bias - I believe if a company thinks itself to be a technology-driven business, then I expect the CEO to at least have an engineering/science background, or the CTO/CIO must have written code & built solid (industrial-strength) products in a previous lifetime. If a CEO is not technical then at least develop a keen appreciation for the engineering challenges and then trust your technology owners to do the responsible thing & you move out the way....]

At a recent ExCo of which I'm just an observer - this lack of alignment reared it's ugly head again when "the business" could not understand how a six-month's projects wish-list from their side, translated into a two-and-a-half-year implementation estimate from the technology team, making a poor attempt at explaining, the classic "IT demand & capacity planning" challenges (what I still find quite surprising in today's time, a topic for another day, let's just say I think "IT Demand Management Process" is not relevant today, and I propose that this is just "old-school-IT" & that its days are numbered).  

What followed then from business was the typical:

• "Why don't add another 20 development teams to make the six months timeline?"
• "Why can't we have CFTs (cross-functional-teams) like the other divisions have?" 
• "Are you sure you have the right engineers? Why is the system so brittle? Why must it take so long? Should we take our business elsewhere?"
• "Why can't we have bespoke technical teams attached to each business owner?"

What also makes this quite a difficult conversation is the CULTURE - where technology teams have historically been at the receiving end as the source of all business problems (the cause of business frustration), the underdogs, just taking a beating from business, without any confidence to push back & have constructive conversations. It's a shame really that a large number of technology teams just have to "submit" and "do as you're told" by business...surely it can't go on like this??

So this is what I've reflected so far - and it calls on both Technology & Business leaders to come together to the table, for me it's simply about ALIGNMENT. In order to align, one needs to really LISTEN. I mean REALLY LISTEN and PARTICIPATE in dialogue, after-all, this is what PARTNERSHIP supposed to be about, right??

Dear Technology Leader...

I think a large part of the issue is technology leaders not doing enough to communicate and simplify the reality of their world. Assuming you're not building a greenfields stack, instead you're building on existing systems (not legacy, but still probably reaching end-of-life), more needs to be done to manage expectations. I would avoid too much abstraction & side-stepping: be open and transparent about everything, no hiding...here's some searching questions:

• Have you stopped yourself to reflect on why there is such a disconnect or lack of understanding? What are you doing wrong? Is there a fundamental issue of principle?
• Have you taken your customers through the system architecture and current challenges?
• Have you communicated your assumptions clearly? For example - does the business understand maybe you're trying to build a common platform/product stack that can support multiple business requirements (e.g. in a multi-country scenario) in one-go?
• Is this assumption valid? What if the businesses are quite divergent in terms of customer requirements?
• Why is it important to provide a common technology platform anyway? For who's benefit?
• Would it not be easier to branch the code & platform to serve individual businesses? Risk duplication but gain in business agility? 
• Who cares if the code is forked anyway, has this option ever been tabled?
• How can you explain the nuances of common stack software development to non-technical people?
• Does business understand how you've structured your delivery teams?
• For example, you might be running with component teams, specialisation instead of generalisation and not ready for cross-functional full-stack teams yet?
• Are you clear where your bottlenecks are?
• Is your software engineering principles solid - i.e. can it support multiple release streams simultaneously?
• Have you shown to business the complexities of what it means to spawn up multiple teams (i.e. this rather stupid notion of adding more people to get the job done sooner)?
• Have you established a way-of-working between business & technology that aims to at least address some of the challenges, and set forth an ultimate vision / aspiration of what ideal could look like?
• Are you doing enough to manage expectations upwards and thus protect your teams?
• Why do you have a need to insert "Business Relationship Managers (BRMs)? Are your technology teams not equipped in dealing with business stakeholders directly? Why do technology units decide that an intermediary BRM would help solve relationship problems?
• Are you empowered enough to challenge priorities & requirements if they don't make sense to you?
• Have you communicated that systems generally have to refresh every 3-5 years? Have you considered presenting a technology roadmap showing all the technical initiatives planned whilst simultaneously expected to keep the business lights on (business-as-usual) and still stay ahead of the curve to keep your stack technically relevant?

Dear Business Leader...

Just as there may be some gaps with your technology leader counterparts, you should consider what gaps are on your side. For starters, have you really invested time to LISTEN to your technology partners?

• Have you done enough to convey your business vision, strategy & goals in a clear manner that informs your technology partners of the role they play & your dependence on them for your overall success?
• Have you resisted the urge to bark orders without first trying to listen?
• Do you have an understanding of how your technology teams have built the system & components? Perhaps you had a role to play in this - i.e. ending up in the current state because of business owners?
• Did you perhaps grow up with the industrial mindset (factory methods) & expect that software systems follow similar patterns "it's just a production line outputting widgets"?
• Do you understand what it means to write common software code and deploy common  software & infrastructure to serve the needs of multiple businesses (with its own set of rules)?
• Do you have a clear picture in your mind of the distinctions and challenges of software teams: Component teams versus cross-functional teams?
• How do you as business owners come together to align on overall business requirements (assuming you're in multi-country set-up) that shares a common platform?
• Did you even agree with technology that a common platform is the way to go?
• Are you doing enough to review your own project's backlog and business requirements - by priority?
• Do you accept that your technology team would appreciate from focus - i.e. do one thing of value at a time?
• Are you doing enough to make sense of your own business priorities?
• Have you read "The Mythical Man-Month"? Do you actually believe that "adding more people to a software project will get it done sooner?" - Are you not being naive, have you stopped yourself to reflect that maybe you're just not getting it??
• What are you doing to get closer to understanding your technology provider's challenges?
• Do you use the IT/technology systems on a daily basis?
• Have you considered sitting closer to your technology team?
• What is your role in the partnership? Is it too one-sided (i.e. your side)? Do you get immense joy at squeezing your technology providers, adding pressures and artificial deadlines to make your case?
• Why do you feel you need an intermediary between yourself & technology - and insist on this concept of a BRM? Are you not interested to learn more about your technology stack or develop closer relationships with the people building your technology? 

Attention Business-and-Technology Leaders - Don't look for that Silver Bullet...you'll have to discover this for yourselves, there's nothing off-the-shelf to plug-and-play for you...

You might have attempted every fad at improving process improvement, this "agile" topic has become so misused that both parties can't really tell if agile is working for you or not - and you're quick to blame the process, or attempt to try a new way, and even get professional consultants in to help...but...as I've experienced agile in a variety of forms in the past ten+ years, I still come back to the essence - and I really feel that people have misunderstood the core. This core that I refer to, is the founding principles espoused in the Agile Manifesto. Simple statements but deeply profound, and it all starts there. I feel this essence is often just skimmed over in favour of an execution process which has led to the downfall of many IT/Business relationships, which is why we keep coming back to the rather archaic IT/Business management frameworks that calls for IT Demand/Capacity Management and Business Relationship Managers...

Go back, breakdown the silos, no pedestals or ivory towers allowed in today's age, re-align & commit to participating in respectful, sincere dialogue, meeting each other half-way. Identify the root of the pain-points, agree on sensible ways to manage classic "capacity challenges" which simply implies some focused management of priorities by business people...if after you've tried to re-align, and still there's an expectation of infinite capacity from IT delivery...then...maybe there's just no hope left...

Yours sincerely,

A weathered-and-battered-technology-leader-looking-for-hope!

Whiners never win

Whiners never win!

What simple yet powerful, three words? 

These are words my electrical engineering professor used on me back in my second year, when I challenged my paper being wrongly graded.  I remember waiting a long time at his office just to see him, the prof just gave me one minute "Mr. Khan, here's some advice for the rest of your life - whiners never win". That was it, and then he left, my paper unchanged.

This stuck with me as I completed my degree, started my first job, took a chance one year after graduating by emigrating to two countries, marriage, parenthood, etc. I keep coming back to this simple message "whiners never win" and so just get on with life or work...

Yet, coming back to South Africa, now 8 years and counting, I was surprised to learn how much whining happens in the workplace! It is emotionally draining. Almost everyone has a complaint, not happy with this or that, unable to separate personal emotions from being professional at the workplace. Just a whole lot of whining going on. I wonder if it's just the context of the nation, just whining, starting with the commute into work listening to radio stations (like 702) which I've stopped completely. I actually don't listen to such news anymore, it starts the day of on the wrong note, stepping into the office with negativity and stress. Don't forget the stress of driving on SA roads...

I was also surprised how people tend to bring their home issues into workplace as well, affecting how they show up, perform, etc. My mindfulness, listening and empathy skills have seen an accelerated growth since 2011...

Still, eight years on, I still see it a lot of whining in the workplace...come on folks, stop whining. 

Whining never wins. 

Bring your best self to work, show up and get through the struggle...

Stop whining. "Whining never wins"...

Don't get me wrong, I've got loads of empathy...but at some point, people need to step up and just stop whining as whiners never win!