Innovation is much more than coming up with creative ideas, it's about having a culture of continuous improvement and forward thinking approach.

As a leader, driving innovation means fostering an environment where creative ideas can thrive and be applied as well in meaningful ways. True innovation combines vision with practicality, where leaders not only inspire curiosity but also align it with business goals.

Its equally important to avoid using jargons and buzzwords in the name of innovation instead practice innovation as an invested process with long-term value generation

Understand different types of Innovation

1. Incremental Innovation- Where in any business, the existing technology, process gets enhanced and improved , Majority of innovation falls in this category for eg. ios, android upgrades shows sustainable advancement over existing technology

2. Disruptive Innovation- Where a new business model comes in the market and disrupts the existing business, for eg, Quick commerce business in India have disrupt the traditional retailer markets forcing major large retailers to rethink their strategy

3. Radical Innovation - Where a business come up with big breakthrough of technology with significantly changing the industry product design and ecosystem around that, for eg Electric Vehicles where entire engine design, underlying technologies, emission all gets changed

Innovation: Pasteur Quadrant

Pasteur's Quadrant is a framework introduced by political scientist Donald Stokes in his 1997 book "Pasteur's Quadrant: Basic Science and Technological Innovation." The model classifies scientific research based on two dimensions: the pursuit of fundamental understanding and the consideration of practical use.

Lets understand these four quadrants:

The model consists of four quadrants based on these two criteria:

1. Low Use/Low Understanding Quadrant (Meaningless):

Little emphasis on either practical application or basic understanding (typically non-research activities).

Example: This quadrant is rarely populated by significant research activities.

2. Bohr’s Quadrant (Pure Basic Research):

High emphasis on fundamental understanding, no immediate practical application.

Example: Niels Bohr’s research on atomic structure, which was driven purely by a desire to understand the nature of atoms. Another example could be studying the other planet soil by sending robots

3. Edison’s Quadrant (Pure Applied Research):

High emphasis on practical use, no interest in deepening fundamental understanding.

Example: Thomas Edison’s work on developing the lightbulb, where the focus was on practical outcomes rather than basic science.

4. Pasteur’s Quadrant (User-Inspired Basic Research):

Combines the pursuit of fundamental understanding with solving practical problems.

Example: Louis Pasteur’s research on germ theory. While his work contributed to basic biological understanding, it was also motivated by solving real-world problems, such as preventing disease and spoilage. Medical industry in today's era continuously do that based on different patient's problems

Overall Quadrant Significance:

This Quadrant shows that scientific research can be both fundamental and practical, helping organisations and governments prioritise research that can drive innovation while advancing knowledge. It offers a middle ground between pure academic research and purely practical innovation, and it’s a key concept in modern R&D strategy.

My Takeaway :-

As a Technology leader, There are multiple ways of running innovation practices like design thinking workshops, hackathons, innovation day, Idea jamming session which business fosters by providing a regular chunk of time investment for innovation

What really helps in:-

• Set Clear Innovation Goals: Define your organisation's innovation goals and communicate them clearly to your team. This will provide a shared direction and motivation aligned with business goals and strategies

• Create a Culture of Curiosity: Encourage curiosity and a thirst for knowledge among your team. This will foster a mindset that is open to new ideas and possibilities who can challenge the status quo

• Provide Opportunities for Learning and Development: Invest in professional development programs to help your team stay up-to-date with the latest trends and technologies.

• Celebrate Successes: Recognise and reward innovation. This will encourage your team to continue taking risks and pursuing new ideas.

• Encourage Failure as a Learning Opportunity: View failures as opportunities for growth and learning. Create a safe environment where people feel comfortable sharing their mistakes and experimenting with new approaches.

Most importantly, establish a structured process to transform major ideas into actionable solutions. Often, valuable ideas remain unimplemented. thus, it's essential to create metrics to track progress from ideation to execution, ensuring that promising concepts are effectively brought to production.

References:-

https://blog.rootsofprogress.org/pasteurs-quadrant

https://hbr.org/topic/subject/innovation

https://hbr.org/2017/06/the-4-types-of-innovation-and-the-problems-they-solve

https://www.researchgate.net/figure/Stokes-model-of-scientific-research-Stokes-1997_fig3_46713948

https://futuretech.mit.edu/news/what-should-be-done-about-the-growing-influence-of-industry-in-ai-research

Based on my experience in the platform domain, here are some of the challenges Platform Engineering faces in generating a compelling value proposition:

Indirect Value

• Platform improvements often don't directly translate to user-facing features. Increased developer velocity or faster deployments might not be readily apparent to end-users.

Fallacy : "It Just Works" : When things run smoothly, everyone might take it for granted. One might not understand the complexity of the platform or the effort that goes into maintaining it. It can be like magic - "it just works" - without acknowledging the intricate machinery behind the scenes until something breaks down

• Features like reliability, scalability, redundancy, disaster recovery, and quality assurance might go unnoticed by the business until the system encounters abnormalities.

Measurement metrics complexity

• Balancing developer needs with business goals and OKRs are tricky. Platform features might address multiple developer pain points, might reduce revenue loss , providing stability and availability to business but not necessarily contribute directly to immediate business objectives like increased revenue.

• Quantifying the value of platform improvements can be difficult. Isolating the impact of platform changes on developer productivity can be challenging due to external factors.

Developer Buy-in:

• Let's be honest, as a developer, nobody loves getting notified about another infrastructure upgrade, especially when it involves dealing with API deprecations and other changes. It becomes even more challenging when no immediate benefit is perceived.

• Encouraging developers to adopt new platform tools and workflows requires significant effort. Overcoming resistance to change and ensuring the tools are user-friendly is crucial.

Bull Whip effect fallacy

• Building for perfection without feedback loops can lead to long development cycles, and when these features are finally adopted, they may not generate significant value.

• Single Point of Failure: A small issue in the platform, invisible to developers, can cause a significant performance degradation or even an outage. This can be like a stockout in a supply chain, leading to a scramble for resources.

• Over-provisioning: To avoid outages and ensure smooth operation, platform engineers usually over-provision resources (like servers or storage). This can be like a retailer ordering excessive inventory in fear of stock-outs.

Now Lets discuss basic solutions to tackle challenges shared above in order to generate value for your platform:-

Research and feedback Loops

• While designing any feature, Not only do industry research but also Collect input from platform users to identify issues and opportunities

• Keep on tracking platform performance metrics and share it back to users and business to understand and refine value proposition

• Feature and support Intake requests should compliment with feedbacks, both improvements and testimonials.

• User centric surveys to understand the pain points, strength and gaps to build future backlog

Iterative Improvements

• Follow agile sprint based iterative deliveries and identifies key milestones so that if Pivot is needed then decisions are taken at right time based on feedbacks

• Conduct regular deliverable and product reviews to assess past performance and plan improvements

• Regularly forecast metrics for staffing and cloud cost based on backlog and future traffic prediction to avoid surprises

Stakeholder Management

Leverage and identify various communication medium forms like slack chat, email, zoom, office hours, in office listening session, roadshow, tech conference basically any medium to communicate.

• Internal Community - Identify and build a community of early adopters as Platform Advocate, they could be developers, operations, product/program leads and executives to ensure balanced input.

• Internal Partner- Identify partners allies from your customers with whom any cross collaborative big programs can be run for a business wins where they have clearly defined business OKRs and they need exceptional platform requirements, don't forget to join their bandwagon and generate wins together

• External Stakeholder - Along with feedbacks, share the success stories, new features with identified users and sometimes specialised features tailored to the specific users. For eg, On platform you have unlocked a capability of running burst mode containers, so identify and reach out to all teams like Spark, Streaming who could be your potential users and even can join pilot runs.

Security and Compliance

• Regularly audit the platform for vulnerabilities and address them promptly, Relate this with Org wide OKRs, Identify your deployment size and measure risk saving numbers per cluster, per host, per servers

• Track compliance with industry standards and regulations, A basic task but took away your capacity, Measure this work in a reverse fashion, What if Its not done, what risk it imposes and then draw those savings as a metrics

Data Driven Decisions

• Most important Measure your unplanned effort, Platform engineers usually gets pulled in various directions , To bring back attention and to focus on developing platform , every efforts need to be measured and stack ranked.

• Regularly analyse key performance metrics to drive decisions. whether its feature adoption, platform adoption, business weightage.

• Cost Optimisation should be targeted complimented with Reliability metrics, No business goal can be achieved with trading offs one or another

• Measure burn outs for your engineering efficiency and regulate process around them being guard for your team as a leader to not say Yes to anything coming your way

• Identify and explore opportunities to cut down manual toil and Automate and measure those in terms of days, hours, cost save

Example Case Study: Prioritising Automation for Cluster Patching

Problem: The automation for cluster patching isn't being prioritised in the backlog as value loop is not assessed.

Solution:

=> Gather Data

Quantify Cost Savings (ROI): Calculate the manual hours saved by automating the patching process, considering the frequency of patches required.

Quantify Risk Savings: Identify the SLAs for addressing vulnerabilities and the risk associated with not implementing the automation. Compare the feature parity with open-source solutions if the automation isn't implemented.

=> Align with Business Goals:

-Department/Unit Goals: Let say If your unit aims to achieve 100% SLA compliance for addressing the latest vulnerabilities, emphasise how this automation supports that goal.
-Business Objectives: Link your proposal to broader business goals, such as improving security posture, reducing operational costs, and enhancing system reliability.
-Unlock Future Opportunities:
Automated Upgrades: Highlight how automated patching can pave the way for automated validation and testing, thereby increasing overall reliability and reducing time-to-market for new features.
-MOSCOW Prioritisation:
Ready for negotiations to have an MVP first to generate and visualise value as a fail fast approach. That means choose must-Have or the best should-have in first phase

=> Conclusion:
This exercise can even helps to validate whether you are advocating for the right initiative to ensure your team and unit meet their objectives. If the answer is yes, proceed with presenting this as a design value loop to stakeholders

Recently I penned an article about "Measuring your Platform Engineering Efficiency" ,Now I am taking a step back to offer a high-level perspective with a mind-map, which encapsulates the various verticals within the platform and illustrates their interconnectedness.

A new focus is emerging for companies that are dedicated to attracting and retaining the best tech talent: developer experience, Deloitte Insights tech trend 2024 report

While this mind-map serves as a valuable reference, it's essential to recognise that each organisation and vertical has its unique trajectory. Therefore, consider this mind-map a flexible reference point rather than a one-size-fits-all solution

Also to note:- Specified details do not represent the state of hierarchy of my current organisation and are used for illustrative purposes only.

Let's understand the various blocks mentioned in the MindMap:-

Pink Blocks:-

In the context of your organisation, Taking e-commerce app as reference, picture multiple service domains such as payment, cart management, inventory management, rewards, product catalog, search, storage, authentication, and more. Each of these can be likened to individual micro-services developed by application teams. When integrated, these micro-services culminate into an end-to-end e-commerce application

Light Blue Blocks:-

These gateways serve as the primary interfaces connecting your Application teams with Platform teams. Here's a breakdown of their components:

1. Operations (NOC): This encompasses the Network Operation Center, acting as the first line of support with 24/7 monitoring capabilities essential for on-call support. Equipped with runbooks and monitoring expertise, they facilitate fault isolation and initial recovery for emergency requests and escalated whenever necessary, whether to Application or Platform teams.

2. Ticketing Portal: Utilising portal like Remedy, JIRA, Service-now, or similar tools, this portal streamlines communication and issue resolution. It allows for self-service requests ranging from basic support inquiries to new feature requests or bug reports concerning existing functionalities.

3. Self-Service Portal: Representing a paved road or an internal developer UI portal, It provides an abstraction layer, shielding application developers from platform intricacies. Through automation or simple clicks, developers can seamlessly execute tasks within the platform layer, eliminating the need for in-depth knowledge of underlying platform components.

Grey Blocks:-

This Ground Zero Infrastructure team plays a pivotal role in the initial setup and maintenance of your infrastructure. Here's an overview of their responsibilities:

1. Day 0 and Day 1 Activities: They handle the installation and configuration of infrastructure components, whether on-premise in a datacenter or on the cloud. This involves provisioning servers, storage, networking, and other essential resources.

2. Virtualisation Layer Setup: They establish the virtualisation layer, whether it's on-premise or on the cloud, ensuring optimal resource allocation and management.

3. Network Policy Definition: They define and implement network policies and segmentation strategies to ensure secure communication between various domains, maintaining data integrity and confidentiality.

4. Security Audits and Implementation: Conducting security audits of cloud environments and defining host and operating system-level security measures are crucial tasks. They ensure compliance with security standards and best practices, mitigating potential vulnerabilities and threats.

5. Load Balancers, Firewalls, and API Gateways: They configure load balancers to distribute incoming traffic across multiple servers for improved performance and reliability. Firewalls are set up to enforce security policies and control access to resources. API Gateways with rate limiting capabilities are implemented to manage and secure API traffic.

6. Edge CDN Proxies and Cache Configurations: Setting up edge Content Delivery Network (CDN) proxies and cache configurations at various layers optimises content delivery, enhances user experience, and reduces latency. They also implement disaster recovery (DR) activities at the site level to ensure business continuity in case of unexpected incidents or outages.

Together, these activities ensure the robustness, security, and performance of the infrastructure, laying a solid foundation for the smooth operation of your applications and services.

Green Blocks :-

Structuring of Platform Engineering verticals is contingent upon the maturity level of the platform as a product. At different stages of development, certain tasks may be consolidated or divided to optimise efficiency.

Additionally, the alignment with business strategy plays a crucial role in determining the focus areas and distribution of responsibilities within these verticals

1. DevOps: This team focuses on deployment (CI/CD) efforts, managing the entire deployment lifecycle whether its for multi-cloud, hybrid with on-prem. They handle artifacts, versioning and source code management, automate processes, regular patching and aim to reduce deployment time while ensuring code is deployed securely and robustly.

2. Platform Developers: Responsible for developing the platform as a product, this team ensures to develop APIs for seamless interaction with platform components, following a NoOps approach. They builds key capabilities of platform such as authentication, scalability, traffic management, and cost efficiency. They address application-specific use cases, customise features for organisational needs, They establish deployment automation with abstraction of platform in a paved-road way for smooth platform experience

3. DataOps and Storage: Tasked with managing all data-related requirements, this team oversees various databases and storage solutions. They determine the best-suited options for each use case, whether on cloud or datacenters, and deliver data services through an API-first approach, enabling easy access for application developers.

4. FinOps: Comprising engineers and analysts, this team focuses on cloud cost optimisation. They work closely with the finance department to manage monthly cloud bills and drive cost efficiency across the organisation. They not only provide feedback to internal platform teams to develop cost-effective platform capabilities but also suggest application teams on adopting cost-efficient practices from the development itself.

5. MLOps: This team, consisting of platform engineers and machine learning scientists, collaborates to build MLOps solutions. Their aim is to streamline platform and application development efforts for various identified use cases, leveraging machine learning techniques and automation.

If the primary focus is on shifting security left, establishing a separate DevSecOps focus group would be ideal. This team would specialise in integrating security practices early in the development process

On other side, if the product aims to harness analytics capabilities and automate mundane work through automation or AI, leveraging MLOps would be advantageous.

In both scenarios, aligning the organisational structure depends on focus areas with the specific needs of the product and the journey where we ensures optimised resource allocation and efficient execution of strategic objectives.

Red Blocks

Here's a refined version of the various Site Reliability Engineering (SRE) verticals:

1. Reliability Engineering: This team ensures the resilience of the organization's solutions, products, and services from development to production. They focus on making applications fault-tolerant, highly available, and redundant, and they oversee all production activities in a step-by-step manner. Additionally, they implement, enforce, and audit Service Level Objectives (SLOs), Service Level Agreements (SLAs), and Error Budgets across the organization.

2. Observability: Responsible for enhancing visibility and reducing noise, this team sets up metrics, logging, and tracing capabilities using various tools. They provide observability solutions for application teams, Network Operation Center (NOC) teams, and Platform teams to better monitor and understand system behavior.

3. Application Domain and Performance SRE: Collaborating closely with application developers, this team ensures the reliability of applications and measures their performance under real-time traffic conditions. They also engage in Chaos Engineering practices to proactively identify and address weaknesses in application resilience.

4. Incident Management: This team handles the reporting of all incidents, conducts root cause analyses, and enforces SLOs. They facilitate business reviews, promote operational excellence, and align with Objectives and Key Results (OKRs) related to the platform's performance and reliability.

Orange Blocks

• Developer Productivity- This team focus on enhancing developer efficiency either by building or adopting tools which depict various insights and analytics tailored for your organisation needs, by measuring various developer efficiencies metrics mentioned in my last article

• Internal Developer Portal- Responsible for building and maintaining the internal developer portal, this team aims to create a centralized hub for all developers. The portal serves as a one-stop-shop, allowing developers to deploy applications, access metadata insights about deployments, find documentation for their queries, and visualise productivity tracking.

References or Good Read:
https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/tech-forward/why-your-it-organization-should-prioritize-developer-experience

https://www2.deloitte.com/uk/en/insights/focus/tech-trends.html#from-devops-to-devex

https://www.gartner.com/en/newsroom/press-releases/gartner-identifies-the-top-strategic-technology-trends-in-software-engineering-trends-for-2023

System thinking can be thought of a language, As a language it is specific way of viewing the world, it affect thoughts and thoughts in turn affects how we look at the world - Michael R Goodman

The increasing complexity of modern systems, especially in engineering, sometime underscores the importance of "System Thinkers". While the fact is, those individuals who possess a holistic understanding of the interconnected components and processes within a system can navigate any complexities effectively.

It's essential to learn, our understanding progresses through distinct stages

Reactive => Adaptive => Creative => Generative

i.e. reacting to challenges, to adapting to dynamic environments, to fostering creativity in problem-solving, and ultimately to generating innovative solutions proactively

The Solution-Neutral Approach

A solution-neutral approach in system thinking means delaying the selection to any particular alternatives (technology, platform, language or method) until a thorough understanding of the overall system's requirements and constraints is achieved.

Needs → Solution-Neutral Function → Concept → Architecture

For example, Take a Scenario, when you are going to buy a new car for yourself, Now with solution neutral approach, Take a step back for the said decision:-

Problem Identification:-
  Requirement: Transportation for office commute

Solution Exploration:-
  Public Transport: Buses, Trains, Taxis
  Private Transport: Car Pooling, Personal Vehicle (Car)

Attributes Evaluation:-
  Options Availability: Evaluate the availability of each   transportation option in your area.

  Commutation Time: Consider the time it takes to commute using each option

  Usage Frequency: Assess how often you need to commute and the flexibility required

  Cost Incurrence: Compare the costs associated with each option, including fares, fuel, maintenance, insurance, and parking

=> Hence here by applying a solution-neutral approach, one can make a well-informed decision that is aligned with specific needs while considering all available options and their attributes. This ensures that you choose the most effective solution and remove yourself being biased towards a particular choice

In the platform engineering world, the rapid emergence of new tools presents both opportunities and challenges. Here's how system thinkers should approach this dynamic environment

1. Identify Real Needs: System thinkers will deep dive into understanding of underlying problems and requirements before jumping to solutions. They distinguish between tools that genuinely address new challenges and those that merely reinvent existing solutions without significant value addition.

2. Evaluate Effectiveness: System thinkers adopt a critical mindset, identify attributes such as scalability, performance, security, ease of integration, and community support to determine whether a tool is fit for their specific use case and environment.

3. Avoid Over-Engineering: With tons of tools available, there's a risk of over-engineering solutions by incorporating unnecessary complexity. System thinkers prioritise simplicity opting for tools that offer the right balance of features and usability without introducing undue complexity.

4. Encourage Innovation: While being concern about new tools, system thinkers also embrace innovation and experimentation. They recognise that some of the most groundbreaking advancements come from unconventional tools or approaches and are open to exploring new ideas that have the potential to drive significant improvements.

5. Engage with Community: Engaging with broader community of practitioners and experts is integral to the approach of system thinkers. They actively participate in forums, conferences, and user groups to exchange ideas, share insights, and learn from each others' experiences, helping them stay informed about the latest tools and best practices.

References :

http://systemarchitect.mit.edu/docs/menshenin21a.pdf

https://thesystemsthinker.com/wp-content/uploads/2016/03/Systems-Thinking-Tools-TRST01E.pdf

Decide with Datum - simply means baseline or reference

" Comparison is a thief of Joy" -- Theodore Roosevelt

You might have heard the above quote already

Excessive comparison or constant comparison with others lead to feelings of inadequacy, envy, or discontentment, as Roosevelt's quote suggests

Although it's undeniable fact that comparison is indeed a natural tendency ingrained in human behaviour, and comparisons can be necessary and constructive in many situations, especially while making critical decisions.

Hence it's important though to strike a balance and approach comparison mindfully thats where the "DATUM" comes in play, this concept was previously used in multiple geometric framework studies

Now Lets go through some experiences to understand this concept further:-

Experience 1: "Sharing a performance review discussion between an engineer and leader (short excerpts) as an example of how DATUM can be leveraged"

Engineer: I am eager to discuss my contributions to Project X, which I drove from start to finish. Given the scope and responsibilities I have managed, I believe it reflects the caliber of work often associated with more senior roles. 
Could we explore the possibility of promotion of mine to a level two steps ahead?"

Leader: I appreciate your dedication and the impressive ownership you've taken with your project. It's evident you've tackled significant responsibilities and delivered results. 
However, let's learn more about career progression within our organisation also,
Have you had a chance to review the role charters (responsibilities) we have? That outlines the specific expectations and competencies for each level

Engineer: No, not yet. but I have been comparing my progress with peers in different teams, and some seem to have advanced quicker, and I also consider, my efforts are superior

Leader: Appreciate your ambition for career growth. Before we delve into potential advancement opportunities, I would suggest taking some time to evaluate how your performance aligns with the expectations of the role (DATUM) you aspire to. Once you feel confident that you meet those criteria, I'm more than happy to explore potential level opportunities within the organisation together

Engineer: Sure, I will explore it and plan a follow up meeting afterwards

Exploring data with datum of the engineer's performance and role, both leader and engineer can next engage in a more meaningful and evidence-based discussion about the promotion, ultimately increasing the likelihood of a successful outcome in the upcoming cycle.

Here is another relatable experience :-

Experience 2: Our team was discussing about defining OKRs (Objective Key results) and KPIs (Key performance indicators)

Team Member 1: As we're discussing defining our OKRs and KPIs for the upcoming quarter or year, one of our objectives is to improve X product capabilities by Y%.

Team Member 2: This sounds a solid objective, but how do we determine what percentage improvement is realistic and meaningful?

Team Member 3: We should start by establishing a baseline. What's the current percentage of capabilities for X product?

Team Member 1: "Good point. we need to know where we currently stand, we can compare it with industry standards or benchmarks. This is where DATUM comes in. We need to see how our product capabilities stack up against other similar apps and competitors."

Team Member 2: "Exactly. By comparing with DATUM, we can set a realistic target for improvement. It also helps us understand what's achievable and what might be stretching ourselves too thin."

Team Member 3: "That makes sense. Once we have a clear understanding of our current position and where we want to be based on DATUM, we can then define specific key results and actions to achieve our objective of improving X product capabilities by Y%."

In above conversation, by integrating DATUM into the discussion, the team ensures that their objectives are well-informed and aligned with industry benchmarks, increasing the likelihood of success in achieving their goals.

"Lastly, sharing here a foundational template for applying the DATUM framework in format of a Pugh decision matrix, enabling thorough comparison of multiple options."

Example, you are looking to buy a mobile-phone,

1. First list out reference or baseline features like camera, screen size, battery life you find important for your usage i.e. find your DATUM

2. Like its filled in Option A, Fill out other options B and D etc with different mobile phone features based on your DATUM,

3. You can also give a score for each criteria with a weightage multipliers to decide the best scoring option taking sum

Hence such decision matrix above provides a structured approach to take complex decisions in life with confidence, applicable to a variety of life choices, ranging from deciding to study abroad, evaluating job opportunities, to purchasing a car. By systematically assessing various criteria against available options, individuals can make informed decisions tailored to their preferences and priorities

Lastly

It's important to be mindful of how comparison affects our emotions and self-esteem, especially in the age of social media , and also we shouldn't discount the constructive role that comparison plays in guiding our decision-making process.

As long as we approach comparison with a balanced perspective and use it as a tool for informed choice rather than a source of unnecessary pressure or discontent, it can surely help us make the right decisions and progress towards our goals.

Metacognition The term metacognition literally means 'above cognition', and is used to indicate cognition about cognition, or more informally, thinking about thinking or thinking beyond

Metacognition involves being aware of how you think, learn, and solve problems. Essentially, metacognition encompasses the ability to reflect on and regulate cognitive processes to improve learning and problem-solving abilities.

By developing metacognitive skills, one can become more effective learner, critical thinker, and decision-maker.

Below are the various phase vise learning, leaders can adopt for reflection of their effective guidance and growth, Let me tell you about an experience from my journey about two years ago where practicing metacognition made a significant difference for me.

Planning - Leaders must consider

1. What is the objective for leading/driving a certain assignment task /program?

2. What prerequisites or prior knowledge does the team or I require?

3. What timelines are we aiming to achieve?

4. What are the metrics for success ?

Monitoring - Leaders should contemplate

1. Is the project or program progressing according to the identified milestones and metrics?

2. Do we need to address any obstacles or pivot towards alternative solutions and remedies?

3. Should we consider adjusting the scope or revising timelines in response to unforeseen challenges?

Evaluation - Leaders need to ponder

1. Have we attained the desired outcomes as measured by various metrics?

2. Does the solution adequately address all aspects of the problem, or are there lingering issues?

3. Can the lessons learned be shared and replicated across different programs?

4. What aspects of our strategy can be improved upon in retrospect?

So There was a discussion about our distributed team's assignments for upcoming year at an offsite.

I impulsively volunteered for 4 out of 6 programs, driven by my eagerness and energy. While there were 3 other leaders besides me in that call looking for workload distribution. However, upon reflection later on, I realised, this decision was influenced my own enthusiasm. I neglected to consider the workload distribution among my colleagues and the potential strain it could have on my work-life balance. 

Through introspection which now I know its called metacognition, I recognised the need for a more balanced approach. I learned to prioritise tasks based on capacity and take on sequentially, rather than taking on multiple responsibilities at once. 

This shift in mindset not only improved own well-being but also fostered a more collaborative and equitable team environment. 
By pacing myself and seeking input from others, I contributed more effectively to our team's success hence. 

References:

https://tll.mit.edu/teaching-resources/how-people-learn/metacognition/

https://nap.nationalacademies.org/catalog/9853/how-people-learn-brain-mind-experience-and-school-expanded-edition

https://cft.vanderbilt.edu/guides-sub-pages/metacognition/

Subscribe now

In every phase of life, and especially in leadership roles, the art of decision-making is not just a skill—it's a critical responsibility that defines our effectiveness and legacy.

KNOT is an acronym which encompasses below 4 key categories for information needed to have effective decision-making:-

1. Know (K): This refers to factual information about the situation which we learnt from verified articles, books, journals and research papers etc

2. Need to Know (NTK): Additional information which we have to gain for a sound decision, which might involve more research, practical, hands-on or other subject matter expertise opinions

3. Opinionated (O): This includes personal beliefs and perspectives that we have which may influence the decision. We need to recognise our own biases and also need to understand group of others offering opinions

4. Thoughts We think we Know (T): This covers assumptions or incomplete information that could be misleading as well. It's important to identify these gaps in your knowledge before making any decision

Let me illustrate with an example that reflects how this framework guided my approach recently:-

I received an invite for the upcoming meeting to decide the support rotation for our critical services, I applied the KNOT framework to ensure a thorough and effective decision-making process as described below:-

• Know- I conducted a thorough assessment of our current rotation setup, looked into both ongoing and historical data to gain an understanding of its performance. This involved analysing metrics such as Time to Resolve (TTR) to gauge our efficiency in handling issues. I validated my analysis with various reporting tools and factual data references we have, This analysis provided valuable insights into our capacity constraints and allowed me to make data-driven decisions to optimise our rotation strategy.

• Need to Know- To gain a in-depth understanding of our current rotation setup, I initiated a meeting with team members to hear their perspectives firsthand. I also solicited their input on potential solutions. Additionally, I reached out to our customers to gather feedback on any issues they were facing. Furthermore, I consulted with other organisational leaders, leveraging the expertise of those who have successfully running support setups. By engaging in these discussions and cross-referencing insights from multiple sources, I was able to gain deeper insights into the problem and develop informed strategies for improvement.

• Opinionated- It's essential to recognise and address bias and fallacies to ensure fair and effective decision-making. For example, assuming that one team member is an expert in resolving support issues may lead to overburdening them with support rotations, potentially resulting in burnout or diminished performance. However, considering alternative perspectives is crucial. Perhaps the subject matter expert (SME) himself is genuinely interested in contributing to support rotations to enhance product stability. Hence to validate this opinion, an open dialogue with the SME is imperative. With this, I had mitigated bias and made more informed decisions that benefit the team and organisation

• Thoughts We think we Know- In my experience, I've learned that no-one knows everything perfect, To overcome this, I've made it a priority to actively listen and remain open to diverse perspectives, especially during meetings with geogrhapically distributed team where lot of other factors comes into play like Timezone challenges, cultural, regulationsBy creating space for different viewpoints to emerge, we gain a deeper understanding of the issue at hand before jumping to conclusions. Additionally, I've cultivated a culture of openness to feedback and counterarguments within my team, encouraging thoughtful discussion and ensuring that our choices are grounded in sound reasoning

Platform engineering metrics are crucial for understanding the performance, reliability, and efficiency of a platform engineering function. They provide valuable insights into the health of the infrastructure, help identify areas for improvement, and enable informed decision-making,
Majorly in today’s dynamic landscape these metrics enable organisations to continuously improve their systems, mitigate risks, optimise resource allocation, plan for scalability, and align with overarching business objectives. In essence, they empower decision-makers to make informed choices that drive innovation, resilience, and growth within the organisation.

Gartner predicts that by 2026, 80% of software engineering organisations will establish “platform teams as internal providers of reusable services, components and tools for application delivery.”

What to Measure

For Platform Engineering, there are hundreds of metrics which can be classified broadly in below categories:-

1. Operational Excellence

2. Compliance

3. Production Readiness

4. Cost Efficiency

5. Developer Experience

1. Operational Excellence

DORA

DORA

DevOps Operation and Research Assessment backed by Google- These are research based metrics and provides standard framework to know about Operational and Organisation performances

Deployment frequency

How frequently changes are getting pushed into production

Change lead time

How long it takes for a commit to reach production

Change failure rate

How frequently a deployment introduces a failure which requires an immediate intervention

Failed Deployment Recovery Time

How long it takes to get recover from a failed deployment incident

MTTx

MTTD (Mean time to detect)- Time taken to detect the issue

This gives an idea about how good your observability is, how best alerting thresholds had been designed for quickly isolating issues

MTTR (Mean time to restore/resolve)- Time taken to restore the issue

This gives you context about your engineering efficiency, incident management process, Run-books presence and much more

There are multiple other MTTx metrics but I believe above two are most important

Support Metrics

Number of Support tickets Opened/Triaged/Closed based on Severity

Understand and classify all support issues over various severity hierarchy followed like
Critical→ Major→ Medium →Minor

Number of Tickets classified as Configuration bugs

This reflects and helps to identify and isolate what all changes goes in, how they went in production , was there a Change request, what all unit testing can improve

Number of Tickets which need feature development efforts

This gives you clarity of investing into your future roadmaps and hence capacity planning and also makes you aware of drift of your platform capabilities v/s the user requirements

Number of total incidents per week and their Revenue Impact

Identifying revenue impact is itself a bigger metrics for any organisation and this defines/redefines various business priorities , Need to have measurement of same with all impacting incidents to run RCA

2. Compliance

DevSecOps Security Metrics

Number of vulnerabilities per week based on priority

Run multiple Security scanning tools to identify and rank vulnerabilities

Vulnerabilities per layer

• Kernel vulnerabilities

• OS Based Vulnerabilities

• Container Based vulnerabilities

Vulnerability Patching Rate

Identify the patching cadence needed for your each environment and define efforts and capacity for same

Vulnerability breaching Age

Notify, Audit and monitor defects and ageing even though they are low in severity

Audit Compliance Metrics

PCI Audit Cycle and benchmarking

It is of paramount importance for the payment card industry data to get this audit done routinely to save revenue leakage/ avoid fraud and gain customers trust

SOX Audit Benchmarking

Sarbanes-Oxley Act also requires various organisation to audit their various practices/procedures for your data backup, change management, access control etc

Internal Audit Scoring

As your org prepare for above two, a shift left approach is needed to run an internal audit at various level for your platform configuration, to gain confidence before going for an external audit

3. Production Readiness Metrics

Reliability Score

Uptime

Basic metrics to measure availability of your tools/services, always take user perspectives in mind instead of computing each component uptime, collate and try to measure uptime for a specific service instead

SLO/SLI

Google Backed SRE principles fundamentally encourages to define SLOs i.e. service level objectives for each of your services identifying right SLI i.e. service level indicators

Error Budget

Identify the downtime which is acceptable for the services based on criticality of the services and aligned/agreed per your business domain, Create notification for those at various steps to monitor the expenditure of same with each incident

RCA Completion Rate

Blameless RCA are the strength of any system reliability, Action items coming out of RCA should be prioritised and there should be always capacity allotted to same, Hence RCA completion rate identified how many RCAs are successfully closed e2e with all Action items completed with in defined timeframe

Code Quality Score

Code Coverage

Not a difficult score to achieve as in current era lot of IDEs provides extension to achieve same, developers need to just adhere with same

Test Coverage

Test Coverage are important to have in order to achieve quality and stability in production, Corner cases, Fault injection, Unit testing, Integration testing all comes in consideration for same

Documentation

How well your documentation, run-books are drafted would be directly proportional to your engineering efficiency, again utilise Document as a Code functionality offered by various IDEs as a shift left approach

Observability

Monitoring Thresholds (Number of Alerts v/s Number of Issues)

Decluttering noise is equally important to have desired attention for incidents, Improve your alerting indicator regularly with increase in traffic, version upgrades and lot of routine changes

Number of Alerts categorised by Priority

Alerts classification helps in understanding need for urgent support or not, i.e. which alerts are eligible for Pagers, Segregation is important as well in measuring improvement rate for incident at each severity

Pagers schedule and Run-books

Pager rotation hygiene, Incident acknowledgements, Services coverage gives the clear picture of the support sanctity, Engineering team should own the process and drives it will fully

Utilisation

Throughput

Its a basic and much needed metrics for any system to run smooth with known boundaries, Perform PoCs, simulation traffic testing for all workloads before running in production in order to define their throughput with various parameters for eg running pods in burst mode needs a thorough testing, Throughput also helps in designing the step wise scaling in production

Scaling Capacity

Platform individual and shared components rightsizing should be known so that you can alert as it reaches x level of scaling and then horizontal, vertical scaling decisions can be taken up

At each layer , platform engineering should be aware of utilisation capacity whether its data storage, compute (clusters, nodes, pods, IPs)

Dimensioning should be publicised and advertised as a specification sheet of platform to make all users aware about it

4. Cloud Cost Efficiency Metrics

Cloud Cost Efficiency Score

Total Cloud cost expenses per week

Its an important business metrics to target, Already each cloud provider billing is visible with finance/FinOps team in cloud account consoles as well, lets define alerting/monitor for them for any abrupt hikes or downfalls

Migration/Introduction Cost

Any new tools/service introduction should have migration or introduction cost defined for ROI as well being architected /defined as a key criteria for Buy/Build approach or Move/Stay approach

Resource Provisioned v/s Resource Utilised

FinOps, Platform Engineering, cloud team whatever function your org has for this, Aiming for cloud cost optimisation has become an unsaid target for any business, Need to keep a close watch on how much actual resources are requested and how much are utilised by business

Decommissioning Save

Unused Cloud resources/platforms should be having retention policy in place to get auto cleaned up after certain time, Every test clusters, POC clusters are in scope for same which usually end up being stale

Chargeback and Attribution

Total Cloud Cost attributed to business

As part of Cost transparency platform engineering function should have core platform plugins cost attributed back to them only, Rest all cloud resources should get attributed back to the business domain it belongs to, this gives an accurate view of investment to all specific business units, Hence its useful to measure total Number of Apps getting chargeback and then their corresponding cumulative Cost to business

Tagging of Application and resources running over cloud

Tagging of each cloud resources not only helps in attribution but also in governance of said resources with their usability to specific business area and allocation percentages too

Forecast Rate

Business strategic decisions are empowered by roadmaps where predicting cloud cost helps in setting the correct expectation with the business growth expected, continuously comparison audit of this forecast should be done with actual expenditure to confirm alignments of Cost to business

5. Developer Experience Metrics

Onboarding Metrics

Time to onboard

Its the time taken by an engineer to understand the developer tools, pipelines and ran their deployment by pushing their first commit

Release Velocity

How frequent new product releases are happening i.e. from development phase to Production, this iterative metrics helps to know customer feature acceptance, reduces churn, this also throws light not only on development capabilities but also how smooth a DevOps pipeline is to facilitate releases

Product Market Fit

Developer Adoption Rate

While building platform as a product, we need to know usability rate of the features as well as complete platform as sometimes the users who are more loud tend to get their feature prioritised but we need to consider business priorities and ROIs to establish contextual and informed decision making in releasing features

Developer Engagement Rate

There has been a lot of say about Internal Developer Platform which talks about self service, accelerating developer productivity, not going in that much details as that had their own set of metrics like PRs, Review measurement etc but
here developer engagement simply means that utilities automation , tools you have invested in building developer experience , you need to see how much they are getting utilised in order to continue upgrade them to increase engagements so they did not end up unused or become a technical debt

CSAT Survey

Lastly a CSAT Score i.e. Customer satisfaction store is the biggest metric of above all,

It is beneficial to gauge customer needs, understand their biggest problems, It can be in both push and pull mode, ie Doing these surveys at a regular cadence or after bigger releases in push mode Or Opening a channel over slack, JIRA intake or your internal developer portal where user can give their feedback anytime they want, i.e. pull mode

Few Pitfalls to avoid

That means when everyone aims to mould/tries different ways just to achieve metrics target then accuracy of the metrics effectiveness will diminish

• There is no one metrics suits all, each organisation have unique use-cases and implementation strategies, so tailor it for your own, research and adapt accordingly

• Steer clear from unrealistic comparisons of metrics between various functions , Metrics provides context, unlike comparison wont serve value

• Resist the temptation to equate metrics with individual performance. Doing so will disturb credibility, overlooks the collaborative efforts that drive success

Subscribe now