My year in books – 2015

I read quite a bit. In all 53 books, & over 16,000 pages. Here’s to yet more reading in 2016.

No plan survives contact with the enemy

The Iraq war & the ensuing occupation was a clusterfuck of epic proportions. This post isn’t about that. This post is about the operation carried out by US military to defeat Iraqi forces. Having just finished COBRA II, there are many lessons from Operation Iraqi Freedom that apply to running projects & team, as well as shipping impactful software

Be wary of a detailed plan & trust your team

In planning the invasion, US Centcom Chief Tommy Franks put together a detailed plan which described specifically how quickly American forces would move to capture Baghdad, and the dates at which they would cross specific bridges. He shared this plan with his land forces commanders, & asked them to operationalize it. The central assumptions of the plan were that American forces would face stiff opposition from Iraqi mechanized forces, & that southern cities in Iraq would join the American forces.

Reality turned out to be different. In southern cities, American forces were stumped by paramilitary forces (Fidayeen) as well as civilians who used small arms fire (RPGs, AK 47s) to ambush and slow down their advance. Instead of a conventional enemy line, American forces were in a 360 degree fight.

The land forces commanders saw this, and decided to slow down the advance because they didn’t want to leave their supply lines & rear exposed. This was not in keeping with the detailed plan which US Centcom & the Pentagon were anchored on. The Pentagon & Centcom leadership saw this as a sign of weakness, risk averseness, as well as bad decision making by the land forces commanders.

There is an important lesson here for us. It is important to be goal oriented, & keep planning based on latest insight. This is especially true in irregular environments (new products, risky initiatives, etc). In these situations, be wary of a detailed plan & encourage your team that is immersed in the work to keep their eyes open & keep “re-planning” based on latest insight.

Theory =/= Real world

The Pentagon had deployed a lot of technology in the battlefield to give all land forces “real time battlefield awareness”. In theory, this would ensure all forces had real time awareness of each other through a “blue force tracker”, be able to co-ordinate better & as a result, move rapidly. Further, the blue forces tracker would give real time insight to US Centcom as well as the Pentagon on the advance of the US land forces.

Reality turned out to be different. The blue forces tracker provided insight to troops about each other, & would have worked great if there was a well defined enemy line. Because US forces were under a 360 attack whenever they engaged the enemy, all the blue force tracker told field commanders was that troops weren’t moving as planned, and this confused most of them. One land commander quipped that what the troops needed was a red forces tracker.

To make matters worse, US Centcom had access to the blue force tracker, and they noted that the land forces weren’t moving as fast as planned. They in turn pressured the field commanders who were facing an enemy they hadn’t trained for. Instead of providing real time intelligence, the technology provided real time confusion.

What worked elsewhere might not work here

In Afghanistan, US special forces played an instrumental role in winning the war. They were able to partner with rebel forces in Northern Afghanistan, & direct air attacks to quickly defeat the Taliban. This had convinced Pentagon leadership that special forces could be used similarly in Iraq as well.

The Pentagon felt that the Shias in southern Iraq would rebel against Saddam when they saw an American invasion, and special forces would be able to direct them & air attacks to defeat the enemy.

Unfortunately, none of this happened. Shias in southern Iraq didn’t rebel. On the contrary, US forces faced strong opposition from paramilitary forces, in cities like Samawah & Nasiriyah. In addition to slowing down land forces, this neutralized any kind of advantage US special forces could provide.

If there is no place for it, don’t shoe-horn it in

Following up on the previous point, the Pentagon was determined to deploy US special forces. The Pentagon felt that Iraqi forces would blow up the Haditha dam in Western Iraq to cause a flood & slow down US forces. They rushed US special forces to take control of the dam, which the forces did successfully.

Once the forces got there, they realized that Iraqis had no plans to blow up the dam & that the dam was in disrepair. Iraqis who could maintain & operate the dam were either killed or had fled, & the special forces had no idea how to operate a dam that was in disrepair. Luckily, the dam continued to operate till US could bring some experts in (a few weeks)

Ironically, shoe horning forces almost led to a disaster that Pentagon leadership wanted to avoid.

Overall, there’s many useful lessons to draw from the invasion, but at the highest level, what’s important is constant planning & re-evaluation with a clear goal in mind, not sticking to a detailed plan designed before execution. For leadership & management, emphasizing inflow of communication from the front lines is critical to success.

What Accident Statistics taught me about Metrics

I first took interest in goal setting & metrics nearly 5 years ago at a fledgling startup where we were trying to get our first product off the ground. The Lean Startup wasn’t out yet, High Output Management was hidden somewhere on Ben Horowitz’s bookshelf, & Goal was known only to Jeff Bezos’ inner circle. My research led me to “Out of the Crisis” by Edwards Deming, first published in 1982.

If you are unaware of Deming, he was a key management thinker (the anti-Drucker according to some, though they had more in common than distinct) who was ignored by American managers but embraced by the Japanese. American managers were big on the quota system, automation, & the compromise between quality & productivity. Deming on the other hand espoused the belief that the only way to achieve long term productivity is by improving quality (measuring it through statistical means & improving it constantly). Eventually, his principles & teachings led to the Japanese manufacturing revolution, & created The Toyota Way.

“Learning is not compulsory, neither is survival.” – Deming

The book is deeply insightful, and explains many management concepts in terms that are easy to grasp (the book is devoid of inaccessible management speak, & filled with inaccessible statistics instead). One takeaway of the book is that management requires one to roll up their sleeves, get immersed in the work to understand it well, & away from “dashboards”. In 1982, he cautioned that the PC revolution would encourage managers to rely to easy to access dashboards without understanding the actual business.

Outcomes vs. Actionable Metrics

One of the concepts the book explains is the difference between actionable metrics & outcomes. While outcomes ultimately matter, they are terrible at guiding day to day decisions.

An example Deming uses here is accident statistics. Let’s say that a city wants to reduce the number of deaths due to accidents, from 1,000 last year to 900 this year. Measuring this helps the city understand how its doing but it doesn’t inform what the city should do to move the needle. He calls this type of metric an outcome. He tells managers to reduce their reliance on metrics of this nature to inform their day to day decision making.

Instead, he encourages that managers dig deeper to find actionable metrics that represent the system — metrics that inform their actions but also connect to the outcome they are trying to impact.

To reduce accidents, actionable metrics would be number of intersections with cross walks, total length of paved side walk, number of speed limit signs posted, number of speeding tickets or DUI tickets issued, number of intersections with stop signs, etc. Prioritizing & measuring these would give the manager leverage on the outcome, & inform day to day actions & decision making. The manager could run many types of analyses & experiments to verify what impacts the ultimate outcome, what offers greatest leverage, & then focus on those areas.

To summarize, I think it is super important for everyone to understand what metric they can impact & how that connects to the ultimate outcome of their team & the business overall. If you haven’t done so already, now’s a good time.

 

A Case for Bots

For the last 5 years, we’ve been living in the app economy. There is an app for everything imaginable. Apple has ~ 1.5M apps in its app store whereas Google has 1.6M apps in the Play store. An average person uses about 25 apps a month.

Looking at these stats, it is obvious that while the ecosystem is vibrant, app discovery is broken. However, I posit that apps as a universal model for all valuable services is flawed. Ergo, the means of delivering value is as much to blame as the yet unsolved distribution & discovery problem that plagues app stores.

“There’s an app for it” is the wrong answer

An app is a designed consolidation of a few use cases that the app developer believes as valuable for users. By extension,  apps try to aggregate user experience. While this increases richness of an app, it can create a frictional experience for each use case. This sort of friction forces users to break context of whatever they are doing, load a different app, and find their way through a set of screens to get an answer to whatever they are looking for.

Consider a calendar app. It does many useful things. It lets you create meetings, it lets you review your agenda, it lets you see where the next meeting is & who you are meeting. These are the core use cases of a calendar app.

However, if you probe the user cases, I’m doing a few different things in different context.

1. What I do most frequently is quickly check when the next meeting starts, & find out which room its in. When I do this, I’m typically in a messaging app or window. I’m usually walking from my desk towards a room.
2. While less frequent, I often look at my daily agenda twice a day. Usually, I’m waiting for coffee & catching up on messages from the night before.
3. When I create meetings, I’m often in a chat thread when someone decides we need to meet face to face to discuss an item & determine next steps. I do this a few times a day.

Today, for all of these experiences, I need to open a calendar app. This not only pulls me away from what I’m doing, it also forces me through go through a frictional experience of clicking, dragging, zooming a few times – not to mention load times for each of the steps.

While the experience is less worse for infrequently used apps (because I don’t use them enough), finding them when I need them is painful.

What would be ideal is

1. Deliver value to me in context of what I’m doing, without having to jump across apps.
2. Discover valuable new services & get stuff done instead of wasting time & mental capacity in searching for things.

This is where bots come in.

What is a bot?

A bot is a service that listens to you when you address it, and does things that you ask for. It lives in an app where you spend a lot of time, and have a lot of conversations. This could be a messaging app, or a discussion forum, email, or a groups app.

What’s a bot good for?

Now bots won’t be the right means of delivering value for all experiences we use apps for today. I believe the right way to look at bots is examine use cases on a frequency of use & nature of use matrix. This is better than examining apps because apps aggregate user experiences & examining them might never provide a clear view of what kinds of problems bots could solve

Transactional use cases are things you can straight forward answers to, or get done without any interaction. An example here is checking where your next meeting is, who you are meeting, & its agenda.

Linear use cases require a bit more interaction, but are usually depth-first use cases with ~2 choices at each step. An example here is creating a meeting, where you choose participants, book a room or create a video conference, & an agenda.

Immersive use cases require rich interaction & often have multiple traversal paths for a user. An obvious example here is browsing your newsfeed.

Here are some more use cases examined on this framework.

Some things are obvious.

1. Bots atomize experiences unlike apps which consolidate them.
2. Bots often augment services that apps provide, and are a new channel of engaging users especially for daily or weekly use applications.

If I were to examine these use cases based on suitability for bots, things pan out differently for different regions.

 

The bot sweet spot is the region of daily use cases, that are transactional in nature. In this region, bots often augment existing full featured apps but not always. E.g. Digit, a service that saves money on my behalf sends me a daily update via SMS & offers some basic ability to ask questions. It is very primitive & doesn’t need a terrible amount of sophistication.

For monthly use cases, I believe bots can answer discovery & distribution problems if a messaging platform supports NLP as well as a page-rank type algorithm for ranking relevance of bots for specific questions its users ask. In that sense, messaging platforms can be tremendously powerful – almost like the browsers were.

For daily use cases that are immersive in nature, like browsing newsfeed, bots will offer little to no value. The magic of newsfeed or a twitter feed is in serendipitous discovery & interaction – something bots will be terrible at.

For rare use cases that are  immersive, like booking personal travel & building an itinerary & making several bookings under constraints of time & money, bots will need to mature significantly at NLP and also integrate with multiple services. This is the region where a bot like M comes in.

What needs to mature?

Over the next several years, we’ll see many technologies mature which will enable teams to build bots that provide & scale entirely new services as well as augment existing apps like calendars with bots.

1. Natural language processing – The power of command line interaction was in articulating exactly what you wanted & getting an answer. However, the precision & inaccessibility of commands made it difficult for an average user to use command line. With maturing NLP, the barrier imposed by precision of the query goes down.
2. Voice recognition – The dominant interaction paradigm of the last decade has been touch, pinch, & zoom. However, with bots, talking actually becomes a very useful interaction paradigm. I’ve been using Amazon Echo for a few days now, and we haven’t touched our phones at home for common use cases like playing music or checking weather. It is not hard to see that eventually, we will be able to order a cab or food, or send a message via Echo.
3. Messaging platforms – Messaging will be an important surface for delivering value via bots. A platform that makes it easy for the world to build bots, and users find bots that can get stuff done for them will be a $100B company. This isn’t an easy problem and requires that 1 & 2 get solved, and it also requires that the messaging platform have wide distribution in order to learn rapidly.

To summarize, I encourage all product teams to examine the use cases they are solving for, & consider bots as a first-class means of delivering value to your users. It will be an important surface for discovering new services as well as delivering a world class experience to your users.

Doing what life expects from me

This year has been a turning point in my life. For most of last decade, I pursued what I expected from life. From grad school, to building a startup from 3 to 50+ employees, to joining Facebook.

The combination of the amount of reading I’ve done this year & the time to reflect over the past year (thanks to 80% gross margins on $B revenue, I’m not waking up every other night to an outage or a customer call from Australia anymore!) on the privilege that surrounds me (I learnt phrases like “fuck you money” ಠ_ಠ), I decided that I need to do what what life expects from me*.

The New Jim Crow, combined with a few other books, made a lasting impression on me. After reading them, I understood that the cards are stacked against prisoners trying to re-enter society. I realized I understood very little about the specific challenges that a prisoner faces. I remember discussing this with our book club, and the common sentiment was frustration at not knowing what could be done. There were no obvious points of leverage, no silver bullets. For me, it was clear that the best way to learn what was going on & to have an impact was to roll up my sleeves.

After a few months of research, today I start my volunteer orientation with the California Reentry Program that works out of San Quentin state prison to help prisoners re-enter society. To the best of my understanding, most of the work involves conducting research on behalf of prisoners, and providing them guidance based on this research. It also includes teaching them some skills such as resume building, interviewing – things we take for granted.

I’ll be lying if I said I’m not nervous. I’m not nervous about going to prison & working with prisoners (even though the handbook has pages after pages of rules & restrictions, which is a stark contrast after spending most of my life trying to break rules). I’m nervous about what impact this will have on me. Will I be able to handle coming face to face with people who are trying to take a second shot at life? Will I be able to continue doing this over next several months or years, or will I stop? As with all things I’ve done, we’ll find out. One thing is for sure – I haven’t felt this motivated, yet powerless about anything in life. Here’s to doing what I think life expects from me!

* – A phrase I borrow from Victor Frankl.

Questions machines should answer

Most of what I do is build products that help people make better decisions & allow them to do what people are truly great at – building relationships. There’s a host of machine learning techniques that can be used to improve decision making. However, it is important characterize types of decisions made in a typical business. At their core, these fall into 5 categories – Who, What, When, Where, Why.

Who?

This is a seminal question for businesses. Who should we sell to? Who should we hire? Who should we promote? For majority of these, today we rely on search, heuristics, or expert systems. Search and keyword engineering is how most recruiters try to find prospective candidates when they’re building their pipelines. Heuristics is how most sales & marketing teams identify & qualify prospects. Expert systems are often what most analytics platform rely on to provide insight, e.g. which customers show poor engagement.

The problem with existing approaches is primarily that it still relies on people to make judgements or rules, and doesn’t integrate lifecycle learning with decisions in real time.

What?

Once you’ve successfully identified who to engage, the next question is what do you engage them with. For a sales prospect, what is the best collateral for you to share with them? For a potential candidate, what message will resonate most with them & convert them? Again, today we rely on a rep or a recruiter’s ability to search for & mine information to determine what the message & collateral should be.

Many people believe this differentiates good reps from average reps. I fundamentally think this is incorrect. People should do what they are good at, which is building relationships, negotiating, etc. People should not be judged by how good they are at something a machine will be much  more effective & efficient at.

When?

Getting attention at the right time matters. Most existing notions about right timing range are rules based, heavy on conjecture, & “one size fits all”. An example of this is “best time to engage a candidate is at the X year mark”, or “best time to engage a prospect is at the beginning of a new quarter”. At best, these provide guard rails around actions, & at worst, these are old wives tales at best, created based on intuition of “experts”.

Here again, machine learning provides us an opportunity to determine the best time to engage a prospect, based on features of the prospect as well as matching pattern against successful engagement in the past.

Where?

Where we engage prospects matters today more than it ever has. Between all the means of communication (email, phone, ad, in app notification), form factors of consumption (desktop, mobile, watch, etc) as well as  awareness of location, we have the ability to understand the most suitable place & means who which we should communicate. Email has & continues to be the lowest common denominator of means of communication, but this is going to change rapidly.

Why?

What stands in the way of advances in machine learning is how people interpret recommendation, & act on them. We are conclusion forming machines, and absent of conclusions, we have a hard time acting. When a machine answers any of the 4 questions above, a human will need to understand why that’s a good answer. A successful implementation of machine learning for these should be able to inform the user, and help them develop an intuition for a certain decision, or else – people will simply ignore the recommendations.

To summarize, the future of enterprise productivity belongs to companies that enable their customers to answer the who, what, when, & where better than anyone else.

Abstractions, Autonomy, Appetite – The 3 Enablers of Speed

Speed remains one of the salient features of successful software companies. I’ve written in the past about why engineering & business teams should be designed to move fast. But what enables speed? Why are some teams able to move fast, while others struggle. Based on my experience at building products at Sefaira, and now Facebook, I’ve found 3 key enablers of speed.

Abstractions

In the early days of a startup, when you’re building a product that has some traction with customers, you make short sighted technical decisions. Given the stage, these decisions are generally valid. However, overtime these decisions harden the tech stack, making it difficult for small teams or individuals to work independently, and ship impactful things. This phenomena affects not just startups, but all high growth software companies.

This is where abstractions come in. As a team grows, and the tech stack grows, a company that focusses on deliberately decoupling the tech stack and creating meaningful abstractions (on an ongoing basis) will be able to sustain its speed by liberating engineers from inter-team dependencies. This allows a small team to leverage the depth of your entire tech stack to build new products & features, as well as experiment at an ever faster cadence.

Autonomy

This one seems obvious. While abstractions reduce the dependencies a team has on others in order to ship, autonomy reduces the number of permissions a team needs in order to build new products. A system of permissions is often a result of lack of trust in your engineers to understand the needs of your user & the ability to ship impactful features. Such a system will inevitably slow down. You can often tell how much autonomy an engineering team has by calculating the ratio of commits with & without associated tasks.

In order to fight this, it is important to give a team clear objectives to hit, and then step away from day to day functioning of the team. It’s important that your engineers spend a non trivial amount of time with your users (even if they are users themselves) & are responsible for tracking product adoption & success metrics. Such a system allows the team to operate independently towards achieving its objectives.

Appetite

With abstractions & autonomy in place, you now have the right environment for hungry engineers to thrive. Unfortunately, most contemporary software development techniques tend to handicap this speed. Estimate & date driven engineering culture sucks the life out of building products. These techniques while possibly great as a tool for learning, generally dehumanize engineers.

Instead of setting up checks & balances, focus on giving your engineers well defined goals & autonomy to achieve them, and set up incentives which encourage them to take a big bite.

Lastly, one remarkable thing about these three traits is that they are self reinforcing. As an organization grows, these characteristics allow a team maintain their speed, and in many cases, move faster.

What does building clocks have to do with the future of computing?

When I was in 6th grade in India, many of my friends in school were electronics enthusiasts. Give us a few general purpose circuit boards, resistors, transistors, capacitors, and a soldering iron, & we felt we could build anything we wanted.

We built things like door bells, mini pianos, clocks, alarms, and many annoying little gadgets. I think I even made my parents install the doorbell I made in our house. From there we graduated to making stuff on computers. In 9th grade, we built a software for managing hotel reservations in Borland C++.

So where are some of us today. Without names, I’ll mention their roles

1. Computer vision scientist at Amazon
2. Chip designer at Synopsys
3. Chip designer at NVidia

Not only was none of us arrested & interrogated, today many of us are designing the future of computing, right here in America.

That’s what’s really disheartening about Ahmed’s story. America & the world needs more kids to do what he was doing. Instead, he was arrested, suspended from school, interrogated by the state, & not allowed to call his parents.

The Mongol Way

At its peak, the Mongol empire included all of China, Russia, the Middle east, Persia, & Eastern Europe. Had Genghis Khan not passed away, forcing General Subotai to return for the great gathering to elect the new Khan, the empire would have likely stretched all the way to the Atlantic. While brutality is a trait that Mongols are known for, brutality was a consequence of their conquest & not the basis for it. Having read 2 books on Mongol history & military strategy, & heard the Hardcore History podcast series “Wrath of the Khans”, I’ve learnt that there were some key traits that made Mongols such a vaunted military machine. My intent behind writing this is to list their core “values”. I leave to the reader to draw lessons.

1. Speed above everything else

The Mongol military was almost always smaller in size compared to their enemies. This put them at a disadvantage relative to their enemies who were often well stocked & numerous. However, Mongols emphasized speed & mobility as virtues above everything else. Speed afforded them many tactical advantages. They were able to engage the enemy on their own terms when they wanted & where they wanted, they were able to flee when they made a mistake, they avoided disease that often paralyzed slow moving armies, & they were able to communicate across many different regiments who were all marching towards the same battle from different points of approach.

However, mobility wasn’t just a consequence of being nomadic, though that certainly helped. Mobility was a strategic objective. To enable this, the Mongol army was exclusively cavalry based. There was no infantry of note. Each soldier carried at least 3 remounts (horses, mostly). Their horses too were trained to tail their formation & didn’t need supervision. They carried raw horse meat under the saddle which cured the meat as they rode, giving them food on the go. In addition, they had dried milk which they could mix with water & drink for nourishment.

It’s clear that the Mongols understood their strengths & designed their strategy to leverage & amplify these strengths.

2. Meritocracy & autonomy

Per historians, Genghis Khan was the first leader in history to understand the importance of meritocracy. While many of his contemporaries appointed family members to positions of leadership, Genghis Khan was systematically meritocratic. His top Orloks (literally Eagles, equivalent of Field Marshals), Jebe & Subotai are illustrative examples here.

The earliest battles Genghis Khan fought were against other Mongol tribes as he strived to unite all of Mongolia. Jebe was a rival archer who shot Genghis Khan’s horse from under him in one of the battles. Genghis Khan so admired Jebe’s skills & bravery, that he appointed him as one of his top commanders. The other was Subotai who wasn’t even a mongol but a son of a blacksmith, and didn’t ride a horse till he was 15 (compared to most Mongols who started riding horses when they were 3). However, Subotai went on to become the top general for Genghis as well as his descendants, as he proved himself in many battles over the years.

Further, Genghis Khan and his descendants understood that his top generals needed autonomy to achieve the strategic objectives he had laid out. To enable this, compared to contemporaries, Genghis Khan’s military had wide ranging tactical autonomy in achieving the strategic objectives that the Khan set in consultation with his military leaders.

3. Compete on your own terms

I’ve pointed out that Mongol armies were smaller than their foes. However, Mongols always wanted to dictate the terms of the fight. For instance, their tactical doctrine stated that they won’t engage their enemy directly in hand to hand combat unless waves of light cavalry has already weakened them. This implied that they used speed & stamina (through remounts) of their cavalry to weaken the enemy by a barrage of fire, before any direct fighting (first military force in history to do so).

They also leveraged their advantage in communication to converge multiple regiments to a single point of attack. This ensured they weren’t as vulnerable prior to the final offensive.

Lastly, they went to great pains in timing their attacks. They attacked parts of Russia in winter because their horses could dig through snow to find grass (unlike their enemies) while they avoided attacking Baghdad in summer to avoid Malaria.

4. Focus on what matters

Mongol focus & discipline was legendary. At the very top, the Mongol military’s singular intention was to disrupt the enemy commander to sow confusion & destroy the morale of the opposing soldiers. To do this, they developed the doctrine, later adopted by the west as “deep battle” where they pummeled the opposing infantry with a barrage of light & heavy fire. When sufficiently weakened, they concentrated their forces and marched down the enemy formation to attack the commander. As a result, they won almost all battles against larger armies.

Further, they didn’t want their enemies to regroup. As a result, they spared no resource in pursuing enemy commanders to kill them. That Subotai pursued the Khwarismian Shah with an army of 30,000 after defeating him in battle for over 2,000 miles & several months across deserts, is a testament to their focus on their objectives.

There are also numerous instances where Mongol scouting raids didn’t loot or plunder enemies they defeated because they were singularly focussed on recon missions & understood that carrying loot would slow them down.

5. Learn from failures

In early battles against the rulers in China, the Mongol army failed miserably at siege warfare. The Chinese cities were protected by moats & 40 foot walls which didn’t exactly allow Mongol to leverage their primary strength — speed. Genghis Khan learnt that he needed to develop a heavy cavalry consisting of the most sophisticated siege machinery in the world. To achieve this goal, he often enrolled & promoted siege specialists from the ranks of his enemies, in exchange of sparing their lives. He was relatively egoless & very practical in this regard. He was very good at diagnosing causes of his failure, and spared no effort in fixing them.

I can think of many parallels that some of the top organizations today have, in terms of values, ranging from speed, focus & the ability to learn from failures & experiment. The context of course couldn’t be more different — we’re not in the killing business though the zero-sum game of monopolizing a market is still as real.

Leaders don’t wear a cape

When I returned to work on Monday, I found this note on my desk. It was left there by an intern who worked on our team over the summer, & left on Friday. It caught me by surprise, mainly because (as the note suggests) we didn’t work together a whole lot, and I also don’t remember “acting like a leader”. On thinking more about it, it reminded me of some very important aspects of leadership.

Leadership happens when you think no one’s watching

We often feel that leadership happens is when a situation requires it. For example, when you’re in a crisis, or  you’re making a speech, or reviewing a product, or leading a meeting. While leadership matters in these scenarios, the reality is that many around you are observing your “run of the mill” behaviors. They will emulate you, unbeknownst to you. How you conduct yourself when you think no one is watching is integral to leadership.

Leaders don’t need a cape

Many of us assume that being a leader requires a special title, e.g. a manager, or a director, or a CEO. We are all enamored with this “cape” that we expect leaders to have on when they act like a leader. Again, the reality is that leadership doesn’t require a cape or a fancy title. At its core, leadership is about making your team mates & others around you better, and ensuring their contribution & impact is outsized. To do this, you don’t need a fancy title, you just need to help those around you achieve & exceed their individual & team goals.

Leadership is a continuous state

There is no on/off switch to being a leader. Many of us feel that being a leader requires us to be strong & exhibit leadership behaviors in specific situations. Here the reality is that one can be as much of a leader when they are vulnerable as when they are strong. You can be as much of a leader when you screw up & make amends, as when you make a good decision and follow it up with great execution. Leadership is all the small things & the big things, all the good & the seemingly bad.

Ultimately, this note reminded me of a poem by John Wooden, titled “The little chap who follows me”

“I must be careful as I go
Through summer’s sun and winter’s snow,
Because I am building for the years to be;
This little chap who follows me.”