Leading By Example Considered Harmful
Ok not really but it isn't a magic panacea either.
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:
My team has the same goals as me (i.e. business impact).
My team is motivated to grow their role at the company.
My team is not acting optimally towards that objective.
Therefore this must be because of missing knowledge.
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.
