Books

Made to Stick

Posted by Santh

Why do some ideas succeed while others fail?

We have come across several urban legends that resonate with people though they are unbelievable and false, while some of the most potent transformational ideas are not even considered. The traditional belief is that successful communication requires getting the right people and setting the right context. But there is another factor that is key for an idea to become viral – “The Stickiness Factor” as explained by Malcom Gladwell in The Tipping Point. This blog is about a different book Made to Stick by Chip and Dan Heath, which identifies the traits that make ideas sticky and provides a checklist for creating a SUCCESsful idea: a Simple Unexpected Concrete Credentialed Emotional Story.

Simple: Great simple ideas have an elegance and a utility that make them function a lot like proverbs: short sentences (Compact) drawn from long experience (Core). Simple = Core + Compact

  • Finding the core requires stripping down an idea to its most critical essence. To get to the core, we have start with weeding out the superfluous elements and eventually get down to the tougher part of eliminating ideas that may be really important but just aren’t the most important idea.
  • Creating a compact message is the next step once the core is identified. Compactness is all about elegance, prioritization and being crisp. It should not result in dumbing down or shooting for the lowest common denominator to make things easy. Techniques like “inverted pyramid” used by journalists to present information in descending order of importance and “forced prioritization” limiting to just one thing, are helpful.
  • A few examples of simple ideas that are compact while retaining the core idea:
    • SouthWest Airlines tagline: THE low-fare airline.
    • Bill Clinton’s 1992 campaign lead: It’s the economy, stupid.

Unexpected: The first problem of communication is getting people’s attention. The most basic way to get someone’s attention is by breaking a pattern as humans adapt incredibly quickly to consistent patterns. For example, we quickly get used to certain sounds like that of our air-conditioner or ceiling fan and certain smells like a room freshener or candle, that we become consciously aware of these things only when something changes. To get people’s attention and keep it, naturally sticky ideas provoke two essential emotions: Surprise and Interest.

  • Surprise gets our attention. Some naturally sticky ideas propose surprising “facts”. Like the statement “You use only 10% of your brain”.
  • Interest keeps our attention. Interesting ideas like conspiracy theories or gossips makes us keep tab on developments thereby maintaining our interest over time.
  • The Gap Theory of curiosity: Curiosity happens when we feel a gap in our knowledge and these gaps cause pain till they are filled. To leverage the gap theory, we sometimes have to set the context and give people enough backstory that they start to care about the gaps in their knowledge. Mystery novelists and crossword puzzle writers excel in this technique by setting some context and giving us clues that generate sufficient interest when curiosity takes over and propels us to finish!

Concrete: As we master a language, we use complex words and abstraction to make our point. When we deliver our beautiful abstract message, listeners admire our mastery over language and extensive vocabulary. However, abstraction makes it difficult to understand an idea and remember it. It also makes it harder to coordinate our activities with others, who may interpret the abstraction in different ways. Concreteness helps us avoid these problems:

  • Concrete is memorable: When we are asked to remember how a beach feels, our sense memories are immediately evoked bringing back memories of the sight of sand and waves, smell of the ocean, sea breeze blowing across our face, etc. For a person who has not seen a beach at all, it is only the textbook definition of beach that comes to mind at best and cannot relate to it as well.
  • Concrete allows coordination: Abstract statements can mean different things for different people. For example, a goal to manufacture “the best car” will mean top speed for a race driver while it will mean comfort and space for a person looking to drive his family of four for a picnic. So, making it concrete with tangible aspects like “the car that can comfortably accommodate a family of four along with ample space to carry picnic bags” will help effectively coordinate within a team and reduce scope for different interpretations.

Credible: People’s beliefs are based on years of trust built in family, personal experience, faith and authorities. However, we can’t always rely on these factors to vouch for our message. Most of the time our messages have to vouch for themselves and must have “internal credibility”, which can be obtained from three sources:

  1. Details: A person’s knowledge of details is often a good proxy for expertise. Vivid details shared along with the message will increase the credibility of the idea.
  2. Statistics are a good source of internal credibility when they are used to illustrate relationships. Using “human-scale principle” will make statistics more effective and allows people to bring their intuition to bear in assessing whether the content of the message is credible.
  3. The Sinatra Test: In Frank Sinatra’s classic “New York, New York”, he sings about starting a new life at New York City and the chorus declares, “If I can make it there, I will make it anywhere”. An example passes the Sinatra test when just that instance is enough to establish credibility in a given domain. For example, if you have driven on Indian roads, you can drive anywhere.

Emotional: Accidental mutation of human brain thousands of years back led to cognitive revolution resulting in agricultural, scientific and industrial revolutions through analytical thinking that set us apart from other animals. However, most of our actions are still driven by primitive emotions or feelings invoked by an event. As we prepare to communicate our idea, it will help to remember that using statistics or science to make our point shifts people into a more analytical frame of mind. When people think analytically, they are less likely to think emotionally that makes them care for something. There are three strategies for making people care:

  1. Using associations (or avoiding them as the case may be): Piggybacking strategy associating ideas with emotions that already exist.
  2. Appealing to self-interest: Highlighting what is in it for oneself is a powerful way of engaging people with an idea.
  3. Appealing to identity: In some cases, going beyond self-interest and appealing to an identity that people care about will be impactful.

Stories: There are numerous books highlighting why stories are the most effective means of communicating messages at work and I have a blogpost on one of them. “Made to stick” highlights that stories cause mental simulation that evokes the same modules of the brain that are evoked in real physical activity. So, while mental simulation is not as good as doing something, it is the next best thing. There are three basic plots that can be used to make our ideas stick:

  1. The Challenge Plot: Obstacles seem daunting to the protagonist and the triumph of will power over adversity inspires us to act.
  2. The Connection Plot: These are about our relationships with other people and will be a good way to build relationships.
  3. The Creativity Plot: Involves someone making a mental breakthrough, solving a long standing puzzle or attacking a problem in an innovative way.

To summarize, for an idea to stick and be useful for a long time, it has to make the audience:

  1. Pay attention
  2. Understand and remember it
  3. Agree / Believe
  4. Care
  5. Be able to act on it

Sway

Posted by Santh

Can you remember instances when you decided to pursue a course of action that went against your professional training?

Have you wondered why leaders at times make silly mistakes by ignoring the obvious?

The question when we look back at such incidents invariably is: How can a professional with such established reputation and years of experience do this?

Leaders have to make decisions all the time based on available data and with no guarantee of success. Though they typically have the best interests of their organization in mind, sometimes things do go wrong and posterity can attribute at least some of the failures to past “irrational” decisions. It is usually easy for people to provide elaborate commentary on poor results with hindsight bias. Does this mean all leaders are doomed to be criticized in the future? Brafman Ori’s book “Sway: The Irresistible Pull of Irrational Behaviour” can help leaders deal with this occupational hazard during decision making by being aware of potential pitfalls due to certain psychological undercurrents: loss-aversion, swamp-of-commitment, value-attribution, diagnosis-bias, self-perpetuation, fairness-of-process and group-conformity.

The first time I came across the concept of irrational behavior was in the Dan Ariely’s book “Predictably Irrational” several years back. It was before I started blogging and when I was still reading non-fiction for fun rather than leadership insights. Brafman Ori has taken it to the next level by explaining the reasons behind these irrational behaviors and also shares some practices that can help us avoid falling into the trap.

History is filled with numerous instances of top-notch, award-winning professionals making a choice that contradicted their years of training resulting in disastrous outcomes as they swayed from the logical path. This book explores some of the psychological forces that derail rational thinking: how they creep upon us, when are we most vulnerable to them and why don’t we realize that we are getting swayed. By better understanding the seductive pull of these forces, we will be less likely to fall victim to them in the future.

Loss Aversion – tendency to go to great lengths to avoid potential losses: Human mind naturally experiences the pain associated with a loss much more vividly than it does the joy of experiencing a gain. This results in our overreacting to perceived losses for no apparent logical reason. The more meaningful a potential loss is, the more loss averse we become and get swept into an irrational decision. Some examples of this behavior are people subscribing to expensive “unlimited” phone or internet plans to avoid perceived loss associated with pay-as-you-go, investors in financial markets concentrating on avoiding losses rather than focusing on maximizing their gains, etc.

Swamp of Commitment – hanging on to a strategy even if the chances of success are small and the cost of delaying failure is high: History is filled with stories of civilizations and companies vanishing by sticking to a committed path even after realizing the need to change. It is also what leads a gambler or investor to chasing losses. Loss aversion and commitment have powerful effect on their own. But when they both combine, it becomes that much harder to break free and do something different.

Value Attribution – inclination to imbue a person or thing with certain qualities based on initial perceived value: From our childhood, we form perceptions about value. For example – premium branded products are preferred over regular ones even if packaging is all that is different, a lawyer is trusted more when he shows up wearing a fancy suit. We have mental models of how a top investment banker or computer geek or a seasoned politician will look like. Anyone who does not fit the stereotype finds it difficult to gain acceptance.

Diagnosis Bias – blindness to all evidence that contradicts our initial assessment of a person or situation: The proverb “The first impression is the best impression” is based on this psychological undercurrent. After all, the first impression might have occurred under exceptionally fortunate or unfortunate circumstances.

Self perpetuation – taking on characteristics assigned by diagnosis thereby reinforcing it: This is also called self-fulfilling prophecy or chameleon effect. When we brand or label people, they take on the characteristics of the diagnosis. It is also called Pygmalion effect when a positive trait is assumed and Golem effect in case of negative traits.

Fairness – its the process and not the outcome that causes irrational behavior: We expect procedural justice from people we deal with, which is perceived fairness of the process rather than just a fair outcome. For example, we consider a car salesman to be fair when he explains the reasons why the original price is worth every penny rather than another who gives an easy 10% discount without spending any effort to explain why this is the best possible deal. In the second case, we leave with the question of why only 10%, did the salesman really give me the best deal or did I overpay? To avoid this fairness dilemma, managers are asked to put greater effort, energy, investment and patience into nurturing relationships.

Group conformity – propensity to go along with the group and save the embarrassment of being odd person out: Regardless of how independent minded and steadfast people are, it is common for people to align with a group instead of voicing an unpopular viewpoint due to fear that others will doubt their intelligence, taste or competence. For a decision to be made by comprehensively considering all possibilities, it is important for the discussion to include initiators, blockers, supporters and observers. It might be frustrating to encounter blockers for what might appear to be an obvious course of action, but their opinions are absolutely essential to keeping groups balanced and hold back irrational behavior.

If this book were a movie, the first 90% is an intriguing build-up and the Epilogue is a fitting fast-paced climax where Brafman Ori gives us some invaluable suggestions on ways to avoid these pitfalls, some of them below:

  • Our natural tendency to avoid the pain of loss is most likely to distort our thinking when we place too much importance on short-term goals. When we adopt the long view, immediate potential losses don’t seem as menacing.
  • When we find ourselves unsure about whether or not to continue a particular approach, it is useful to ask – “If I were just arriving on the scene and were given the choice to either jump into this project as it stands now or pass on it, would I choose to jump in?” If the answer is no, then chances are we have been swayed by the hidden force of commitment.
  • The best strategy for dealing with the distorted thinking that can result from value attribution is to be mindful and observe things for what they are, not just for what they appear to be. You have to be prepared to accept that your initial impressions might be wrong.
  • “Propositional thinking” is all about keeping evaluations tentative instead of certain, learning to be comfortable with complex, sometimes contradictory information and taking your time and considering things from different angles before coming to a conclusion. Net-net, a self-imposed waiting period before making a diagnostic judgment can help avoid diagnostic bias.
  • One way to counter fairness sway is to try to weigh things objectively and not succumb to emotional maneuvers or moral judgments.
  • When we make decisions or take actions that will affect others, keeping them involved will help ensure that they feel the process is fair.
  • Just as communicating our process is important, so is giving voice to the dissenter. In group situations, the presence of a blocker can actually make the decision making process more rational and less likely to go off the track.

The ability to think has set humans apart from other animals and become all-conquering species. At the same time, our natural decision making machinery has limitations that leads us to being swayed at times by factors that have nothing to do with logic or reason. This book will help us recognize and understand the hidden world of sways, and learn to weaken their influence on our thinking process.

Stories at Work

Posted by Santh

After reading a few heavy technology books since the beginning of 2021, I was looking for a relatively light read and that’s when my senior leader recommended “Stories at Work” by Indranil Chakraborthy. With a recommendation from such an accomplished orator and fantastic storyteller, I bought the book immediately to check on the techniques to benefit from. Being an engineer who takes pride in analytical approach to solve problems, I considered myself to be good at articulating facts and data points. And by false dichotomy, assumed that I cannot be a good storyteller. Indranil broke this myth with the following definition of stories in business and set the tone for some awesome insights!

A story is a fact wrapped in context and delivered with emotion

I usually start any new learning with understanding “Why” it is required. In this case I remembered Yuval Noah Harari’s Sapiens referring to human’s ability to tell stories as a key result of Cognitive Revolution that led to advancement of our societies. In addition, Indranil Chakraborthy provides six compelling reasons why stories are profoundly relevant:

  1. Evolutionary predisposition: Biologists confirm that human brain is predisposed to think in story terms and explain things in story structures. Our brain converts raw experience into story form and then considers, ponders, remembers and acts on a self-created story, not the actual input experience. So, the next time someone nods vigorously indicating understanding of your speech but says something completely different when asked to paraphrase, blame the human brain at work!
  2. Childhood story exposure: We have been telling children stories to teach them values, behavior and build their knowledge. This exposure to stories through the key years of development results in adults who are irrevocably hardwired to think in story terms.
  3. Chemical post-it notes: Daniel Goleman’s “Emotional Intelligence” covers this topic in detail – in essence, emotionally intense events are permanently registered in our emotional brain (amygdala) by neuro-chemicals for super-fast retrieval whenever similar events take place in future.
  4. Neural coupling: When a story is told and it has meaning, brain patterns of the speaker and the listener synch. This can be used to ensure listeners fully comprehend what one wants to convey.
  5. Monkey see, monkey feel: When someone describes pain they went through, we feel the same way. This is due to mirror neurons that are fired up in the minds of both the listener and the storyteller.
  6. Data brain, story brain: Stories impact more areas of our brain than data does and hence stories involve us much more. This increases the likelihood of us taking action when we hear stories and not just data.

To summarize why stories are a powerful way to communicate our message – In this world of increasing noise and clutter, an ability to find an expressway to the listeners’ minds can be the most powerful skill in a leader’s repertoire. Stories can be this expressway if laid out appropriately!

Now that we understand “Why” stories are important in business, the book explores “What” are the four situations where we can start our storytelling journey:

  1. Using stories to build rapport and credibility: When we meet a person or a group for the time, we start with an introduction that is usually filled with our credentials that we expect to build trust. While credentials are an indirect pointer to our character, we can be more effective in building trust by sharing anecdotes from our life. Indranil calls them “connection stories” that can help our listeners appreciate our values and result in forming a bond through shared values and beliefs. He also provides a step by step process to create and fine-tune connection stories:
    • Before meeting a new group of people, write down five words or phrases abut your character, values or beliefs that you would like your listener to infer about you.
    • Recollect and jot down an incident from your life where you have displayed many of these character traits.
    • Narrate the incident to someone you trust and write down what they inferred about you from it.
    • Based on the feedback, chisel down the story to just about a minute or less.
    • Tell the story to two other people that will automatically help you refine it further.
    • Retell the story to yourself, starting with the character trait you want your audience to take away.
    • Finally, record your story, transcribe it and fine-tune further by brutally eliminating the words that are unnecessary.
  2. Using stories to influence and overcome objections: When people have a strong belief on an illogical idea, it is usually based on some personal experience or story. Using data or logic to debate against such belief will be futile. The only way to convince people to change under such scenario is to replace it with a more powerful story, which is called “influence story“. An influence story has to be introduced carefully, using the following steps:
    1. Acknowledge the anti-story: Empathize with the listener’s story and express understanding of reasons behind prevailing belief.
    2. Share the story of the opposite point of view: This is the step to replace with a more powerful story, will be ideal if it can be corroborated.
    3. Make the case: Without offending the listener’s views, explain the need for a change.
    4. Make the point: Finally call for action, maybe to experiment with the change first and see the results for oneself.
  3. Getting strategies to stick: Organizations come up with well-thought vision and value statements but many a times they don’t stick across the organization due to three key reasons – abstraction of language, absence of context or the curse of knowledge. To address these challenges, “clarity stories” using simple English with the following structure are used:
    1. In the past: Articulate how we succeeded in the past using strategy relevant at that time.
    2. Then something happened: Highlight the changes caused by both external and internal factors that have rendered the past strategy irrelevant.
    3. So now: Introduce the new strategy that needs to be adopted to succeed in current reality.
    4. In the future: Explain your vision on how this new strategy will create new opportunities and success in future.
  4. Using stories to share best practices, knowledge or success: Just like we tend to focus on credentials while introducing ourselves, the focus while articulating success or best practices tends to be data points or statistics. Given humans are predisposed to assimilate stories better, the suggestion here is to turn them into “success stories”. Narrate the success as stories placing human characters appropriately for effective reach and impact.

After covering “Why” and “What”, the book goes on to cover “How” to put them together for different business scenarios. I would recommend reading the book for this section (and the previous ones as well for comprehensive understanding).

To summarize, the combination of four story patterns – connection stories, influence stories, clarity stories and success stories – will make external and internal communication more effective and transform an organization. Happy story-telling!

SRE – Management

Posted by Santh

We covered the motivation behind SRE in the first blogpost of this series, followed by Principles and Practices. Lets complete the foundation with Google’s guidance on how to get SREs working together in a team and working as teams. To ensure SRE approach sticks without the team slipping back to old ways, the new ways of working covered in this blogpost should be incorporated in a structured manner along with the team and the management committing to adhere to them at all costs.

Accelerating SREs to On-Call and Beyond: Educating new SREs on concepts and practices up front will shape them into better engineers and make their skills more robust.

  • Initial Learning Experiences – The Case for Structure Over Chaos: SRE must handle a mix of proactive (engineering) and reactive (on-call) work while traditional Operations teams are predominantly reactive. To position the team for success with proactive work, structured knowledge build-up of the system is essential. Some techniques for getting there:
    • Learning Paths That Are Cumulative and Orderly – Show the new SRE team an orderly path that will infuse confidence that there is a plan to mastery of the system through a combination of education, exposure and experience.
    • Targeted Project Work, Not Menial Work – Make the initial weeks effective by giving the engineers project work that can reinforce their learning.
  • Creating Stellar Reverse Engineers and Improvisational Thinkers: SREs will continue to encounter systems with design patterns that they have not seen before. They need strong reverse engineering skills along with ability to think statistically and improvise fully to untangle without avoid getting stuck.
  • Best Practices for Aspiring On-Callers: For engineers who typically prefer creating new tech solutions, being on-call to troubleshoot production issues can be made interesting with the following practices:
    1. A Hunger for Failure: Reading and Sharing Postmortems
    2. Disaster Role Playing (regular team exercises for new joiners to enact responding to pages)
    3. Break Real Things, Fix Real Things (by simulating volumes or issues in non-critical lower environments)
    4. Documentation as Apprenticeship (by overhauling outdated knowledge base)
    5. Shadow On-Call Early and Often
  • On-Call and Beyond – Rites of Passage and Practicing Continuing Education: Once the engineer has demonstrated ability to handle issues independently, it is time to be formally added to on-call rota and celebrate this milestone as a team. It is important to setup a regular learning series that helps the entire team stay in touch with changes.

Dealing with interrupts: Once the SRE team is in-charge of handling operations, “Managing Operational Load” is the next topic to focus on. Operational Load is the work that must be done to maintain the system in a functional state, and this will interrupt the SRE team working on any other planned project work. So, the objective is to handle such interruptions without distracting the engineers from their cognitive flow state. The interrupts fall into three general categories:

  • Pages concern production alerts and are triggered in response to production emergencies. They are commonly handled by a primary on-call engineer, who is focused solely on on-call work. A person should never be expected to be on-call and also make progress on projects or anything else with a high context switching cost. A secondary on-call engineer provides back-up in case of contingencies.
  • Tickets concern customer requests that require the team to take an action. The primary or secondary on-call engineer can work on tickets when there are no pages to handle. Depending on the nature and priority of tickets, a dedicated person might also be assigned to work on tickets.
  • Ongoing operational responsibilities include activities like team-owned code or flag rollouts, or responses to ad-hoc, time-sensitive questions from customers. An approach similar to handling tickets can be adopted.

Embedding a SRE to Recover from Operational Overload: A burdensome amount of ops work for a prolonged period will be dangerous because the SRE team might burn out or be unable to make progress on project work. One way to relieve this burden is to temporarily transfer a SRE into the overloaded team. Google’s guidance to the SRE who will be embedded on a team:

  • Phase 1: Learn the Service and Get Context – Remind the team that more tickets should not require more SREs and emphasize on healthy work habits that reduce the time spent on tickets. Some of the healthy habits are focusing on non-linear scaling of services, identifying sources of inordinate amount of stress, and identifying emergencies waiting to happen.
  • Phase 2: Sharing Context – After identifying pain points, suggest improvements and demonstrate better ways to work. Some examples are writing a good postmortem for the team or identifying root cause for frequent issues and suggesting solutions.
  • Phase 3: Driving Change – Nudge the team with ideas based on SRE principles and help them self-regulate. This can be done by helping the team fix any basic issues (like defining SLO), coaching team members to address issues in a permanent way or asking leading questions.

Communication and Collaboration in SRE: There is tremendous diversity in SRE teams as it includes people with various skills such as systems engineering, software engineering, project management, etc. Also, given the nature of responsibilities handled by SRE, team members tend to be more distributed across geographical regions and time zones when compared to product development. Considering these aspects, communication and collaboration among SRE teams and across other teams should be designed to address the joint concerns of production and the product in an atmosphere of mutual respect. There should be forums (like weekly Production Meetings) for the SRE team to articulate the state of the system they support and highlight improvement opportunities to Product Development.

The Evolving SRE Engagement Model: The focus so far has been on onboarding SRE support for a product or service that is already in production. While this “classic” engagement model is commonly a good starting point, there are two other models that are better at embedding SRE principles and practices earlier during development lifecycle. Let’s looks at all the three models, starting with the classic one.

  • Simple PRR (Classic) Model: When SRE receives a request for taking over production management, SRE gauges both the importance of the product and the availability of SRE teams. The SRE and development teams then agree on staffing levels to facilitate this support followed by a Production Readiness Review (PPR). Once the gaps and improvements identified from the review are addressed, SRE team assumes its production responsibilities.
  • Early Engagement Model: SRE participates in Design and later phases, eventually taking over the service any time during or after the build phase.
  • Evolving Services Development – Frameworks and SRE Platform: As the industry moves towards microservices architecture, the number of requests for SRE support and the cardinality of services to support will increase. To effectively address the increased demand, all microservices should adopt structured frameworks for production services. These frameworks include codified SRE best practices that are “production ready” by design and reusable solutions to mitigate scalability and reliability issues. A production platform built on top of such frameworks with stronger conventions reduces operational overhead.

These five ways to work should help establish and reinforce SRE teams in an organization. And with this, we come to the end of SRE overview series. I strongly recommend reading Google’s book to get a comprehensive understanding of SRE. As the industry moves further towards microservices and cloud, traditional support model that is predominantly based on manual operations will not be scalable and sustainable. The sooner organizations embark on pivoting towards an engineering-oriented support model with necessary investments in technology and people, the better for products and services they provide.

SRE – Practices

Posted by Santh

After covering the motivation behind SRE along with the responsibilities and principles in previous blogposts, this one will focus on “how” to get there by leveraging SRE practices used by Google. The book explains 18 practices and I strongly recommend reading the book to thoroughly understand them. I have provided a brief summary of the most common and relevant practices here.

The book has characterized the health of the service similar to Maslow’s hierarchy of human needs, with basic needs at the bottom (starting with Monitoring) and goes up all the way to taking proactive control of the product ‘s future rather than reactively fighting fires. All the practices fall under one of these categories.

Monitoring: Any software service cannot sustain in the long term if customers usually come to know of problems before the service provider. To avoid this situation of flying blind, monitoring has always been an essential part of supporting a service. Many organizations have L1 Service Desk teams that either manually perform runbook based checks or visually monitor dashboards (ITRS, App Dynamics, etc.) looking for any service turning “red”. Both these approaches involve manual activity, which make monitoring less effective and inefficient. Google being a tech savvy organization, always had automated monitoring through custom scripts that check responses and alert.

  • Practical Alerting from Time-Series Data: As Google’s monitoring systems evolved using SRE, they transformed to a new paradigm that made the collection of time-series a first-class role of the monitoring system, and replaced those check scripts with a rich language for manipulating time-series into charts and alerts. Open source tools like Prometheus, Riemann, Heka and Bosun allow any organization to adopt this approach. For organizations still relying heavily on L1 Service Desks, a good starting point will be to use a combination of white-box and black-box monitoring along with a production health dashboard and optimum alerting to eliminate the need for manual operations that only scales linearly.

Incident Response: Incidents that disrupt a software service dependent on numerous interconnected components is inevitable. SRE approaches these incidents as an opportunity to learn and remain in touch with how distributed computing systems actually work. While Incident Response and Incident Management are used interchangeably at some places, I consider Incident Response that includes technical analysis and recovery to be the primary responsibility of SRE team, whereas Incident Management deals with communication with stakeholders and pulling the who response together. Google has also called out Managing Incidents as one of the four practices under Incident Response:

  • Being On-Call is a critical duty for SRE team to keep their services reliable and available. At the same time, balanced on-call is essential to foster a sustainable and manageable work environment for the SRE team. The balance should ensure there is no operational overload or underload. Operational overload will make it difficult for the SRE team to spend at least 50% of their time on engineering activities leading to technology debt and inefficient manual workarounds creeping into support process. Operational underload can result in SREs going out of touch with production creating knowledge gaps that can be disastrous when an incident occurs. On-call approach should enable engineering work as the primary means to scale production responsibilities and maintain high reliability and availability despite the increasing complexity and number of systems and services for which SREs are responsible.
  • Effective Troubleshooting: Troubleshooting is a skill similar to riding a bike or driving a stick-shift car, something that becomes easy once you internalize the process and program your memory to subconsciously take necessary action. In addition to acquiring generic troubleshooting skill, solid knowledge of the system is essential for a SRE to be effective during incidents. Building observability into each component from the ground up and designing systems with well-understood interfaces between components will make troubleshooting easier. Adopting a systematic approach to troubleshooting (like Triage -> Examine -> Diagnose -> Test / Treat cycle) instead of relying on luck or experience will yield good results and better experience for all stakeholders.
  • Emergency Response: “Don’t panic” is the mantra to remember during system failures to be able to recover effectively. And to be able to act without panic, training to handle such situations is absolutely essential. Test-Induced emergency helps SRE proactively prepare for such eventualities, make changes to fix the underlying problems and also identify other weaknesses before they became outages. In real life, emergencies are usually change-induced or process induced and SREs learn from all outages. They also document the failure modes for other teams to learn how to better troubleshoot and fortify their systems against similar outages.
  • Managing Incidents: Most organizations already have an ITIL based Incident management process in place. SRE team strengthens this process by focusing on reducing mean time to recovery and providing staff a less stressful way to work on emergent problems. The features that can help achieve this are recursive separation of responsibilities, a recognized command post, live incident state document and clear handoff.

Postmortem and Root Cause Analysis: SRE philosophy aims to manually solve only new and exciting problems in production unlike some of the traditional operations-focused environments that end up fixing the same issue over and over.

  • Postmortem Culture of Learning from Failure has primary goals of ensuring that the incident is documented, all contributing root causes are well understood and effective preventive actions are put in place to reduce the likelihood and impact of recurrence. As the postmortem process involves inherent cost in terms of time and effort, well defined triggers like incident severity is used to ensure root cause analysis is done for appropriate events. Blameless postmortems are a tenet of SRE culture.

Testing: The previous practices help handle problems when they arise but preventing such problems from occurring in the first place should be the norm.

  • Testing for Reliability is the practice that helps adapting classical software testing techniques to systems at scale and improve reliability. Traditional tests during software development stage like unit testing, integration testing and system testing (smoke, performance, regression, etc.) help ensure correct behavior of the system before it is deployed into production. Production tests like stress / canary / configuration tests are similar to black-box monitoring that help proactively identify problems before users encounter them and also help staggered rollouts that limits any impacts in production.

Capacity Planning: Modern distributed systems built using component architecture are designed to scale on demand and rely heavily on diligent capacity planning to achieve it. The following four practices are key:

  • Load balancing at the Frontend: DNS is still the simplest and most effective way to balance load before the user’s connection even starts but has limitations. So, the initial level of DNS load balancing should be followed by a level that takes advantage of virtual IP addresses.
  • Load balancing in the data center: Once the request arrives at the data center, the next step is to identify the right algorithms for distributing work within a given datacenter for a stream of queries. Load balancing policies can be very simple and not take into account any information about the state of the backends (e.g., Round Robin) or can act with more information about the backends (e.g., Least-Loaded Round Robin or Weighted Round Robin).
  • Handling Overload: Load balancing policies are expected to prevent overload but there are times when the best plans fail. In addition to data center load balancing, per-customer limits and client-side throttling will help spread load over tasks in a datacenter relatively evenly. Despite all precautions, when backend is overloaded, it need not turn down and stop accepting all traffic. Instead, it can continue accepting as much traffic as possible, but to only accept that load as capacity frees up.
  • Addressing cascading failures: A cascading failure is one that grows over time as a result of positive feedback. It can occur when a portion of an overall system fails, increasing the probability that other portions of the system fail. Increasing resources, restarting servers, dropping traffic, eliminating non-critical load, eliminating bad traffic are some of the immediate steps that can address cascading failures.

Development: All the practices covered so far deal with handling reliability after software development is complete. Google recommends significant large-scale system design and software engineering work within the organization to enable SRE through following practices:

  • Managing Critical State – Distributed Consensus for Reliability: CAP Theorem provides the guiding principle to determine the properties that are most critical. When dealing with distributed software systems, we are interested in asynchronous distributed consensus, which applies to environments with potentially unbounded delays in message passing. Distributed consensus algorithms allow a set of nodes to agree on a value once but don’t map well to real design tasks. Distributed consensus adds higher-level system components such as datastores, configuration stores, queues, locking, and leader election services to provide the practical system functionality that distributed consensus algorithms don’t address. Using higher-level components reduces complexity for system designers. It also allows underlying distributed consensus algorithms to be changed if necessary in response to changes in the environment in which the system runs or changes in nonfunctional requirements.
  • Distributed Periodic Scheduling with Cron, Data Processing Pipelines and ensuring Data Integrity: What You Read Is What You Wrote are other practices during Development.

Product is at the top of the pyramid for any organization. Organizations will benefit by practicing Reliable Product Launches at Scale using Launch Coordination Engineering role to setup a solid launch process with launch checklist.

These practices shared by Google provide a comprehensive framework to adopt across software development lifecycle to improve reliability, resilience and stability of systems.

SRE – Principles

Posted by Santh

After a quick introduction to SRE in the previous blogpost, lets step into the principles as shared by Google in their book. Wikipedia defines Reliability as the probability that a system will produce correct outputs up to some given time “t”. Reliability is enhanced by features that help to avoid, detect and repair hardware faults. A reliable system does not silently continue and deliver results that include corrupted data. Instead, it detects and, if possible, corrects the corruption. Reliability can be characterized in terms of mean time between failures (MTBF), with reliability = exp(-t/MTBF).

While getting reliability to 100% appears to be ideal, there is cost involved. SRE outlines the following principles that can help achieve desired reliability level by balancing resiliency with cost. This blogpost will briefly cover each principle and help us appreciate SRE practices that will be covered next.

  1. Embracing Risk
  2. Service Level Objectives
  3. Eliminating Toil
  4. Monitoring Systems
  5. Release Engineering
  6. Simplicity

Embracing Risk:
SRE seeks to balance the risk of unavailability with the goals of rapid innovation and efficient service operations, so that users’ overall happiness – with features, service, and performance – is optimized. Efforts to increase reliability beyond a certain point will exponentially increase recurring costs making it economically worse for a service and its users. Cost of improving reliability can be categorized into two buckets, both of them are invisible to end users but essential to avoid disruptions rather than building new features:

  1. The cost of redundant machine / compute resources.
  2. The opportunity cost when engineers are allocated to improve reliability.

In SRE, service reliability is managed by managing risk. The goal is to explicitly align the risk taken by a given service with the risk the business is willing to bear and strive to make a service reliable enough, but no more reliable than it needs to be. To achieve this, a set of Service Level Objectives need to be defined and this will be covered in the next principle.
Before that, another key concept is Error Budgets. As we embrace risk this way, tensions will arise between Product Development and SRE teams as they are usually evaluated on different metrics. An error budget aligns incentives and emphasizes joint ownership between SRE and product development. Error budgets make it easier to decide the rate of releases and to effectively defuse discussions about outages with stakeholders, and allows multiple teams to reach the same conclusion about production risk without rancor.

Service Level Objectives:
To manage a service, we first need to express its important behaviors quantitatively and then define the level of service that will be delivered. Three important terminologies that help achieve this are:

  1. Service Level Indicator (SLI): a carefully defined quantitative measure of some aspect of the level of service that is provided. Examples – request latency, error rate, system throughput, availability, durability.
  2. Service Level Objective (SLO): a target value or range of values for a service level that is measured by an SLI. Example – 99% of Get RPC calls will complete in less than 100 ms.
  3. Service Level Agreement (SLA): an explicit or implicit contract with your users that includes consequences of meeting (or missing) the SLOs they contain. SLAs usually have financial implication for violating SLO.

Eliminating Toil:
Toil is the kind of work tied to running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows. SRE’s goal is to eliminate toil so that they can spend time on long-term engineering project work. Typically 50% of each SRE’s time should be spent on engineering project work that will either reduce future toil or add service features.

Monitoring Systems:
Monitoring includes collecting, processing, aggregating and displaying real-time quantitative data about a system, such as query counts and types, error counts and types, processing times and server lifetimes. Effective monitoring helps proactively avoid failures and involves alerting, building dashboards, analyzing long term trends and root cause analysis. Monitoring can either be:
· White-box that is based on metrics exposed by the internals of the system, including logs, interfaces like JVM Profiling Interface or an HTTP handler that emits internal statistics.
· Black-box that involves testing externally visible behavior as a user would see it.

Release Engineering:
When equipped with the right tools, proper automation, and well-defined policies, developers and SREs shouldn’t have to worry about releasing software. Releases can be as painless as simply pressing a button and Release Engineers help achieve this using devops pipeline that includes source code repository, build rules for compilation, configuration management, test integration, packaging and deployment.
Release engineering is guided by an engineering and service philosophy that’s expressed through four major principles:

  1. Self-Service Model: Tools and process that allows product development teams to control and run their own release processes and achieve high release velocity.
  2. High velocity: Frequent releases that result in fewer changes between versions.
  3. Hermetic Builds: Self-contained builds that must not rely on services that are external to the build environment.
  4. Enforcement of Policies and Procedures

Simplicity:
Software simplicity is a prerequisite to reliability. With an eye towards minimizing accidental complexity, SRE teams should:
· Push back when accidental complexity is introduced into the systems for which they are responsible.
· Constantly strive to eliminate complexity in systems they onboard and for which they assume operational responsibility

SRE – Introduction

Posted by Santh

SRE is what happens when you ask a software engineer to design an operations team
– Ben Treynor Sloss, Google

Site Reliability Engineering (SRE) is among the most popular technology topics during the last few years, with the IT industry viewing it as a better way to run production systems by applying a software engineering mindset to accomplish the work that would otherwise be performed, often manually, by sysadmins. The definition of SRE by the originator of this term (Ben Treynor Sloss at Google) gives an insight into the vision with which this concept was originally created – “SRE is what happens when you ask a software engineer to design an operations team”. As it usually happens with any topic that becomes popular, there are numerous SRE experts in the industry who have interpreted the concept as it is most convenient for their needs. To avoid a biased understanding, I started learning about SRE by reading the book written by creators of this concept at Google – Site Reliability Engineering: How Google Runs Production Systems.

Most misinterpretations on what SRE team should do and who should be part of this team will go away if one understands this statement from the book: SRE is fundamentally doing work that has historically been done by an operations team, but using engineers with software expertise, and banking on the fact that these engineers are inherently both predisposed to, and have the ability to, design and implement automation with software to replace human labor.

Google’s Approach to Service Management
  • Hire software engineers to run products and to create systems to accomplish the work that would otherwise be performed manually
  • Without constant engineering, operations load increases and teams will need more people just to keep pace with the workload
  • 50% cap on the aggregate “ops” work for all SREs—tickets, on-call, manual tasks, etc.
  • When a SRE team consistently spends less than 50% of time on engineering work, shift some of the operations burden back to the development team or add staff to the team without assigning that team additional operational responsibilities
  • Want systems that are automatic, not just automated

    • SRE vs. Devops
    Before going further into SRE, let me compare SRE with Devops, which is a similar concept that addresses friction between development and operations. SRE and Devops are similar when it comes to bridging the gap between development and operations in addition to massive focus on automation. In Google’s view, SRE is a specific implementation of DevOps with some idiosyncratic extensions. There are significant differences too with Devops being a mindset focused on product development and delivery while SRE is a set of practices focused on post production reliability.

    SREDevops
    ProductionRemoving silos, “big picture”, delivering applications
    Set of practices and metricsMindset and culture of collaboration
    System availability and reliabilityProduct development and delivery
    Systems engineers who write codeEveryone involved
    How it should be doneWhat needs to be done

    SRE Responsibilities:

    SRE team is typically responsible for the availability, latency, performance, efficiency, change management, monitoring, emergency response, and capacity planning of the services they support. The core tenets of Google SRE are:

    • Ensuring a Durable Focus on Engineering
    • Pursuing Maximum Change Velocity Without Violating a Service’s SLO
    • Monitoring using automated software
    • Emergency Response designed to reduce Mean Time To Repair (MTTR)
    • Change Management that is automated to accomplish progressive rollouts, quickly detecting any problems and rolling back changes safely when problems arise
    • Demand Forecasting and Capacity Planning to ensure that the required capacity is in place by the time it is needed
    • Provisioning conducted quickly and only when necessary
    • Efficiency and Performance by predicting demand and provisioning capacity

    Many organizations embark on building a SRE team in addition to a dedicated multi-tiered Operations team to support a service. Adding a SRE team as just another layer to existing ones supporting a service will only make the Operations process more inefficient. Being on-call is one of the integral functions of a SRE team and transforming existing L2 Support team to SRE model will yield the best results. Instead of “my environment is unique and SRE won’t work” attitude, it is important to revisit the entire Operations process holistically considering SRE principles and practices. In the next two blogposts, I will cover key points on principles and practices followed by Google as mentioned in the book.

    The 4 Disciplines of Execution

    Posted by Santh

    I had referred to 4DX in my previous blog and the book that introduced this concept was my next read. Executing projects to completion successfully has been my strength for long and after reading the book, was delighted to know that I already follow most of the rules given in this book. So, the book helped build my vocabulary on execution focus and also articulate how one can succeed with excellent execution. In this blogpost, have summarized the key rules and principles behind 4DX.

    People working at large organizations will be familiar with the struggle to prioritize execution of important strategic goals as they will invariably end up spending most of their time on urgent day-to-day operational tasks. So, the real enemy of execution is our day job, which the book calls the whirlwind. 4DX acknowledges the importance of whirlwind and provides a set of rules for executing our most critical strategy in the midst of our whirlwind.

    1. Discipline #1: Focus on the Wildly Important – The big idea here is to focus our finest effort on a few highly important goals that can he achieved in the midst of the whirlwind of the day job, rather than giving mediocre effort to dozens of goals.
      1. Rule #1: No team focuses on more than two Wildly Important Goals (WIGs) at the same time.
      2. Rule #2: The battle you choose must win the war.
      3. Rule #3: Senior leaders can veto, but not dictate.
      4. Rule #4: All WIGs must have finish line in the form of from X to Y by when.
    2. Discipline #2: Act on the Lead Measures: Discipline 1 takes the wildly important goal for an organization and breaks it into a set of specific, measurable targets until every team has a WIG that it can own. Discipline 2 then defines the leveraged actions that can enable the team to achieve that goal. Tracking a goal is done through two types of measures:
      • Lag Measures: Measurement of a result we are trying to achieve and called lag measure because by the time we get the data the result has already happened, so they are always lagging. Example – sprint velocity, lead time, revenue, profits, etc.
      • Lead measures: Foretell the result and is virtually within our control. Example – while a sprint goal (say velocity, lag measure) can be jeopardized due to external dependencies that are out of the team’s control, the team can certainly adhere strictly to acceptance criteria (lead measures like definition of ready and definition of done). And more the team acts on the lead measure, the more likely sprint goals will be accomplished. Lead measures should have two primary characteristics:
        • Predictive: If the lead measure changes, team can predict that the lag measure will also change.
        • Influenceable: It can be directly influenced by the team without a significant dependence on another team.
    3. Discipline #3: Keep a compelling Scoreboard – The third discipline is to make sure everyone in the team know the score at all times, so that they can tell whether they are winning. A Sprint Burndown Chart that tracks the team’s progress towards sprint goal can be an example. The following four questions will determine if the scoreboard is likely to be compelling to the team:
      • Is it simple?
      • Can I see it easily?
      • Does it show lead and lag measures?
      • Can I tell at a glance if my team is winning?
    4. Discipline #4: Create a Cadence of Accountability – The fourth discipline is to create a frequently recurring cycle of accountability (WIG sessions) for the past performance and planning to move the score forward. In a Scrum team, Sprint Retrospective is a routine that strives to achieve this by expecting the team to discuss those things that went well and others that went wrong, to identify improvement opportunities for future sprints. A WIG session has the following three part agenda:
      1. Account: Report on commitments
      2. Review the scoreboard: Learn from successes and failures
      3. Plan: Clear the path and make new commitments

    Over the years, I have seen numerous strategic organizational initiatives being launched with the right intent and much fanfare. However, only a few of them achieved the real goals and many went down quietly over time, slowly suffocated by the whirlwind. The book summarizes this situation beautifully and kindles hope at the end: Once people give up on a goal that looks unachievable – no matter how strategic it might be – there is only one place to go: back to the whirlwind. After all, it’s what they know and it feels safe. When this happens, your team is now officially playing not to lose instead of playing to win and there is a big difference. Simply put, 4DX gets an organization playing to win!

    Work deeply

    Posted by Santh

    We are taught from childhood that “no pain, no gain”, emphasizing the importance of spending time and effort to achieve results. Once we grow up, we encounter self-help books that teach us to pivot towards working “smart”, not just “hard” and present their own theories and practices to make their point. All of them are based on the author’s personal experiences and beliefs, and we can benefit by learning from them and customizing for ourselves. One such book that stuck a chord with me is “Deep Work” by Cal Newport. Just as I finished the chapter on Rule #1 – Work Deeply, I was able to connect my learnings to a challenge my son wanted help with and immediately wrote this blog post with my thoughts.

    Let me start with references from the book, followed by my inferences that will explain the picture above.

    • Roy Baumeister on willpower: You have a finite amount of willpower that becomes depleted as you use it.
    • Ritualize: To make the most out of your deep work sessions, build rituals of the same level of strictness and idiosyncrasy. These rituals will minimize the friction in transition to depth, allowing us to go deep more easily and stay in that state longer.
    • 4DX: The 4 disciplines of execution (abbreviated 4DX) is based on the fundamental premise that execution is more difficult than strategizing. It helps address the gap between what needs to be done (strategy) and how to do it (execution):
      • Discipline #1: Focus on the Wildly Important – Ironically, the more you try to do by pushing too hard, the less you accomplish. So, execution should be aimed at a small number of “wildly important goals”.
      • Discipline #2: Act on the Lead Measures – There are two types of measures for success – lag measures and lead measures. Lag measures describe the thing you are ultimately trying to improve while lead measures focus on the new behaviors that will drive success on the lag measures. The problem with lag measures is that they come too late to change your behavior. So, start with acting on lead measures.
      • Discipline #3: Keep a Compelling Scoreboard – An always visible scoreboard creates a sense of competition that drives us to focus on these measures, even when other demands vie for our attention. It also provides a reinforcing source of motivation. Finally, it allows us to recalibrate expectations as required to achieve what is wildly important (like an agile burndown chart will help the team recalibrate efforts required to meet sprint goals).
      • Discipline #4: Create a Cadence of Accountability – A periodic review of scoreboard helps us to review progress towards lag measures and pivot as required in case the progress does not really converge towards producing the ultimate results expected.
    • Be Lazy: Tim Kreider in his “The Busy Trap” blog says – “I am not busy. I am the laziest ambitious person I know” and goes on to explain “Idleness is not just a vacation, an indulgence or a vice; it is as indispensable to the brain as vitamin D is to the body, and deprived of it we suffer a mental affliction as disfiguring as rickets. The space and quiet that idleness provides is a necessary condition for standing back from life and seeing it whole, for making unexpected connections and waiting for the wild summer lightning strikes of inspiration — it is, paradoxically, necessary to getting any work done“. So, periodic shutdown from work will enhance our ability to produce valuable output due to the following reasons:
      • Reason #1: Downtime aids insight – Unconscious Thought Theory (UTT) posits that the unconscious mind is capable of performing tasks outside of one’s awareness, and that unconscious thought (UT) is better at solving complex tasks. The implication of this line of research is that providing your conscious brain time to rest enables your unconscious mind to take a shift sorting through your most complex professional challenges.
      • Reason #2: Downtime helps recharge the energy needed to work deeply – Attention Restoration Theory (ART) asserts that people can concentrate better after spending time in nature, or even looking at scenes of nature. The core mechanism of this theory is the idea that you can restore your ability to direct your attention if you give this activity a rest.
      • Reason #3: The work that regular downtime replaces is usually not that important – Working in information technology field for US multinationals from India means ones evening is core work time, attending meetings and discussions during the limited time zone “overlap” available. So, I replaced “evening downtime” with “regular downtime”, which for me is typically a few hours every morning when I go for my morning run and spend time with family. The point is that your capacity for deep work in a given day is limited and by setting aside some time for yourself to relax and reenergize, you are missing out on much of importance.

    Putting it all together: Going back to my son’s challenge, he got an unexpected one week holiday as his school had to reschedule classes due to second covid-19 wave. He was initially happy with this change as he could spend time as he wished (usually video games) for an extra week but the willpower he had originally corralled to excel academically had gone unutilized resulting in his initial euphoria eventually turning into guilt.

    As humans, we are usually tempted to engage in shallow activities that are easily enjoyable (like playing video games or watching our favorite TV show) instead of deep work (like studying or writing this blog). But we are also ambitious and aspirational with a need for achievement to make our life purposeful. Willpower helps us handle this conflict by motivating us to engage in deep work required for purposeful activities that are usually difficult. But our willpower is finite that depletes with use and needs to be recharged for sustenance. Overutilizing willpower will lead to exhaustion, underutilizing it will lead to guilt and smartly utilizing will produce great results for our wildly important goals. Smartly utilizing our willpower means:

    • Using rituals to minimize the friction in transition to deep work and amplifying the benefits of finite willpower
    • Using the 4 disciplines of execution to measure and progress towards our vision and goals
    • Provide ourselves sufficient rest to recharge the energy needed to work deeply

    With years of trial and error, I was already practicing some of these disciplines and this book provides additional structure that should make me more effective!