The Power of Average Days

Leadership Is Built in the Margins of Ordinary Days

Nobody becomes a great engineering leader on the day they ship the transformative product, survive the all-hands, or finally get the board to stop second-guessing the roadmap. They become one in the 6:47 AM Slack message they send to unblock a junior engineer before standup. They become one in the ten minutes they spend reading a post-mortem before a meeting instead of during it.

The mythology of leadership is full of inflection points — the pivot, the hard conversation, the courageous call. Those moments matter. But they are downstream of something quieter and far more demanding: the daily reps. The unglamorous, unremarkable accumulation of small, deliberate actions that nobody applauds because they happen too slowly to register as progress.

Every CTO or VP of Engineering who has built something durable will tell you the same thing when pressed: the culture didn't come from the all-hands speech. It came from what they did on a Tuesday in February when nothing was on fire and there was no external pressure to perform. That Tuesday is where leadership actually lives.

This is not a motivational observation. It is an engineering one. Systems that perform reliably under load are not built through heroics — they are built through deliberate, boring, consistent design decisions made over time. Your leadership is a system. It should be engineered the same way.

The Compound Effect of 100 Ordinary Days

Compound interest is a concept engineers understand intuitively when applied to technical debt — a small shortcut today becomes a structural problem in six months. The same mathematics applies to leadership behavior, but we almost never model it that way. A 1% improvement in how you run a team, applied consistently over 100 days, does not produce a 100% better team. It produces a fundamentally different one.

Consider what actually changes when a VP of Engineering commits to reading every sprint retrospective instead of delegating the summary. After a week, nothing visible shifts. After a month, they start noticing a pattern in where estimates break down — always in the integration layer, always when two squads share an interface. After three months, they've restructured the ownership model around that insight. The retro reading wasn't the intervention. The consistency was.

The compounding is not linear and it is not always visible to the person doing the work. This is what makes it psychologically difficult. Humans are wired to respond to feedback loops, and the feedback loop on daily leadership reps is delayed by weeks or months. The engineer who writes clear, specific code review comments every single day for a quarter will have raised the baseline quality of their team's output — but they will never be able to point to the exact day it happened.

What makes this harder is that the absence of compounding is also invisible in the short term. A leader who skips the hard conversation, who lets the vague ticket slide, who approves the architecture shortcut because the quarter is tight — none of those decisions look catastrophic on day one. They look catastrophic on day 90, when the team is moving at half speed and nobody can articulate exactly why.

The practical implication is uncomfortable: you cannot evaluate your leadership quality by how you feel today. You can only evaluate it by the trajectory of your behavior over a meaningful window of time. Consistency is not a virtue in the abstract. It is the only mechanism through which leadership quality actually propagates into organizational outcomes.

Real Work: The 1:1 as Infrastructure

The 1:1 is the most underrated piece of engineering leadership infrastructure in existence. It is also the most commonly degraded one. The moment a calendar gets tight, the 1:1 is the first thing that moves — because it doesn't have a Jira ticket, a deadline, or a stakeholder watching. It feels optional in a way that a sprint review does not. This is a category error that compounds badly.

A 1:1 that happens consistently, at the same cadence, with a clear structure and genuine attention is not a meeting. It is a signal. It tells the engineer on the other side of the table that their trajectory matters to you independently of the current sprint. It creates a container where problems surface before they become incidents, where ambition gets named before it becomes attrition, where misalignment gets corrected before it becomes a reorg.

The pattern that breaks teams is not the leader who never does 1:1s — that person usually gets feedback fast enough to course-correct. The pattern that breaks teams is the leader who does 1:1s inconsistently. Who shows up fully present for three weeks, then reschedules twice, then runs one from their phone in a cab. The inconsistency itself becomes the data point. The engineer stops bringing the real thing because they've learned the container isn't reliable.

Engineering leaders who take 1:1s seriously as infrastructure treat them the way they'd treat a critical cron job: you don't skip it because you're busy, you don't run it at half capacity because something else is on fire, and you absolutely monitor whether it's producing the expected output. The output of a healthy 1:1 is not a warm feeling — it's a clear picture of where each person on your team is stuck, what they're optimizing for, and what you need to do differently to unblock them.

The leaders who do this consistently — not brilliantly, not with perfect frameworks, just consistently — end up with something that cannot be manufactured any other way: they know their people. Not their performance review summaries. Their people. That knowledge is the substrate on which every other leadership decision gets made with higher accuracy and lower risk.

What Consistency Actually Costs

It would be dishonest to write about consistency as a leadership practice without naming what it costs, because it costs something real. Consistency in the domains that matter — the 1:1s, the code review culture, the post-mortem rigor, the architectural standards — requires that you deprioritize something else. There is no version of this that is free. The calendar is zero-sum and so is cognitive bandwidth.

The leaders who sustain high consistency over long periods are not the ones with more time. They are the ones who have made explicit, often painful decisions about what they will not do consistently. They have stopped attending the status meetings that produce no decisions. They have stopped writing the detailed quarterly updates that nobody reads. They have gotten ruthless about protecting the recurring practices that compound, at the expense of the one-time activities that feel productive but don't.

There is also a psychological cost that is less discussed: consistency in leadership requires tolerating the absence of immediate reward. The 1:1 you ran well today will not show up in any metric this week. The architectural conversation you steered toward long-term maintainability will not be celebrated in the sprint demo. You are making investments in a fund that doesn't publish daily returns, and that requires a specific kind of conviction that is genuinely hard to sustain without evidence.

The leaders who sustain it tend to have internalized a clear mental model of how their daily behavior connects to organizational outcomes — not as an article of faith, but as an empirically derived belief based on watching what happened when they were consistent versus when they weren't. They've seen the team that had reliable 1:1s weather a reorg without losing three engineers. They've seen the one that didn't. The conviction comes from the data, not the inspiration.

Personality Is the Variable You're Not Controlling For

Here is the part most engineering leaders skip: consistency is not uniformly difficult for everyone on your team, and it is not uniformly difficult for you in every domain. The reason some leaders sustain rigorous 1:1 cadences effortlessly while their peer down the hall can't hold one for three weeks running is not discipline. It is personality structure — specifically, the underlying traits that govern how individuals respond to routine, ambiguity, interpersonal obligation, and delayed reward.

HEXACO personality science gives engineering leaders a precise lens for this. The model captures six core dimensions — Honesty-Humility, Emotionality, Extraversion, Agreeableness, Conscientiousness, and Openness — that predict, with meaningful accuracy, how a person will behave not in high-stakes moments, but in the ordinary ones. Conscientiousness, for instance, predicts exactly the kind of sustained, self-directed follow-through that consistency requires. But it also interacts with Emotionality in ways that matter: a high-Conscientiousness leader with high Emotionality may sustain their own practices while absorbing so much of the team's anxiety that they become a bottleneck rather than a multiplier.

LU Teams is built on this insight. The friction that appears in engineering teams — the 1:1 that always gets rescheduled, the retro that never produces action items, the architectural decision that keeps getting reopened — is rarely a process failure. It is almost always a personality dynamics failure. Two people with incompatible trait profiles are interacting in a context that neither of them has been given the language to navigate. The result looks like a performance problem or a communication breakdown, but it is something more structural.

When you understand the HEXACO profiles of the people you lead, you stop trying to solve personality friction with process fixes. You start designing the actual conditions under which each person's natural tendencies produce compounding value rather than compounding drag. The VP who knows that their most technically brilliant engineer scores low on Agreeableness and high on Openness doesn't schedule them for the consensus-heavy roadmap session — they bring them in for the hard architectural review where dissent is the point. That is not accommodation. That is precision engineering applied to human systems.

The ordinary day looks different when you have this data. The 1:1 is not a generic check-in — it is a calibrated conversation shaped by what you know about how this specific person processes feedback, tolerates ambiguity, and signals that something is wrong. The consistency of the practice is the foundation. The precision of the execution is what turns that foundation into something that actually compounds.

Keep Pedalling

The image that keeps coming back when thinking about leadership consistency is a cyclist on a long climb. Not the sprint, not the descent — the climb. The cadence that looks almost boring from the outside, the effort that produces no dramatic visual change in position for long stretches, the discipline of not attacking the grade too early and burning out before the summit. The work is in the pedalling. The summit is downstream of the pedalling. You do not get to skip to the summit.

The leaders who build great engineering teams are not the ones who had the best ideas or the most charisma or the highest tolerance for chaos. They are the ones who showed up on the ordinary days and did the ordinary things with enough care that those things compounded into something extraordinary. They ran the 1:1s. They read the retros. They pushed back on the architecture shortcut in the planning meeting nobody wanted to be in. They did it again the next week.

There is no secret here, and that is exactly what makes it hard. The path is visible. The discipline required to walk it is the entire challenge. If you are building a team right now, the question is not what you should do differently. The question is what you will do consistently, starting today, that you will still be doing in 100 days. That answer is your leadership strategy. Everything else is commentary.