Does this sound like you? You're an achievement-oriented leader. To build momentum, you personally set the standard for performance and for exemplifying the values of the organization. You take the lead, set the pace, and expect the people around you will notice, follow along, and (eventually) catch up to and match your performance. What do you think actually happens? Not what you expect. Let me save you many months of pain. This pacesetter-type leadership has been a huge part of how I have managed the last 2 years, and while reflecting on 2024, I've finally come to understand some of the ways it works but can also fall short.

In 2022, I inherited a team operating a piece of critical platform infrastructure for Google. The team was full of bright, experienced engineers but was ostensibly failing. An infrastructure migration effort was entering its 3rd year with little to show in the way of results. Still getting my bearings in the new org, I spent time observing the team and came to the conclusion we were dying a death by a thousand cuts. Everyone was super talented and in each area (architecture, project management, operations, code health, testing, product, etc) we were easily scoring a solid "B+." But, it turns out, that "final missing 10%" compounded in a way that made the aggregate result underwhelming.

Consequently, the situation called for small, surgical changes across the board to optimize the performance of the team. The required changes would encompass both cultural attributes (habits/incentives/values) as well as fundamental technical skills and problem solving intuition. As part of my overall approach to turning the ship around, I resolved to role model the desired behaviors. For example, when we had a near-miss incident (caught during the release/rollout process) I personally authored the postmortem and led the review. Whenever production did something unexpected/strange (even if non-breaking), I would doggedly pursue an explanation even if it took hours/days. My intention was to exemplify a value of curiosity and an unwillingness to accept "I don't know" as the final answer. I would show-not-tell the team how to exploit debugging tools to maximum advantage and buff up our observability approach whenever an answer was not forthcoming. Surely, then, they would all become masterful solvers of distributed systems murder mysteries....right? Surely they would all become naturally curious and investigate these blips without being asked...right? Right!?

Not quite. My superstars and favorites continued to excel and even improved. Meanwhile, the strugglers and the "chronically stuck" continued in their old ways. These were the very people I most wanted to help! It wasn't that "leading by example" made no difference (in fact, it was quite important to my eventual success coaching this team), but rather the role it played is more akin to setting the table...someone still has to cook dinner if you're going to have an excellent meal. Through this experience and talking to other managers, I found many incorrect assumptions about the mechanism by which leading-by-example works.

In this post, I will–

• Chronicle the 6 errant assumptions that prevent learning-by-example from working consistently.
• Dive into the scientific underpinnings of observational learning, using neuroscience, psychology, and sociologally to describe the preconditions for vicarious learning.
• Describe a technique for successfully leveraging leading-by-example as a key component of an overall performance coaching regiment.

Assumption 1: your intentions are pure.

It is quite a coincidence that one of your primary instincts when the team is struggling is exactly the thing you're told not to do as a manager and that most new managers struggle to resist: doing the work yourself. Dressing it up as "leading by example" is a great way to deceive yourself into believing that you're doing the right thing when in reality you're falling back on old habits built up when you were a tech lead.

In football, the offensive coordinator cannot grab the ball and run down the field. It's against the rules and regardless they probably aren't physically capable of a 4.5s forty-yard dash. There's no such limitation in software engineering, you're perfectly capable of reprising your role as star quarterback. Instead, you need to take a step back and ask yourself "what would I do if it was physically impossible for me to step onto the field?"

You need to be skeptical when your intuitions seemingly justify a personal vice. "Uggh, I know McDonalds isn't part of my new diet, but I'm just so busy today I don't have time to cook and need to eat so...." Engaging your critical thinking is hard (addiction is a bitch). Verbalizing your thought process either in writing or by talking to a trusted peer can pressure test the decision. You'll know you're on firm ground when you can articulate...

• A complete set of observed symptoms of team dysfunction.
• An unexaggerated diagnosis of the causes of this dysfunction.
• Next steps and interventions flowing logically from these conditions.

Leading-by-example isn't a meaningful intervention, it's a tactic implemented towards a specific intervention strategy. For example, if the problems your team is facing require "culture change" then role modeling might help...but it should appear alongside several other tactics (such as: adjusting performance incentives, declaring values, screening for culture fit in the hiring process, team recomposition, etc).

Assumption 2: people want to be you.

I'll never forget the moment I realized I was a different species. A colleague had come to me for advice: they were having a heated disagreement with the tech lead of a sister team. I was offering perspective from my past experience when they interrupted me asking, "oh wait a minute, you're on the management ladder right?" and promptly short-circuited the conversation. It was as if my role in management meant I had no valid advice to offer an individual contributor. Prior to this point, I still very much thought of myself as an engineer, one that just happened to be working on problems at such scale that it was necessary to program people in addition to computers. This was a senior staff engineer so ostensibly their role wasn't too far removed from my own. And yet, I had 3 or 4 similar such experiences in short order which further confirmed I was an "other." In Google's culture, managers are a different specifies. The same is probably true at your company. This creates an apparent category error wherein many of your reports won't even have a fundamental recognition that how you manage your skillset, spend your time, and direct your attention has any bearing on how they ought to do the same.

Even your beliefs and preferences will be regarded with a grain of salt–seen as descended from a different set of priors towards a totally different ends. Borrowing the language of Max Weber–

• Engineers experience managers as purveyors of functional rationality: a type of bureaucrat whose primary concern is a means-end calculation of how a result be quickly and efficiently achieved ("I want this task done, done quickly, and with just enough effort")
• Engineers see themselves as purveyors of substantive rationality: more holistic, reticular, and value-driven ("I navigate the interdependency of a wide range of objectives and perspectives, balancing elegance/functionality/cost/extensibility/...")

In most cases, there will be no recognition that what appears as the former is really a much more advanced practice of the latter. For example, consider the entrenched resistance you've probably encountered over task management/agile practices. While you see organized backlogs, task breakdowns and small single-purpose PRs as tools that personally help you do "better" engineering, others see these as tone-deaf bureaucratic demands.

Assuming that people "look up to you" and are therefore motivated to learn your skills and imitate your proclivities is wishful thinking. As such, leading-by-example can actually move your team in the opposite direction. Your actions will be seen as establishing "this is the sort of thing the boss deals with."  The end result is less engagement with the desired behaviors rather than more. This is why tech leads (TLs) are so critically important. TLs inspire mimesis with ease because many envision a direct progression from where they are to the TL's role–they want to be the TL and so watch their behavior carefully. No one wants to be a manager...especially if you're like me and spend far too much time talking about how miserable the job can be.

Assumption 3: people care what you think.

Have you ever downplayed your own authority/power/importance? Probably! Servant leadership dominates present-day work culture. Regardless of style, most leaders try to actively encourage thinking for oneself and having a strong sense of ownership . This is a good thing! Low-ego cultures are amazing! People feel compelled to offer their best work, are unafraid of admitting mistakes, and readily adopt a beginner's mindset ensuring continuous growth. However, this also means eroding your own capacity to influence through deeds alone. You have, in effect, been continuously declaring "what I care about, believe, and do might not matter...think for yourself." It would be hypocritical then to express dismay when someone fails to emulate your behavior.

This flies in the face of a pervasive belief in leadership circles that where leaders focus their energies team interest follows. I most often hear this expressed by high-ranking VPs. First off, these folks exist on a totally different plane of existence from run-of-the-mill managers like me. Most people probably don't care where you or I direct our gaze. Moreover, I think this confuses actual and proximate cause. For example, you show up to an operational review and grill the engineers with deep, probing questions that catch them off guard. At next month's review, suddenly the engineers are much more prepared and they successfully answer your questions. Have you taught them the importance of rigor and engineering excellence? Probably not. What you've actually done is served up a hearty dose of negative reinforcement via public embarrassment. People are extremely sensitive to social rejection and will be certain to avoid repeating such mistakes. Any deeper learning rests on the assumption that the team is mature enough to realize that their boss's attention is a valuable signal about what matters. This lesson unfortunately tends to occur somewhere in the mid-to-late stage of one's career.

Speaking of hard-won career lessons: when is the last time you were memed into doing something because it was "VP so-and-so's #1 thing" only to find out later that said VP actually has five or six "#1 things?" Probably, like, yesterday given how often this happens to me. In effect, all of us–no matter our level in the organization–have been taught that a very-powerful-person's interests are mercurial (hey, it's almost like they are humans like the rest of us). One will not last long over-indexing on the opinion du jour.

As leaders under conditions of egalitarianism and fickleness, we've effectively forfeit the ability to influence behavior through the dispensation of attention/favor alone. I believe power exists to be used (otherwise, just have one giant flat org) and you probably shouldn't just give it all away, but that's a topic for a different blog post. At this point the cat is probably already out of the bag. You could fall back on the one "hard power" we posses: the distribution of opportunities and career advancement (and $$$). But then that brings us to...

Assumption 4: you can always reward the right behavior.

You need to be realistic about much authority you really have. You might think, "I define what success looks like in this team/org/company." However, the average reader of this blog is a manager at BigCo where promotions and annual ratings are the result of committee consensus. Are you certain you can sway the committee to support Jane Doe's promotion just because she followed your lead? This rests on an even more tenuous assumption that you personally are well-aligned with what the organization values. Or that factors outside of your control won't pop up at the wrong time (like an economic recession decimating the merit increase budget). Even startup leaders will run into the limitations of social capital and how much they are willing to shorten runway or strain relationships with cofounders in the name of perfect fairness.

Every time you fail to reward or at least praise someone who followed your lead, you run the risk of breaking the operant conditioning loop. There is a sort of game theoretic calculus happening where each of your reports is operating under imperfect information. For example, say you only offer formal feedback during annual review cycles. Your reports will be hypersensitive to any positive/negative signal whatsoever–even accidental signals. They are likely to see mirages of feedback where there is none and end up optimizing for the wrong behaviors.

Even the best managers fall victim to this in small ways due to inconsistency. It's impossible to have perfect visibility into how all of your reports spend their time. They might not think to broadcast that they did something or realize what they did is praiseworthy. You might have too many reports to pay close attention. You'll be stressed and overwhelmed one day and just forget to respond to that launch email with a hearty congratulations. Either way, at some point you'll miss something. Doubly so if you're trying to incentivize "micro-behaviors" that aren't readily apparent to distant observers.

Assumption 5: everyone's definition of success is the same.

On the subject of incentives, not everyone is incentivized by extrinsic motivators like promotions and wealth. Engineers ultimately choose which incentives they respond to, and some of those incentives are not under your direct control. Consider intrinsic motivators like mastery, novelty, relatedness, acceptance, and honor, freedom. If someone is motivated by mastery (e.g. constructing elegant, maintainable, well-architected systems) then they aren't likely to pay much attention to the techniques you employ for achieving business impact (e.g. balancing velocity/quality for long-term commercial success).

Imparting new skills via role modeling depends on the motivation of the learner to make an effort to understand and replicate your actions. Role models often operate on the faulty syllogism:

1. My team has the same goals as me (i.e. business impact).
2. My team is motivated to grow their role at the company.
3. My team is not acting optimally towards that objective.
4. Therefore this must be because of missing knowledge.
5. Therefore they will be attentive and driven to replicate behaviors that demonstrably achieve business impact and garner recognition.

The problems begin as early as step #1, where you assume everyone is aligned around the definition of success. Consider the divide between "launch" and "landing." When someone sees "launching" as the end-goal, they will throw a party and go home the second their code hits production. Meanwhile, if you see "landing" as the end-goal, you'll continue diligently measuring and assessing whether the launched feature is resonating with users. What you might view as excellent role modeling, your team sees as "oh that's just Jim, he's obsessed with metrics 🙄."

Misalignment occurs in somewhat obvious ways, like in the example above, but also in more pernicious forms. For example, someone may be very transparent that they are seeking career advancement and therefore define success around helping the organization achieve its goals. But what happens when you disagree about the specific ways they need to show up given their role/level? Your team members have some conception of what their "craft" is and the skills required to be a masterful practitioner. When their conception of "being an excellent engineer" is in conflict with "the behaviors the organization will reward" cognitive dissonance follows. In the worst case, engineers become embittered and lose confidence in the organization. No amount of role modeling will get through to someone who sees those behaviors as emblematic of an inferior value system.

Assumption 6: your work is visible.

Goal formation occurs at the macro level (as in the prior assumption, where we talked about overarching objectives like business impact) as well as micro level (goals employed in the problem solving procedure). For example, responding to a production incident involves goals like "figure out when the incident started" which itself can entail further goals like "find the right graph in Prometheus." Unless you go out of your way to broadcast every step taken, your team will have no visibility. It will be impossible for someone to replicate your problem solving strategies or the subordinate skills you drew upon in the process.

Observational learning depends on the learner's capacity to recognize, encode, and structure the critical concepts. If the learner cannot perceive and understanding the nuance behind your actions, they aren't likely to successfully replicate those behaviors or employ them at the appropriate times.

That said, perception also depends on sensation which is all too often missing in our brave new world and remote and hybrid work. The bulk of your brightest moments and breakthrough problem solving likely occur in private or a closed conference room. Your team can't learn anything if all they can observe is the final end result.

I've tried to solve this by sharing stream-of-consciousness documents and chat threads which capture my entire process, tools utilized, and evidence collected every step of the way. I call this "live-tweeting the problem." One such document was over 20 pages and took several days to write. This just isn't practical. It's even less practical to chronicle the nearly infinite number of things you didn't do and actively avoided because you knew they were fruitless blind allies. This is what's known as negative knowledge and assists with effectively avoiding obstacles (like spending hours debugging a WARNING in the logs that you know is just a spammy log line that gets printed even during normal operation).

Despite your best efforts, most of the time your team will be reading smoke signals limiting the effectiveness of any role modeling.

The Science of Observational Learning

I've painted a pretty negative picture, so I want to reiterate that leading-by-example is a foundational part of how I approach my work. Doing this effectively means replacing errant assumptions with empirical facts. When you "lead by example" you are deploying what psychologists call observational learning. Understanding the underlying mechanisms will help you be a more effective role model. Let's build this up starting from neuroscience.

Learning Abstract Concepts and Mirror Neurons

A mirror neuron is a neuron that fires both when an animal acts and when the animal observes the same action performed by another. It has been postulated that mirror neurons play a critical role in the acquisition of motor skills and even speech/language. Mirror neurons have been frequently referenced in self-help literature and pop-science media, over-hyping the role they play. There is limited scientific consensus on the full extent of their function in human cognition beyond motor skills. In fact, mirror neurons were first discovered in the motor cortex (specifically area F5 of the premotor cortex) of macaque monkeys. When we talk about "mirror neurons" in the context of knowledge work or abstract skill acquisition, we're often incorrectly extending the concept beyond its neurological basis.

What actually happens during knowledge work and abstract learning is more complex. Rather than mirror neuron activation, we're typically engaging multiple cognitive networks, including:

• The executive function network in the prefrontal cortex, which handles planning, decision-making, and abstract thinking.
• The default mode network, which is involved in understanding others' mental states and perspective-taking.
• The working memory system, centered in the dorsolateral prefrontal cortex, which maintains and manipulates information.

When we observe someone performing knowledge work, like programming or problem-solving, we're not actually mirroring their actions in our motor cortex. Instead, we're engaging in what cognitive scientists call "cognitive modeling" or "mental simulation." This process involves:

1. Understanding the goals and subgoals of the observed behavior.
2. Recognizing patterns and strategies.
3. Building mental models of the problem-solving approach.
4. Integrating new information with existing knowledge structures.

When we watch someone debug code, we're not actually engaging mirror neurons in the same way we would when watching physical movements. The learning process is more cognitive than motor-based.

"[Learners] need to make sense of the situation or instruction, identify and construe relevant goals, develop appropriate responses, and realize the goals to which their efforts are directed. Hence, individuals’ thinking, acting, and learning are mediated by the degree of conscious engagement when undertaking work tasks."

– Stephen Billett, Christian Harteis, & Hans Gruber, Developing Occupational Expertise through Everyday Work Activities and Interactions, The Cambridge Handbook of Expertise and Expert Performance.

This distinction is important because it helps us understand why learning abstract skills through observation can be more challenging than learning physical skills. Without the direct motor-mapping that mirror neurons provide, we need to rely more heavily on explicit instruction, understanding of principles, and active engagement with the material. When one "leads by example," that usually precludes any of the above:

• There is by definition no explicit instruction happening and any communication of principles rests on prior understanding.
• The low visibility of technical work in general further constrains the bandwidth of any information transmitted to the learner.
• Engagement with the material rests on motivation which, as covered earlier, can be impeded by self-identity mismatch, goal/motivation mismatch, and inconsistent reinforcement.

This partially explains why leading-by-example is middling-at-best for teaching new software engineering skills.

Social Cognitive Learning Theory

There are 4 cognitive conditions that mediate vicarious behavior acquisition according to Albert Bandura–

1. Attention: learners must actively focus on the model and behavior being demonstrated. This process is influenced by characteristics of the model, such as how much one likes or identifies with the model, and by characteristics of the learner, such as the learners's expectations.
2. Retention: the observed behavior must be remembered and mentally represented. This process depends on the learner's ability to code or structure the information in an easily remembered form or to mentally/physically rehearse the model's actions.
3. Reproduction: learners must be capable of physically and intellectually performing the observed actions. Reproducing the model's actions may involve skills the learner has not yet acquired. It is one thing to carefully watch a circus juggler, but it is quite another to go home and repeat those acts.
4. Motivation: there must be a reason or desire to perform the learned behavior. This process can be impaired by the learner's beliefs about their ability to succeed i.e. self-efficacy. Someone may observe a behavior and believe it will help them acquire their goal states but with low self-efficacy they simply give up.

This framework gives us a new lens to understand our faulty assumptions. Your team is not attentive to you as a potential model because they do not identify with you or see you as an "elder engineer" to learn from.  The inherently low-visibility nature of technical work makes it difficult to observe/encode/retain the critical concepts. Inconsistent or incompatible rewards/recognition schemes impinge motivation. Your over-involvement reduces opportunities to rehearse and reinforce reproduction. Goal states, values, and beliefs misaligned with the demands of the role and needs of the organization cause all 4 conditions to misfire.

Bandura's theory is the accepted contemporary account. That said, psychologists have studied observational learning for more than a century. There are multiple outmoded theories and misconceptions that are relevant to dispel:

• Affective (emotional) response is not necessary for vicarious acquisition and reinforcement, in fact vicarious learning can occur even when affective responses have been chemically or surgically blocked.
• A response (skill) does not need to be taught before observation can affect it. Observation can successfully convey entirely novel, never-before-seen behaviors and abstract rules.
• Observation of an action alone cannot elicit a drive to emulate that action. That is to say, behavior will not be imitated unless reinforcement follows. Reinforcement does not always take the form of an explicit reward/punishment, it can also occur via normative social pressure or internal beliefs/goal states.

When conditions are right, observational learning is extremely powerful. It's the basis for much of early childhood development. Considering that language and formal instruction are relatively modern inventions (anthropologically speaking), it really was the basis for all learning for thousands of years.

"The time, effort, and grief saved can be vast. Learning by observation also minimizes the need for overt trial and error practice. Even elaborate concepts and cognitive strategies are vicariously acquired.  Also, most of our cultural heritage is socially transmitted. If it were not,  each generation would need to reinvent algebra and the means to harness electricity. Witnessing others' actions at solving problems, and the  environmental effects so produced, together foster observational learning."

– Ted Rosenthal & Barry Zimmerman, Social Learning and Cognition.

Now let's put all of this theory into practice.

Effective Leading by Example Builds Credibility

The conditions for observational learning must be right. As we've seen, those conditions aren't naturally found in the workplace. Moreover, there are many models that may be observed in the workplace. Imitation is first and foremost a sociocultural mechanism of transmitting in-group identities. Humans feel compelled to acquire the habits/traits/behavior of their identity groups in order to become accepted by those groups. We have an evolutionary need for the protection of the herd. You are not a herd, you are one manager. Statistically, your team is observing others more than they are observing you. There are more bad examples than good in the herd at large.

Cutting through the noise requires attention. As established above, attention is mediated by how much the learner likes or identifies with you as a model. When you step onto the field and do some hands-on technical work, you build credibility as an engineer rather than as a people manager. When you pick up some important but painful toil (holding a pager, fixing a broken integration test), you show that you're not above hard work. When you become recognizable to your team as "one of them," a fellow engineer, they will be more likely to take note of the behaviors you role model.

Sociology defines three paradigms of authority/influence:

1. Traditional authority is based on established customs, traditions, and history. It's a long-standing form of authority, often inherited or passed down through lineage or religious practices. Think of a monarchy.
2. Charismatic authority stems from the personal qualities, charisma, and magnetism of a leader. It's associated with individuals who inspire loyalty and devotion through their exceptional personality, heroism, or conviction.
3. Rational authority is based on means-ends logic where authority comes from overall effectiveness in achieving a stated purpose and the role one plays towards that end. It's associated with bureaucratic structures (think governments and corporations) exactly because those structures codify a dominant way of achieving goals replete with elevated roles (managers, police officers).

We've established earlier that modern-day egalitarian work cultures and the politics of large companies means we cannot rely upon traditional or rational authority. So instead, leading-by-example cultivates a type of charismatic authority that lends your beliefs and actions weight they would otherwise lack...lubricating the influencing process.

Transitioning from "Doing" to "Coaching"

The credibility you earn can be used as the basis for the all-important "here's what success and growth looks like in your role" conversation. This isn't just some perfunctory reading of the job responsibilities. This is a deep, visceral, almost brutal heart-to-heart. Your goal is to probe deeply and elicit vulnerability to learn what your coachee really deeply desires out of their job/career without all the defensive architecture and corporate sterilization. You can see how this sort of thing can only happen if there is an established basis of credibility, intimacy, and rapport. This comes from working elbow-to-elbow.

With an understanding of what they really want, you can begin discussing the ways that is or isn't in alignment with what the organization needs or is willing to reward/recognize. Coachees can dialectically explore whether they want to be "reprogrammed" with a new set of goals better aligned with the organization. This will ensure their attention is directed at the right behaviors to emulate, and that the necessary reinforcement will be forthcoming so as to sustain motivation, and thereby, continuous learning.

Skipping this conversation altogether, or doing it poorly, is not an option. Leaving your reports out of alignment will leave their growth effectively up to chance. In truth, this was me and my new team. Initially, I skipped these conversations with my staff engineers. Due to extreme seniority and long tenure, I errantly believed they would already be well-aligned with the organization. In one particularly bad case, an aspiring staff engineer put forth tremendous effort to complete key projects in record time, only to find out they wouldn't be promoted due to focusing too much on "tactical work" over "strategic influence." I had dropped (what were to me) obvious hints and opportunities for strategic influence all year, and went out of my way to role model the necessary behaviors. But they never took the bait and just kept focusing on more immediate tasks. Ther resulting perfectly-acceptable-yet-average results failed to substantiate a promo. The shock of a no-promo was sufficient negative reinforcement to jumpstart the learning process but the pain was completely avoidable. All it takes is one conversation. (In fact, another important takeaway is to keep re-attempting this conversation if the first time doesn't connect). Observational learning depends on the learner's capacity to recognize concepts as critical and germane to their goals...in this case, getting promoted.

Even if you go no further than this hard 1:1 where you get honest and deep about what people want and what it will take to get there, you will be advancing steadily towards improving the team's performance. From this foundation, further role modeling should emphasize highly visible actions that put the abstract reasoning, intermediate goal states, and subordinate skills on display (e.g. pair programming, stream-of-consciousness how-I-solved-it docs, etc) to support encoding/retention.

Back to the story of my struggling infrastructure team. I had to walk before I could run. By getting hands-on and leading by example, I built a better understanding of the constraints and demands placed on my engineers...the tools and options at their disposable and what was truly achievable and what I could realistically expect from them. With that in hand, I set out to do the real job of coaching. I was eventually able to turn around those "chronically stuck" folks mentioned earlier by having exploratory coaching conversations wherein I came to fully understand their worldview. I then used my hard-won credibility to influence them towards more productive orientations aligned with what the team needs and the organization would reward. Where possible, you should try to identify their own unique genius and how that can be leveraged rather than always just "reprogramming" them. Either way, this is a delicate operation filled with crucial conversations where the entire working relationship is on the line. Done well, you can transform someone, unlock the next stage of career growth, and build a life-long follower. I leverage a cocktail of techniques from many sources including Coaching for Performance, Humble Inquiry, Nonviolent Communication, and Multipliers.

In summary, leading by example is a laudable ethic, will go a long way towards establishing an "everybody cleans" culture, and might earn you some credibility to do the real job of coaching. But as a standalone coaching technique it's extremely weak and limiting. It depends on observant/aware reports, alignment on what the role demands, a culture where you are an unequivocal elder, time to actually do the job well and role model the right behaviors, the authority to actually recognize/reward adherents, and a way to actually directly observe the work at hand.