First, an important caveat: even in an imperfect world, No Estimates would be the way to go. That however, requires the entire organization to drink the same cocktail. In the absence of that rare scenario, there are other ways to get there.

• The central question for leadership is "how long will it take to build feature X?"

• Engineers have to answer that question at a time that they know the least about the problem and solution.

• There's also the pervasive tendency of everyone but engineers to greatly underestimate the cost (usually means time) to build something

At Appsmith, these very common problems existed, but we also had extremely progressive and critical minded leaders who allowed us the freedom to test, experiment and learn together. That gave me the opportunity to think through the fundamentals, and clarify the problems at the root:

• Executives complained the team was slow

• PMs had no idea what anything cost to build

• Engineers felt they were just cogs in a machine with no say in their own timelines

We all wanted to fix this. One of the superpowers of a good engineering manager is knowing what 1 or 2 interventions will be most effective from the 40,000 best practices in the market. So, simply adopting DORA or something similar was out of question. The main thing to solve in the situation was the accuracy of our estimates. And my secret desire was to just be done with estimates some day. We smashed the first one, and got pretty close to solving the second.

The need for economic analysis

Engineering is probably the most important function in the company, but in most companies they operate without any understanding of unit of work. As Sidu puts it, a feature is not the unit of work, it is the unit of distribution. Variably called effort, cost, etc., it is the thing the team invests to realise downstream value. And as units go, it needs to be a standard, interchangeable measure. The tongue-in-cheek-ness and the audacity of applying this concept to building software is intentional.

Building the habit

We already were using a kanban board, and the straighforward approach I introduced to the team was t-shirt sizes. During our fortnightly iteration planning, the team estimated every planned item together. We also maintained a doc to describe with examples the types of tasks for each tshirt size. This was the first half of the story. The first habit.

What I needed out of all this was the cycle time. By standard definition, this should be the time it takes to build something from idea to live. I took the liberty of tweaking that meaning in two ways:

• so that it pertains to the unit of work instead of the unit of distribution. (reasons explained in the previous section)

• start the clock when a task goes to "in progress" and stop it when it reaches "done". (we didn't want to be fussed with all the chaos upstream and downstream at this point)

Finally, I built an Appsmith app to do these and several other calculations. I wanted a graph that shows, broken down by tshirt size, the median of times it took our team to take a task from start to end. Of course, as we went along I had to make a couple of minor tweaks e.g., to exclude weekends.

A world emerges

Here's the graph. You can see this live on the app too.

In the beginning, it looks like Eminem's spaghetti. That was expected. But you can see rationality setting in over time. This is the outcome of the team learning the meta information about their work, learning to trust each other, and learning the value of slowing down and speeding up as needed. The graph ends at the dream state we all aspire to:

• XS and S tasks take ~1 day

• M tasks take ~2 days

• L tasks take ~3 days

• XL tasks take ~6 days

The discipline of decomposition

This is one part of the story. Remember, the secret plan for world domination was to ultimately get rid of even having to do these estimates. For that, the team needs to also get insanely good at decomposing tasks into the simplest possible increments. So, a second graph. A simple reporting of the monthly number of taks broken down by the estimate size. We want the larger ones to vanish. We were well on our way to it until the end of reporting (my leaving the team).

By breaking complexity into smaller, discrete units, we reduced the risk profile of our releases. We stopped trying to ship monoliths and started shipping predictable increments. This skill is perhaps the most valuable technical lesson the team carried forward to their next roles.

Professional predictability

By making our output measurable, we solved the original frictions:

• Executives were relieved of the "slow" narrative because we could finally project capacity with confidence.

• Engineers regained agency, as accurate estimates protected them from the chaos of over-commitment.

• PMs could finally make trade-offs based on the actual cost of building.

In the end, engineering leadership is about creating a system where engineers can work with clarity. We didn't just ship more code; we built a culture of predictability that served the business and the engineers equally, while learning to take more pleasure doing it.

In Buddhist thought, maya isn't a claim that the physical world is a hallucination; it’s a warning that our perception of it is a construction. We mistake a transient set of social arrangements for a permanent reality. Of course the ladder is real in its consequences. It dictates your compensation and your standing in the social hierarchy, but it is illusory in its meaning, and detachment is the first step towards peace and self actualization.

The systems trap

In The Elegant Puzzle, Will Larson describes organizations as complex systems that are constantly in flux. When we look at a career ladder through this lens, we see why it feels so unstable. A "Senior" title isn't a badge of merit etched into your soul. I’s a temporary state within a system that includes your manager’s advocacy, the company’s current growth phase, and the prevailing market conditions.
The ladder is a tool for legibility. Organizations need a way to categorize thousands of people, so they create rubrics. But as Larson points out, the map is not the territory. We often fall into the trap of optimizing for the rubric, chasing high-visibility projects or "impact" metrics, while neglecting the actual craft of engineering. We trade the messy, non-linear reality of becoming a better builder for the neat, linear illusion of the next rung.

The superpower of situational clarity

This post is not titled "Ladders are bullshit", because I don't think they're completely useless. The Ladder is a tool of convenience for the organization, but it can become an unhealthy attachment for the individual. Therefore my exhortation to practice detachment. Also therefore, the title, "The Ladder is Maya".

Seeing the ladder as maya isn't a call to "opt out." We all want good things, and our needs change depending on where we are.
The goal is situational clarity.

At different stages, the most important thing might be the money, the title, or the meaningful work itself. Go ahead and chase that promotion if you are doing it consciously to achieve a specific end.
The danger is when we stop using the ladder and start being used by it. When we treat the ladder as the only reality, we lose the ability to negotiate. We become reactive, living in a state of scarcity thinking where our self-worth is tied to a promotion committee’s verdict.

Confession

I’m currently navigating this tension myself. I am genuinely enjoying my role as an Engineering Manager. I’m finding a specific kind of growth in the day-to-day operations, chasing the "perfect execution". It looks to me like I can only chase this close to the ground, working directly with engineers.

The maya of the ladder says my next move is "up." I should be aiming for the next level of abstraction: Manager of Managers, Senior EM, Director. The ladder dictates that more distance from the execution is the only definition of success.
But I’m not done with this level yet. To jump to the next abstraction just because the ladder says it’s there would be a failure of clarity. It would be trading a felt sense of mastery for a title that might actually take me away from the very work that I enjoy and that is currently making me a better leader. That time might come in the future, or it might not. The point is irrelevant. That's the argument.

So let's reframe this

When you recognize the ladder as a construct, you get a tighter focus on your ambition. You stop seeing a reorg or a "delayed" promotion as a cosmic injustice and start seeing it as the natural shifting of a temporary structure.

It's a game, after all. The org is playing it's game, and you're playing yours. Occasionally, the outcomes align and that's great. Sometimes, they don't and that's ok. Walk with a lighter step knowing that the rhythms will eventually match, even if temporarily. Meanwhile, create your own music: hone your craft, nurture those relationships and curate your inner stability: all these give you a much better competitive edge than a made up title.

There is a familiar pattern, especially pertaining to spaces like Round Table India, where difficult ideas are articulated early, first, and often at personal cost.

An idea appears first in the spaces where it is produced under real stakes: small publications, activist writing, essays forged under real consequences, long before panels or podcasts decide it is safe. It circulates there quietly. It does its work without applause. Then, later, the same idea reappears elsewhere, smoother, safer, detached from risk, spoken in the accent of discovery.

What happens here is the hijack. Very little labour is involved. Ideas are not refined or extended; they are simply taken from risky contexts and restated in safer ones, where they can generate authority, legitimacy, and reward. There are jobs, book commissions, brand recognitions, yada*3: all this for the discerning connoisseur of ideas, the ladies and gentlemen of taste who happen to pass by little items of curiosity and interest that they can take back to show their friends, claiming them as their own.

This is not mere "plagiarism". It is more efficient than that. Maybe no sentences are lifted. No rules are broken. What moves upward is not text but thought: positions, framings, conclusions now severed from the conditions under which they were first produced.

I first encountered this problem years ago through Hatred in the Belly. The essays in that book named the phenomenon directly: how Dalit, Bahujan and Adivasi thought is mined, sanitised, and reissued by more privileged actors who then accrue disproportionate authority for it.

The responses to those essays were revealing. Instead of engaging the argument, critics reached for a familiar set of evasions:

• So are you saying only Dalits should write about Dalits?

• Are ideas owned by caste now?

• Isn’t this reverse exclusion?

These were not mere misunderstandings. Nor are they to be taken for bumbling of congenital idiots. They were cunning refusals. Each one sidestepped the actual claim that power determines where ideas are allowed to appear, who is authorised to speak them, and which spaces remain structurally inaccessible to their producers.

I noticed the same pattern again recently after publishing an article on RTI that received little visible traction beyond friends and family, but seemed to echo back soon after through podcasts, panels, and social media commentary. The ideas were familiar. The confidence with which they were presented was new.

This is not about my article. And it is not only about credit or citations.

The deeper issue is that knowledge is repeatedly regurgitated in spaces that are structurally inaccessible to those who produced it.

The harm lies not merely in misattribution, but in exclusion: ideas circulate upward into rooms their authors are never invited into.

A metaphor from craft makes this clearer. Imagine a tribal artist whose work hangs in a museum they themselves would not be allowed to enter. All the celebration and accumulation of prestige is now displaced, away from the artist. The producer remains outside the institution that now claims stewardship over their work.

I mentioned podcasts and panels. Public media offers the most visible version of this extraction. Academia is where the consequences are starker, this is where the real loot is.. There, unattributed ideas become citations, citations become careers, and the original producers—often young, precarious, and already disenfranchised—vanish from the record. What is lost is not just recognition, but access, livelihood, and historical memory. It matters who gets cited. It matters more who gets invited, platformed, hired, published, and archived.

My own position is relatively comfortable. I am not building a career in this space, nor am I dependent on institutional recognition. That distance makes it possible to write as an observer rather than a claimant. It also clarifies the asymmetry. Many writers do not have this buffer. For them, the bargain is brutal: do the dangerous, first-order thinking, and watch it circulate in rooms you are barred from.

This is best understood as a problem of labour. Not skilled transformation, but unearned capture. The producers often take tremendous risks in naming what cannot yet be said, absorbing backlash, speaking when it is unsafe. Above them sit others who do not improve the work, but merely repeat it once the danger has passed, converting risk they did not bear into authority they did not earn.

This is not a failure of individual ethics. This is not a call to action for mass social media cancellations. That's just performative circus that we've seen usually ends up benefitting the overlords yet again. No. This is how the economy of ideas is organised in a caste society.

Spaces like Round Table India continue to shape discourse upstream. They determine what can later be said elsewhere. That influence is real, even when it does not appear in trending lists. But this is not their bonded labour, a duty to their oppressors.

The fiction worth disabusing ourselves of is not that ideas should circulate, but that circulation without risk, effort, or consequence is neutral or happenstance. Ideas do not rise on their own. They are NOT produced in sanitised laboratories. They are taken far from their place of germination, upward. So the privileged can reap the rewards of having said them safely.

Kent Beck is not wrong. Not entirely, at least.
He's responding to something many of us have experienced firsthand: the moment a product stops feeling like it’s made for people and starts behaving as if it were built for a dashboard. You can almost imagine the idiot PM getting that underserved promotion by annoying you, the user, no end.

Nonsense notifications, bullshit engagement, and that sudden realisation of a thoroughly enshittified experience. When Beck warns us about enshittification, or about the tyranny of metrics, I find myself nodding violently. Yes. We’ve seen this movie. Some of us even starred in it.

So let’s start with respect. The discomfort that Beck is naming is real. And it goes without saying, the attention he has in our industry is thoroughly and richly earned.

So the following isn't disagreement, but an exercise of teasing out a bit of nuance. Maybe also a gentle and respectful roast.

My central argument is that Beck's impatience is better directed at praxis rather than at theory.

If I'm being abtuse, it's mindfully so, to saturate the arguments so that they stand out more sharply. A careless reading of Beck's article would end up in the following summarisation: Metrics did this to us. We tried measuring things. It went badly. Therefore, the measuring itself must be suspect. Better to retreat to principles, instincts, craftsmanship, and judgment. Those older, nobler tools that don’t vibrate on your wrist at inconvenient moments.

Yes, yes and yes. That's what we did. But, are we sure that’s what we set out to do?
Because in most cases, we didn’t really try metrics. Not in the way one tries to become good at something difficult. What we tried was a thinner version: random and/or cargo culted dashboards (often without ownership), haphazard targets without context, proxies promoted into judges. We asked metrics to replace thinking rather than provoke it. When the results disappointed us(as they almost inevitably do) we are at a point of declaring the whole enterprise a waste of time.

This move is understandable. It’s also a little like following a recipe, but replacing all the ingredients, and then complaining that the recipe itself is rubbish.

Or, like driving with navigation. Keeping your eyes glued to the map and away from the road is definitely gonna end up in disaster. Doing the opposite, while seemingly safe, is still ineffective.

Distance changes everything

When feedback is close, immediate, and rich, metrics are often unnecessary and sometimes absurd. A craftsperson shaping wood doesn’t need a KPI for smoothness. A developer debugging code they just wrote doesn’t need a weekly report to know something is broken. In these contexts, introducing metrics doesn’t add rigor; it strips information away, with the added bonus of being perfectly annoying.

The other extreme is an explosion of distance. Millions of users, dozens of teams. Delayed, diffused, and noisy feedback. Here, refusing to measure anything at all is reckless. You can't scale intuition, you can't calibrate the judgment across several teams of engineers. Some form of instrumentation becomes vital.

Metrics, in other words, are a compensatory technology for distance.

They exist because proximity, immediacy, and fidelity of feedback have been lost. That indeed is tragic but metrics are a way of clawing back some ways to achieve clarity.

And this is where things reliably go wrong.
Metrics are introduced to cope with distance, but then almost inevitably reinterpreted as if they had restored proximity. A proxy for feedback is mistaken for feedback itself. Numbers stop being prompts and start being verdicts. Conversations close instead of opening. Optimization becomes local, relentless, and strangely hollow. Yada*3.

That is not a failure of measurement. It’s a failure of interpretation. (Dammit this almost feels like a religious cleric offering a vehement defence lol.)

The false comfort of extremes

Faced with this, our industry has a habit of swinging between two comforting extremes.

• On one side is metric fundamentalism: the belief that with enough dashboards, we can automate judgment away entirely.

• On the other is metric rejection: the belief that the very act of measuring is what corrupts us, and that wisdom lives safely on the other side of numbers.

Both positions are oddly impatient.
Principles without operational anchors dissolve into vibes. They sound good, feel right, and quietly drift when pressure arrives. Metrics without principles harden into weapons. They look objective, feel decisive, and slowly eat the thing they were meant to protect.

The harder, less fashionable work lies in holding the two together without letting either pretend to be sufficient on its own.

What metrics are actually for

Used well, metrics are not answers. They are invitations.
They exist to surface tensions, provoke questions, and force trade-offs into the open. A metric that ends a debate has already failed. A metric that starts one, even an uncomfortable one, is doing its job.
This requires patience, governance, and admitting that numbers are evidence, not authority. And it requires becoming a student of the thing, rather than trying it briefly, badly, and then declaring it corrupt.
That work is slower than declaring allegiance to one camp or the other. It doesn’t fit neatly into slogans. And it doesn’t let us off the hook.
Which may be why we’re so tempted to skip it.

A boring responsibility

If you’re reading this and nodding along, chances are you’re in a position of influence. You’re probably reasonably well paid. You probably oscillate like most of us between confidence and a low-grade, ever-present imposter syndrome. None of that disqualifies you. In fact, it’s part of the terrain.
One of the highest-leverage things leaders can do is surprisingly unglamorous: become good stewards of value.

That means being the person who gently slows the room down when a metric is being treated as a verdict rather than a prompt. It means asking, “What question is this number actually raising?” instead of “How do we make it go up?” It means reminding teams again and again that metrics are evidence, not authority.

Sometimes it means being the buzzkill.
Not the moralistic scolder-in-chief. Not the unilateral decider. But the person who keeps reopening the conversation when it’s trying to prematurely close. The one who notices when optimization is drifting away from purpose and deftly shepherds the discussion back toward principles: What are we trying not to lose here? What would success still look like if this number went down?

This is not about rejecting metrics. It’s about refusing to let them replace thinking.
And doing this well without sounding sanctimonious, without undermining agency, without turning judgment into fiat *is the work*.

It’s subtle. It’s social. It requires taste. It rarely shows up on a dashboard. But it can be immensely rewarding. If you do it well, you can take deep pride in it because it's so woefully rare.

A note on abstraction and an open door

This is an abstract piece. That’s not because the concrete examples are missing, but because they are many, and personal. I have first-hand experiences of metrics doing real harm, and of metrics doing unmistakable good.

Those stories deserve to be told properly, with specificity and care. I've been meaning to write about them, and probably will soon.

And because this framing resists easy binaries, it should invite disagreement. Hey I'm still learning this stuff, so don't accept the authority of the written word. I'm really hoping to see some further debate. If you think metrics are more dangerous than I’ve allowed for, say so. If you think principles collapse faster than I’ve suggested, argue that case. If you believe the entire enterprise of measurement in complex human systems is irredeemable, make that argument. These are not heretical positions. They are substantive ones.

What this piece pushes back against is impatience with complexity, with apprenticeship, with the slow work of stewardship. If there is a better way to hold metrics and judgment together without letting either dominate, that conversation is worth having in the open.

In the years between 1911 and 1917, as the world’s great powers vied for territory and prestige, the last unclaimed spaces on Earth became arenas where national ambition played out. These remote frontiers were stages to prove technical skill, endurance, and pride. The race to the South Pole was about maps and flags, sure, but it was also about the way leaders chose to lead.

Three names are forever etched in our memory in this context: Roald Amundsen, Robert Falcon Scott, and Ernest Shackleton. Each led expeditions into the most inhospitable place on Earth. Each left behind stories that have become legend. And each embodied a different archetype of leadership.

Amundsen, the meticulous planner. His South Pole expedition was a masterclass in preparation and risk mitigation. He studied the Inuit, learned to handle sled dogs, mastered the use of skis, and taught himself to be deeply tuned to the icy environment he was entering. His team reached the Pole first and returned without loss of life. It was the leadership of precision and discipline.

Scott, scientist and the idealist. His expeditions were loaded with scientific equipment and driven by a sense of national pride. He balanced exploration with research, sometimes at great cost to speed and safety. His 1911–1912 South Pole party arrived weeks after Amundsen’s, only to perish on the return journey. Scott’s name is etched in our memories forever as a tragic hero. As a leader he was deeply and very simply principled. The depth of character of Scott and his men is inspirational.

Shackleton, the crisis leader. His 1914–1917 Endurance expedition never even reached the continent’s interior. Trapped in the ice for over a year, Shackleton kept his crew alive through impossible conditions, bringing every man home. He is celebrated today for his unbreakable commitment to his people.

These are heavy simplifications of complex, flawed, and remarkable humans and extremely complex projects. Real life and the role of leadership is always far, far messier than what I’ve condensed in the paragraphs above. Amundsen’s precision was not infallible. Scott’s "failure" was not without so many stories that teach and inspire us today. Shackleton’s charisma had limits. But even simplified, these archetypes are vivid and useful.

In modern engineering leadership, we encounter these types often. The Amundsens who design for every edge case and aim to remove all uncertainty before execution. The Scotts who chase bold visions and balance delivery with deep research. The Shackletons who keep the team intact through chaos, setbacks, and near-catastrophes.

The outcomes in Antarctica are well known, but for our purposes, the outcomes are not the lesson. Given a careful and rigorous decision-making process, there are no bad decisions. Good leadership is about reacting and responding well. First, about making the decisions that best fit the constraints and the context, and second, in shaping the circumstances to proactively change the environment and constraints. A company needs different kinds of leaders, and the wisdom to know which is needed when.

As for me, I am instinctively closer to Shackleton: steady in a storm, drawn to the work of keeping the crew together when things go wrong. But I have been on a rewarding journey to learn from Amundsen. Learning to add his rigour and precision to my instincts has been a rewarding and enjoyable journey. In all this, I think, I've stumbled into the Scott arena of idealism and deep research style. This is an ongoing journey, self awareness thankfully comes to me at intervals, and on mornings such as this one, I am able to reflect more honestly about myself.

The result, I hope, is a leadership style that can navigate the unknown and the chaotic, while also seeking to nurture a kind of growth that is pleasurable and rewarding.

If you want a soundtrack for this reflection, you could do worse than listening to Departure Songs by We Lost The Sea. Especially the first track, “A Gallant Gentleman,” inspired by Lawrence Oates, a member of Scott’s doomed party. Here’s my tribute to that album.

Every run-of the-mill company says they believe in teamwork, then turn around and measure, plan, and staff as if individual output is all that matters. The result is fragile delivery, pointless heroics, and a constant, low-grade chaos that everyone has quietly accepted as “just how things are.”

So, it just makes sense that the team is the most granular unit of delivery for most practical purposes. If you’re not optimising for the team’s output, you’re optimising for nothing. The team is the least count. Individual performance is important for delivery of course, but in an indirect way.

This is football and not tennis. You win together, or you don’t win at all. The scoreboard is for the team, not for the individual with the flashiest footwork or most points in isolation.

I'll fight you on this, this is a hill I will die on.

The Curse of the "Finished" Engineer

One common anti-pattern looks like this: “Oh, John’s finished his tasks, so he can help out on that other project.”

No. Just… no.

Work doesn’t get magically faster because you dropped in someone who doesn’t know the domain, hasn’t been part of the design conversations, and isn’t aligned to the shared goal. It actually gets much, much slower and much, much shabbier. Context-switching is expensive, onboarding mid-stream is expensive, and you’ve just fractured the focus of your team.

If a project is behind, that’s a team problem. You swarm on it as a team. You adjust scope, priorities, or staffing as a team. You don’t pull individuals like interchangeable parts off an assembly line.

The Fantasy of Parallelism

Another flavour of the same sickness is this: a team of five people running five parallel projects. This looks efficient on a roadmap slide. In reality, you’ve created five under-resourced efforts, each moving too slowly to matter, and each doing things in suboptimal ways that will come back to bite you later. You're raising a pack of biting, rabid angry wolves that will follow your team forever.

Little’s Law and the Theory of Constraints tell us what every good coach knows: reduce work in progress, focus your capacity, and you deliver faster. Running at “full capacity” on paper is the enemy of throughput in reality.

Teams Learn Together

Peter Senge argues in The Fifth Discipline that the only sustainable competitive advantage is an organisation’s ability to learn faster than its competition. That applies to engineering teams tenfold.

When you optimise for team-level delivery, you create the space for shared learning. More here. One person’s breakthrough becomes everyone’s win.

Debugging a nasty production issue? You swarm it.

Building a new service? You pair up.

Refactoring a core module? You bring others in to understand why and how.

Compare that to the “every person for themselves” model, where knowledge sticks to individuals like lint. Those people become bottlenecks, they burn out, and when they leave(literally or even just mentally), they take their knowledge with them.

Don't Ignore the Data

The data is clear. The Accelerate research (Forsgren, Humble, Kim) and the DORA metrics are not ambiguous:

• Fewer handoffs

• Shorter cycle times

• Lower work in progress

• Higher deployment frequency

…all correlate with higher performance.

The Curse of the Gifted Programmer was an email written in 2000. The Mythical Man Month was first published in 1975. Don't fool yourself into thinking you can intuit your way through this. Read the damn textbooks.

A single “brilliant” developer is never enough. Teams with deep collaboration habits outperform teams that rely on gifted individuals who hoard complexity.

The Culture Shift

If you want to play at an enterprise level (ship consistently, reduce defects, and keep people around for the long haul), you have to shift culture from “me” to “we.”

That means:

• Stop assigning people to unrelated projects just because their individual backlog looks empty.

• Stop pretending a team can run as many parallel projects as it has members.

• Swarm on priorities. Finish things. Deliver together.

This is radical, but it isn't new. It’s how high performing teams in any discipline operate. No one sends a rugby winger to go play for another team mid-match just because they’ve had fewer touches of the ball. You keep your shape. You play your game. You win together.

If you lose, you learn together and come back stronger.

If you want to measure something, measure the team’s delivery as a whole. If you want to improve something, improve the team’s flow of work.

But if you want to keep pretending it’s all about individual performance, fine — just don’t be surprised when your “team” starts to look a lot like five strangers stuck in the same room.

This is one slice of team maturity. And within that, a way to create resilience without compromising speed. Below, you will find a model or framework to build resilience through levels of maturity.

The Four Levels of Ownership

Level 0: Australopithecus

Level 1: Homo Habilis

Level 2: Homo Erectus

Level 3: Homo Sapiens

Level 0: Australopithecus

Or, "Authority-led Assignment", "Central Assignment".

This is the least resilient, most brittle state. You’ve seen this. You’ve been in it. One person — a tech lead or manager — decides what the team works on, and who works on it.

Rahul, the manager, is juggling three urgent needs:

1. Customer A is complaining about a bug in the checkout flow. Rahul asks Sakshi to fix it.

2. Sales have promised a multi-currency feature to prospects. Rahul assigns Michael to build it.

3. Finance is worried about rising AWS costs. Rahul asks Aman to investigate and shut down unused resources.

On the surface, this works. Everyone is busy, Rahul feels in control. But it doesn’t scale and it doesn’t build resilience. There’s no space for curiosity, agency, or self-directed growth. Individuals stay within their technical silos while someone else carries all the operational tension.

Level 1: Homo Habilis

Or, "Default Assignment".

Over time, responsibilities settle on individuals based on what they’ve done before.

You know you’re here if:

• Sprint planning is quick because everyone already knows who takes what.

• Bugs and production issues are assigned reflexively. The same names every time.

• Your team speaks in silos: “Meera handles backend logic”, “Ajay owns notifications”, “Ravi takes care of infra.”

It works until it doesn’t. The illusion of speed masks long-term fragility. Pockets of knowledge where expertise isn't really needed -> bottlenecks -> burnout. Besides, others never get to learn.

Level 2: Homo Erectus

Or, "Intentional Volunteering".

Here, team members choose their work rather than having it assigned. It’s simple to describe but requires a mindset shift. You’re signaling trust. You’re inviting people to engage with the work, not just receive it.

Example: There’s a bug in the refund logic. Instead of tagging the usual suspect, you post in the team channel: “There’s an issue in the payments flow. Who wants to take this?”

At first, the same people volunteer. Over time, norms shift.

Risks:

• Some people never volunteer. This becomes a coaching moment.

• Some dominate or hoard work. This needs guardrails.

• Managers worry: “What if nobody picks it up?” Occasionally you’ll need to step in but most of the time, someone will.

The biggest benefit is the distribution of learning. You can amplify this by calling out whether a sprint is a “speed” sprint or a “growth” sprint, and letting people choose accordingly.

Example: In one team, Divya from frontend began picking up backend auth bugs during growth sprints, pairing with Nimesh the first few times. Within a few sprints, she was handling auth fixes independently. That’s resilience in action.

Level 3: Homo Sapiens

Or, "Radical Volunteering". Guess you can also call it distributed judgment or shared ownership.

Now the team actively helps each other decide who should take what. It’s not just “What do I want to pick up?” but also “What would be best for the team’s learning, balance, and momentum?”

You start hearing:

• “Priya should take this, it’s new for her and a good growth opportunity.”

• “Zainab should pick this one. I’m already overloaded this week.”

• “I’d rather not take this again. I’ve handled the last three.”

This requires psychological safety, mutual respect, and a strong culture of growth.

Done well, it leads to:

• Better distribution of expertise.

• Team members supporting each other’s learning goals.

• Conversations that align with the team’s direction, not just personal convenience.

Example: Priya consistently owned a tricky async queue module. During sprint planning, she told the team, “I’d like Ali to take this one. I’ll shadow him so he can own it next time.” That’s distributed judgment.

Why This Matters

Resilience means the team doesn’t stall when someone’s on leave. New members don’t take half a year to become effective. People feel in control of their growth and their work.

As a manager, you don’t need to be the most technical person in the room. You need to observe patterns:

• Who always picks the same kind of work?

• Who’s disengaged?

• Who’s getting interrupted constantly?

• Who’s not learning anything new?

These observations give you entry points for intervention with care and clarity. Sometimes in a 1:1, sometimes in a retro, sometimes with a nudge in the team channel.

This model won’t solve for conflict, unclear goals, or poor execution. But it’s a strong foundation. If you get it right, the benefits are obvious: faster onboarding, fewer bottlenecks, deeper trust, and a team that can take a hit without breaking stride.

And it makes sense. We all know how the system works. Referrals open doors. In a world of algorithmic filters and inbox pileups, a human nudge can make all the difference.

I also know things are hard right now. It’s so bloody hard to get that first interview call — to break through the noise, to find someone who’ll give you a fair shot. I’ve been on both sides of this, and I don’t take any of it lightly.

But here’s where I slow down. For me, referring someone is more than just forwarding a résumé or clicking a button. It’s vouching for their craft, their character, the way they might show up to a team.

And I can’t do that lightly.

I know this might sound precious to some. Maybe even self-important. But in my little corner of the world, I try to keep certain things sacred. Trust is one of them. When I refer someone, I’m putting my name on the line — with colleagues I respect, with a system I want to be honest in. That only works if I’ve had the chance to work with someone directly, or know them well enough to speak about how they work, not just what they say.

So if you’ve reached out to me and I haven’t said yes, please know this: it’s not judgment. It’s not gatekeeping. It’s just a boundary I try to hold with care. It helps me stay honest. And in a small way, I hope it helps the system stay honest too.

That said, I’d still love to help in other ways — I can review your résumé, answer questions about the role or the company, or even just be a sounding board. If mentoring would help, I’m happy to offer that too, time and energy permitting.

We’re all walking our own winding paths. If we cross again, and work together, maybe one day I can vouch for you — and will, with pride. Or you, me!

Until then, thanks for understanding, and all the best in your quest to make your dreams come true!

Enter Suranga. Proprietor of Club Sha Lanka, motorcycle whisperer, and persuasive oracle. He whatsapp'ed me a list of available bikes, most of which sounded like minor Greek gods or discontinued household appliances. The only familiar name was the Royal Enfield Classic. Too familiar. I wanted something lighter and more nimble. Less brooding colonial officer, more cheerful sideshow.

I settled on the Honda XR250. Light, tall, and looked like it meant business. On paper, it's like the two-wheeled embodiment of Prabhudeva. I felt quietly smug about my choice, and flew out to Colombo and took a rickshaw ride to Sha Lanka in happy anticipation of riding this red beauty. And then I saw it in person.

The XR250 towered like a solemn coconut tree. I imagined myself, all 165cm and 90kg of me, attempting to mount it with luggage strapped on the back and saw, in vivid slow motion, a succession of ungraceful tumbles punctuated by the polite chuckles of passers-by. My quiet panic must have been visible somehow, because Suranga, with the air of a man about to unveil a secret, said, “Try the TW.”

And with a conspiratorial smile, he wheeled out the Yamaha TW225.

It was, in a word, absurdity. A squat frame, chunky, oversized tyres. A rear wheel that looked borrowed from a mini tractor. The seat height was so low it practically invited you for chai and samosas. The whole thing gave off the distinct vibe of a motorcycle designed possibly on a dare. A toy!

And yet, there was something endearing about it. I can't quite put my finger on it, but it was inviting? I slung a leg over, effortlessly, and settled into what can only be described as the motorcycle equivalent of a tobu cycle.

This, I decided, would do nicely. Forget the looks, I was itching to go places.

The ride

TL;DR: Delightfully quirky, utterly capable.

From the first moment, the TW didn’t roar or snarl. It hummed along like a retired postal worker with nowhere urgent to be. There was something gloriously unhurried about it, and soon I found myself easing into the same mood. Its rear rack and a couple of bungee cords made tying luggage feel almost ceremonial. The world, for once, stayed where it should.

The fuel tank was... modest. Let’s just say you get to know the petrol stations of Sri Lanka very well. The old-school on-off-reserve switch added to its rustic charm, like cooking over a wood fire because you want to, not because you have to.

First gear felt like it had been borrowed from a small tractor: comically low for tarmac, but a silent hero when the terrain got rough. When I took the bike off-road more than once, the TW just shrugged and got on with it.  Like, zero drama. It just went where I pointed, like an obedient donkey.

On the highway, those fat tyres felt like a gentle hand on your shoulder. They were a little slow to tip in, yes, but once leaned over, the TW held its line like a monk holding a thought. It wasn’t a fast bike, but it was sure of itself. I was trying out things that I knew only in theory, and each effort was rewarded with learning.

The brakes did their job without fuss. No ABS, but enough bite to remind you you’re still alive.

Overall, this was the most engaging, least intimidating and possibly the most capable bike I've ridden, all told.

I might have stressed a bit too much about its unhurried nature, but I think on a straight line, this TW can outstrip the xpulse.

Why isn't this in India?

Like yeah, really. Why isn’t the TW sold in India? As an aside, I seriously looked up the possibility of importing it into India and gave up because of the high cost of customs and paperwork hassle.

The adventure and dual-sport market is booming. But most of what’s available seems designed for omitabosons. For a country of short riders and shady roads, the TW would be revolutionary.

The TW225 is no longer in production, but its near-identical cousin, the TW200, is still going strong.

250mm ground clearance, with 790mm seat height. Supremely unbeatable. What the what!? I personally know about 20 people who would buy it just for the specs.

Sure, it still comes with a carburetor, but it would take very little effort to swap in fuel injection and bring it up to modern standards. Add abs and you're done!

It’s simple, proven, nearly indestructible. And somehow, more than the sum of its humble parts.

Yamaha, if you're listening: this one is a no-brainer.

The platypus of motorcycles

The TW is a motorcycle for people who have nothing to prove to anyone else but a lot to prove to themselves. It just bloody works. With a kind of cheerful humility that’s getting harder to find in the world.

This bike is pretty close to what freedom feels like. Not in the dramatic, hair-in-the-wind(lol) sense, but in the quiet joy of not worrying about the bike beneath me. Of not thinking at all, dissolving into the experience. Truly, essentially zen.

This is not just me, check out Ryan Fortnine singing praises.

So here’s to the beloved platypus. The heartbreaker oddball. The utterly charming TW. Long may it plod.

The cosmic Mother held my gaze,
her love alight in tender rays.
No shadow lingered, none could hide,
her presence vast, yet by my side.

Each leaf, each breeze, a whispered prayer,
the universe laid all things bare.
A sacred stillness filled the air,
as if all time had paused to care.

Her hands were leaves, her voice the sea,
and all she touched was part of me.
In every fold of light and hue,
she sang, "You are, and I am you."

I felt no end, no place to part,
the cosmos beat within my heart.
The sky, the earth, the endless blue,
all whispered back, "We are you too."

There are two ways to land a job: spray job applications like you've just got the S power up on Contra, or find that right opportunity that's made for you. Option (A) is depressing, dehumanising, and frankly a big bore. Option (B) is hard in other ways - LinkedIn is rife with fake jobs, even the genuine ones suffer from vague JDs, and behind them usually is a recruiter who doesn't know java from javascript.

Referring to Siddharth Sharma (svs) as a 'recruiter' would be like calling a Michelin-star chef a "guy who makes food". Technically true, but it wildly undersells the magic he brings to the table. He’s a career whisperer, a tough-love therapist, and a damn good human to have in your corner.

When I signed up on recruit.svs.io, I expected the usual recruiter screening call. Instead, I got an hour-long chat that stretched to two, where we talked about my career journey, my quirks, my challenges, and, somewhere in between, a heart to heart on guitars and motorcycles. SVS took the time to really understand who I was, beyond just my resume.

His generosity with time and advice helped me gain clarity on my unique mix of skills, the things I struggle with, and the paths I hadn’t even considered. From a vague sense of "I should find a job," I gained the confidence to take real control of my choices. Enough confidence, in fact, to take a much-needed career break spanning many months. This was my time to regroup after 19 years of grinding, and to come back stronger than ever. Throughout this break, SVS remained a steady presence, offering feedback on roles I considered. His words were like the inner voice I wish I had: grounded in reality but always pushing me to aim higher.

When I finally decided to go for Dyte, SVS was there every step of the way, exchanging updates, helping me navigate the process, and most importantly, keeping me sane. Breaks are great, but they also come with their fair share of irrational anxiety. Our conversations helped me find the solid ground I needed to truly unplug. And that, in turn, helped me fully enjoy one of the best parts of my break: riding my motorcycle across South India. He even inspired me to start writing, and today I'm proud of my personal blog, which is not just my space to find self expression, but also a proof of my skills and thought processes.

SVS has a rare wisdom that goes beyond even his years of experience (though, to be fair, he technically has more grey hair than me). He has spent years building deep, genuine relationships, and his network is full of smart, capable people looking for the right fit. With SVS, you don’t have to slog through the usual recruiting hell. You get clarity, confidence, and if you're lucky, a bit of life advice along the way.

And if you’re even remotely interested in building and scaling engineering teams, his blog, Engineering Org, is a treasure trove of wisdom. It’s one of those rare spaces where you’ll find deep insights that go beyond buzzwords and frameworks, lessons from someone who truly understands what makes teams thrive.

Do yourself a favour and check out recruit.svs.io today.

The argument is that approvals ensure quality and reduce risk. The reality is that they mostly just slow things down. The more approvals you add, the less people think for themselves. The less they think for themselves, the more approvals you need. Before you know it, the team is trudging through a swamp of bureaucracy, waiting for someone to nod sagely and let them continue.

This is how teams quietly lose momentum, lose their edge as it were, one approval at a time.

Approvals are just mistrust in fancy clothes

An approval step is never just a step. It is a statement about how much trust you actually have in your team.

If you need code reviews, it means we do not trust you to follow our standards. If you need approval for architecture decisions, it means we do not trust you to design something maintainable. If you need to ask before taking time off, it means we do not trust you to balance your workload. If you need expense approvals, it means we do not trust you to make reasonable financial decisions. If you need hiring approvals, it means we do not trust you to choose the right people.

The hiring one is particularly maddening. You hire a manager because you trust them to build a team, then force them to beg for every new hire. By the time they navigate the approval labyrinth, the best candidates have taken jobs elsewhere. A spectacular self own.

Individually, these all sound reasonable. Together, they create a culture where nothing moves without permission.

The numbers tell you everything

Before you defend your approval process, measure it.

How many approvals does it take to merge a one line change? How often do approvals actually change the outcome? How long does work sit in waiting for review? How long does hiring take because of approval delays?

If approvals are not stopping bad decisions, they are just slowing down good ones.

The best teams do not ask for permission, they all for context

Mature teams do not need approval for every step. They need information to make decisions themselves.

Instead of requiring code approvals, document clear standards and let engineers hold each other accountable. Instead of big architecture reviews, use open architectural decision records. Instead of vacation approvals, trust people to plan their time responsibly. Instead of expense approvals, set clear budgets and let people use them. Instead of hiring approvals, give managers a hiring budget and let them hire when needed.

The very existence of that approval step could also indicate something is broken in your system. Sure, you say you want approval from all the teams before making an architectural change. Why? Because you may unintentionally break some functionality somewhere. Is that then good design?

Approvals do not create strong teams. Trust does.

Approving wisely

This post is deliberately obtruse, pushing the point. Some approvals are useful. Some even save entire teams from disasters. But the question is which approvals actually help and which just exist because they always have.

Look at your approval processes.

If everything always gets approved instantly, why does the step even exist? If everything always gets rejected, your team is not aligned. If approvals take forever, the problem is not the work, it is the process.

If approvals must exist, they should be lightweight and intentional.

Only require approval for high risk decisions. Launching a security protocol might be a good idea. Changing a button color should not require a committee.

Push approvals down to the people closest to the work. If an engineer is blocked waiting for a director’s approval on a one line fix, something is very wrong.

Use disagree and commit instead of endless loops. If there is a real disagreement, hash it out, make a call, move forward.

Timebox approvals. If something sits waiting for approval for more than a day, default to yes unless someone actively intervenes.

Automate whatever you can. If small expenses require approvals, just give people prepaid budgets. If hiring approvals slow you down, allocate headcount budgets per quarter and let managers handle it.

If an approval does not add clarity or improve decisions, it is just a tax on momentum.

How many approvals before you stop thinking?

Some bureaucracy is inevitable. The world runs on checks and balances. But every approval step should be treated with suspicion. It is a tax on speed, trust, and ownership.

Does it actually prevent bad decisions or just delay good ones? Does it help people think more critically or just push responsibility up the chain? Does it ever change the outcome or is it just there for show?

I hope this post makes you measure the approvals in your system. If they make the team stronger, keep them. If they only add friction, kill them execution style.

Look at your processes. Count the steps. Count the wasted time. Count the moments where people stop thinking and start waiting.

And then ask yourself. At what point do we stop moving forward.

--

In theory, plans are supposed to make things better. They promise clarity, direction, and control, taming the chaos of uncertainty with neat timelines and tidy assumptions. But in practice, they often deliver the opposite. Plans, especially in dynamic environments, become fragile artifacts, undermined by the very complexity they seek to manage.

It wouldn't be wildly inaccurate to ascribe obsessive detailed plans to leadership's utter failure to regulate their anxiety.

Mary Poppendieck’s presentation The Tyranny of the Plan is a masterclass in dismantling this illusion. Drawing from her experiences in manufacturing and software development, she illustrates how rigid plans can become liabilities, trapping teams in cycles of inefficiency and chaos.

When Plans Go Wrong

Poppendieck recounts her time working with Material Requirements Planning (MRP) systems in manufacturing during the 1980s. These systems, hailed as breakthroughs at the time, revealed a glaring flaw: "nervousness." When reality diverged even slightly from the plan, the system would very quickly spiral into instability, requiring frequent and disruptive re-planning. The result was a workflow riddled with inefficiencies, where the plan became a source of chaos rather than order. More anxiety in fact, originally the plan was supposed to be a bandaid on anxiety.

She contrasts this with pull systems like Kanban, which align closely with actual conditions. These systems thrive on flexibility, responding to variability rather than resisting it. By prioritizing adaptability over rigidity, teams using pull systems saw dramatic improvements in reliability and efficiency.

This is all pretty par-for-the-course stuff today. It should be at least, but we know the adoption goes hardly beyond symbols in most places.

A Construction Marvel

The most striking example in the presentation is the construction of the Empire State Building, completed in 1931. The building took an incredible eight months, and the project was 18% under budget. Despite lacking modern computerized planning tools, the project was finished on time and under budget. How? Through adaptive planning and efficient workflows. The builders didn’t rely on static, long-term plans. Instead, they embraced the realities of the moment, collaborating and adjusting as needed. It’s a testament to the power of flexibility in the face of complexity.

Lessons for Software Teams

There's a lot of wisdom for us in the software world. Rigid sprint goals and fixed roadmaps may look reassuring, but they often lead teams astray, locking them into commitments that no longer reflect reality.

Poppendieck points to the construction industry’s Last Planner System as a model for short-term, collaborative planning. This approach emphasizes aligning the work with current conditions rather than a distant, often irrelevant plan. In software, this could mean focusing on iterative development, embracing variability, and building systems that adapt rather than break under change.

The Virtue of Deep Understanding

For any of the magic to become possible, one needs to get really down in the operations. There is a profound virtue in carefully studying and understanding operations: the behaviors, the friction points between various functions, and the patterns that emerge over time.

This can be exciting work, and it’s essential. By observing how teams interact with systems and identifying sources of friction and pileups, we can establish baseline metrics. These metrics become the foundation of continuous improvement: an iterative process of cranking the dial to see what works, what breaks, and what can be made better.

Rather than imposing plans from above, this approach empowers teams to align their actions with real-world conditions. It’s not about forcing a system to conform to a plan but about finding ways to adapt the system to reality, ensuring it becomes stronger, faster, and more resilient.

A Shift in Mindset

At its core, Poppendieck’s argument isn’t just about better processes; it’s about a fundamental shift in mindset. The problem with plans is not that they exist, but that we place too much faith in them. A plan is, at best, a hypothesis. To treat it as a guarantee is to invite failure.

Much more profitable to place your faith in your teams. Provided, that is, that you've done a good job of hiring smart, motivated people. Show them the direction, give them the constraints, and tell them to go have fun with the metrics.

Go from a rigid Plan to Planning as a dynamic process. A living, breathing practice of continuous learning and adaptation. A culture. It’s about setting direction without dictating steps, creating systems that respond to feedback, and building teams that thrive in uncertainty rather than fear it.

Beyond the Tyranny

In the natural world, adaptation is survival. Evolution doesn’t follow a plan; it experiments, iterates, and responds to change. The most successful species aren’t those with the most elaborate blueprints but those with the ability to pivot.

Whether building skyscrapers or software, we exist in ecosystems of shifting variables. To succeed, we must move beyond the tyranny of the plan, designing for adaptability, embracing uncertainty, and cultivating resilience.

In the end, Poppendieck’s insights remind us that plans are not sacred. They are useful, but not infallible. To cling to them too tightly is to miss the point entirely. Because real progress happens not in the execution of a plan, but in the ability to respond when the plan falls apart.

A rant in closing

The tyranny of the plan persists because it’s easier than thinking. Plans give the illusion of progress, even when we’re marching straight off a cliff. But real progress comes from admitting we don’t have all the answers. It means adapting, learning, and yes, sometimes throwing out the plan altogether.

Let’s stop pretending that plans are sacred. They’re tools. Use them, but don’t worship them. And for the love of everything sensible, don’t let them control you. Because when the plan becomes the goal, we’ve already lost.

Next time you see a Gantt chart, become very very suspicious. And take action.

A manager doesn’t need to know every intricate detail of every framework or tool their team uses. What a manager truly needs is to treat management itself as a craft. Like carpentry, software development, or baking a perfect soufflé, management is something you learn by studying principles, practicing techniques, and embracing a learning curve. It is a discipline that has been refined for decades by people who have thought long and hard about what makes teams work. Wing it, and the results will be about as predictable as a biryani made without reading the recipe.

And yet, we perpetuate this odd myth that a great engineer will naturally grow into a great manager. The two roles couldn’t be more different. The skills that make a brilliant engineer are not the same ones that make a great manager. Managing teams is an entirely different ballgame. It demands systems thinking, decision-making frameworks, and an understanding of how humans work in groups. Without intentional study and effort, the transition is less a natural progression and more like being dropped into an unfamiliar video game without the cheat codes.

Yet, I've often seen that the main and sometimes the only tool that managers use is Instinct. Well instinct is a wonderful thing for dodging flying objects or deciding whether to try that suspicious chicken 65, but it’s not enough for management. Instinct alone will not help you identify bottlenecks in a complex system or balance competing forces like speed versus quality. Management, like any other craft, requires tools, practice, and a touch of humility.

Over the years, several books have helped me make sense of this strange and wonderful discipline. Here are a few that have shaped my thinking:

1. Donald Reinertsen: The Principles of Product Development Flow
This book is not casual bedtime reading. It's a detailed guide to the mechanics of decision making in product development. Concepts like cost of delay, small batch sizes, and managing variability are essential tools for any engineering manager. If you’ve ever struggled to explain why work in progress is slowing your team down, this book will give you the language and the logic.

2. W. Edwards Deming: Out of the Crisis
Deming’s principles revolutionized manufacturing and remain just as relevant for engineering teams. His focus on systems thinking, continuous improvement, and feedback loops helps managers see teams as interconnected systems, not just a collection of individuals. Deming’s lessons are a must-read for anyone who wants to move beyond surface-level fixes. This book also solidified my utter disgust for the annual performance appraisal.

3. Mary and Tom Poppendieck: Lean Software Development: An Agile Toolkit
Concepts like eliminating waste, optimizing flow, and empowering teams are explored in depth - an essential read for managing with agility.

4. Daniel Kahneman: Thinking, Fast and Slow
Managers make dozens of decisions every day, often under pressure. This book is a masterclass in understanding how cognitive biases—like anchoring or confirmation bias—can influence those decisions. Becoming aware of these biases is the first step toward better judgment.

5. Patrick Lencioni: The Five Dysfunctions of a Team
A deep dive into team dynamics, this book explores how trust, alignment, and vulnerability impact a team’s performance. If you’ve ever wondered why a technically brilliant team might fail to deliver, this book will shed some light.

6. Gene Kim, Kevin Behr, and George Spafford: The Phoenix Project
A highly relatable story about the chaos of IT operations and engineering management, this book illustrates key principles of DevOps and the importance of flow. It’s as entertaining as it is insightful.

7. Fred Brooks: The Mythical Man-Month
A classic in software project management, this book captures the timeless pitfalls of scaling teams and projects. From Brooks’s Law to the concept of “surgical teams,” it is packed with insights that remain relevant decades later.

8. Peter Senge: The Fifth Discipline
A learning organisation is an unstoppable force. This book challenges you to see teams and organizations as dynamic systems with interconnected parts.

9. Eliyahu Goldratt: The Goal
A novel that teaches the theory of constraints through a compelling story about manufacturing. Its lessons apply just as well to managing bottlenecks in software teams.

10. Andy Grove: High Output Management
A foundational book on management that explores topics like leverage, decision-making, and team productivity.

11. Will Larson: An Elegant Puzzle: Systems of Engineering Management
A practical and thoughtful guide to the challenges of engineering management. Larson provides insights into balancing trade-offs, building resilient systems, and navigating the complexities of teams at scale.

12. Tom DeMarco and Timothy Lister: Peopleware: Productive Projects and Teams
A timeless classic that focuses on the human aspects of software development. This book emphasizes the importance of creating an environment where teams can thrive, offering insights on everything from workspace design to communication and trust.

13. Keith Johnstone: Impro
Surprisingly practical lessons from the world of theater improvisation, showing how to create psychological safety and foster creativity within teams. I've learnt to carefully read and calibrate my interactions within and outside my teams from this lovely and fun book.

14. Randy Hodson: Dignity at Work
A grounding reminder of how to treat people with humanity in high-pressure environments. A bit dated perhaps, but a lot of takeaways.

15. Noam Chomsky: On Anarchism
While not at all about engineering management, this book explores systems of decentralized organization and empowerment, offering lessons in how teams can operate without rigid hierarchies.

These are some of the books that have shaped my journey, but they are just the start. If you have books, articles, or even wild opinions that have guided you, I would love to hear them. Because the truth is, no one ever masters this completely. And isn’t that the fun of it?

So, the next time the recruiter asks you, “Are you technical?”, you have two options: (1) dodge that bullet and go elsewhere, or (2) respond with, “Absolutely. I’ve read more technical manuals on managing humans than I ever did on programming languages.” The craft of engineering management is as technical as it gets, just in ways that don’t always involve compilers or IDEs. It’s about systems, flow, feedback loops, and, most importantly, people. 

Finally, don't forget to let me know books that I should read to become a better manager.

It's a big book, and one of the densest in terms of words-per-wisdom. He's mentioned a few times in the more than recent past that he's working on a smaller primer, but pending that, here's a baby-simple starter post. If you have never thought about flow, small batch sizes, or the cost of delay before, this is a good place to start.

---

The pursuit of Flow

There’s a certain pride teams take in being busy. Full calendars, Slack threads overflowing, every hand on deck. It’s tempting to look at that busyness and assume all is well. But then why do things still feel stuck? Why does every sprint feel like a mad rush to nowhere?

Reinertsen’s Principles of Product Development Flow offers an uncomfortable truth. Busyness is a distraction. Flow is the goal. It’s not about doing more or doing faster, but about how work moves, smoothly, deliberately, through a system. A shift like this sounds simple enough, but in practice, it’s radical.

This post explores a handful of Reinertsen’s core principles: flow, small batch sizes, WIP limits, and decentralized decision-making. There is much more in the book, but these ideas are enough to get you started.

---

The Myth of Efficiency

Many teams follow an unwritten rule to keep everyone busy. If every person is at full capacity, surely the output will take care of itself. It sounds logical but it is completely wrong.

Reinertsen explains that optimizing for efficiency at every step creates a rigid and overloaded system. Pipelines fill up, complexity multiplies, and everything slows down. Teams mistake busyness for productivity and forget that real progress comes from a system that works smarter, not harder.

The surprising truth is that leaving some capacity unused, whether it is downtime for individuals or slack in the workflow, opens the door for meaningful progress. Without this breathing room, teams collapse under their own weight and become trapped in endless cycles of busywork.

---

Small batch sizes and cycle times

Reinertsen emphasizes the importance of keeping batch sizes small. For software engineering, this means breaking down work into smaller, deployable chunks. Instead of bundling features into massive releases, aim for frequent, incremental updates. Small batches not only reduce risk and make debugging easier but also deliver real feedback from users faster, allowing teams to adjust course quickly.

Cycle times are just as critical. Classically, cycle time is measured from ideation to done, but teams can also start simpler and measure from "in progress" to done. The key is to keep this time as short as possible. Long cycle times hide bottlenecks and delay learning, while shorter cycles help surface problems early. If your team uses pull requests, keep them small and review them quickly. Trunk-based development is almost always better, but perhaps that is a matter for another post.

The takeaway is simple. Ship smaller, ship faster, and learn as you go. The faster the feedback loop, the sooner your team can adapt and improve.

---

Work in progress: the silent killer

Reinertsen describes excessive Work in Progress (WIP) as one of the greatest threats to flow. In software engineering, this often shows up as a pile-up in the columns on your kanban board: “In Progress,” “Needs Review,” or “Ready for QA.” The more tickets sitting in these queues, the more progress slows down. Every new piece of work competes for attention, creating bottlenecks and delays.

A good way to start is for the team to agree on a limit for each column. For example, you might decide no more than five tickets can sit in the “Needs Review” column. The moment the limit is reached, the team shifts focus to clearing that queue before moving on to new work. You don't have any business picking up another task into "in progress" until the review column is cleaned up. This keeps the flow smooth and prevents backlogs from becoming overwhelming.

Similarly, if “Needs QA” starts to overflow, engineers can collaborate with QA to test and resolve issues. The idea is simple—focus on what is stuck, clear the blockages, and then move forward. The less WIP there is at any given moment, the faster your team will deliver.

---

Cost of delay: the hidden price

Cost of delay is one of the most overlooked yet impactful concepts in product development. Every piece of work sitting idle has a price—whether it is lost revenue, delayed customer value, or missed opportunities. Reinertsen makes it clear that understanding this cost is critical to prioritizing effectively and keeping the flow of work healthy.

In software engineering, this can mean shipping features sooner rather than letting them linger in development. For instance, a feature that could immediately resolve a major customer pain point has a higher cost of delay than a backend refactor. But here lies a common problem. Engineers are often not equipped to differentiate between the cost of delay for two product features, because they lack the full context of customer impact or business priorities.

The solution starts with collaboration. Engineers, product managers, and business stakeholders need to create an open dialog about the impact of each feature. Product teams should clearly articulate why a particular task has a higher cost of delay, backed by customer feedback, analytics, or market research. Engineers can then use this information to make better decisions during planning, even without diving into business details themselves.

A practical way to bring cost of delay into focus is by asking, “What happens if we delay this work by a week? A month? A quarter?” Features that carry a high cost of delay should move up the queue, even if they feel less glamorous than other work. Once teams start framing work this way—and including engineers in these discussions—prioritization becomes less about opinions and more about delivering the most value.

---

Decentralised decisions

Reinertsen highlights one of the most common bottlenecks in product development. Centralized decision-making. When teams rely on a single person or a small group to approve every decision, delays are inevitable. Work stalls, frustration builds, and the cost of inaction quietly rises.

You're better off federating the decisions to the team. This works particularly well when combined with small batch sizes. When teams deliver work in smaller, incremental chunks, the risk of any single decision going wrong is significantly lower. A less-than-optimal decision is no longer catastrophic—it can be identified and corrected quickly because the team is now operating with shorter cycles and faster feedback. Mistakes become opportunities to adapt rather than roadblocks to success.

---

Flow is everything

...and as engineering manager, it is your job to protect that fire. Reinertsen’s Principles of Product Development Flow challenges the way we think about work. It shifts the focus from isolated tasks and individual efficiency to the broader system, emphasizing flow as the true measure of progress.

Improving flow isn’t about rigid rules. It’s about rethinking the way work moves through your team.

It was a quiet beach, the kind where the air feels heavy with secrets and the waves whisper ancient truths. Lol no, it was just a beautiful, desolate beach. There was one solitary dog to give me company, but after a while he too, ran off into the bushes seeking more thrilling adventures.

I found a seat within a natural rock formation, something that, in hindsight, resembled a throne carved by time itself. I had my headphones in, the volume low enough to let the ocean breathe around me. Then, Ustad Shujat Khan began to play.

It wasn’t just a song. It was a journey, twenty minutes(or three hours? idk) of music that unraveled something deep within. Without realizing it, my body began to sway, moving with the rhythm of something I couldn’t "see", but definitely felt a presence. The music, the waves, the wind were not separate forces. They were one, and I was first an observer then an active part of their dialog.

The world came alive. Everything, every grain of sand, every ripple in the water, felt sentient, humming with the same consciousness. It wasn’t a fleeting sensation. It was full blown visions. Myself as a happy child, laughing under an open sky. A rainforest, dripping with vibrant life, alive in its stillness. I wasn’t just present. I was part of something vast, something infinite. And the overall "theme" was that "love is not only enough, it's everything."

This is really bad and amateur writing, but people better than me have tried and utterly failed to describe the shattering exquisite pleasures of a mystical experience.

Apparently, this is a thing.

Michael Pollan, in his book(and Netflix series) How to Change Your Mind, talks about mystical experiences having qualities that are ineffable and noetic. These moments are impossible to fully describe and carry a profound sense of truth and significance. For me, this wasn’t just a poetic abstraction nor was it temporary madness. It was real, tangible, as if the universe itself extended a hand and whispered, “Here you are, and we are all watching and delighting in you.”

Science too, has begun to unravel these threads. "Eigenmodes of the Deep Unconscious" by McGovern and colleagues bridges Carl Jung's ideas of archetypes with modern neuroscience. Experiences like mine might tap into deep, universal patterns of the "collective unconscious." (That's actually something I had dismissed as voodoo earlier, but now... I can't.) The study describes how altered states, whether through dreams or psychedelics, liberate archetypes hidden within our psyche, revealing primordial stories and images that are both deeply personal and universally shared. This resonates with how, in that moment by the ocean, everything felt both intensely mine and a part of something far greater.

Another eerily interesting study: "The entropic brain: a theory of conscious states informed by neuroimaging research with psychedelic drugs" led by Robin Carhart-Harris and his team from Imperial College. Mystical experiences, whether induced by psychedelics or otherwise, often lead to profound changes in one’s outlook and emotional well-being. These shifts include a newfound connection to the world, a reduction in negative patterns, and a heightened sense of purpose: all outcomes I can -now- deeply relate to. My own destructive habits have dulled, and decisions now seem guided by an inner voice I had not known existed.

Since that day, I’ve changed in ways I still don’t fully understand. My destructive habits seem to have dulled, their grip loosened. I am calmer, more attuned to an inner voice that feels older than me, helping with decisions big and small. Even creativity has blossomed—I owe this blog itself to that one encounter.

So, that encounter with Mother Infinite was back in March. Now about 8 months later, I returned to the same beach, trying to recreate the conditions of that first experience. I was thirsty for some more of that delicious drink, but I didn’t expect it to happen again. But sure enough, as the music started and the waves echoed, that connection reignited, instant and undeniable. It’s like tuning into a frequency that is always there, just waiting for us to listen. One fairly contentious theory about consciousness is that the brain doesn't generate or produce consciousness, but acts as a receiver, tuning itself to the larger cosmic consciousness ~out there~.

An invitation

The world, with its relentless rules of society and commerce, demands our attention for survival. But stepping away, "disconnecting to connect" is really the best thing. Whether through meditation, therapy, or even psychedelics (in legal and guided contexts), there are practices that can lead us toward this awareness. As Pollan suggests, these moments remind us of our intrinsic unity with nature and existence itself. Now, when I pause to notice a stray bird song or the solitary beauty of a city tree, I feel that faint, unmistakable connection to the cosmos. I dearly hope this connection stays for life, in the face of status meetings and consumer apps and Elon Musk's latest shittery.

If this post resonates, you might also enjoy reading "The Grains Beneath Our Feet", where I explored the profound wonder hidden in the smallest things. Sometimes, it’s the seemingly banal that holds the deepest truths.

Such moments may be fleeting, but they remind us of something eternal: we are leaves in the infinite forest, notes in nature’s quiet symphony, whispers carried through time. In this boundless dialogue, there is always more to hear, always more to learn.

"Time it was, and what a time it was." - Simon & Garfunkel

Yesterday, I went to the beach with a cheap Carson microscope in my pocket. No agenda, no plan. Just a vague sense that there was something worth seeing. I didn't know I'd be spending all of the afternoon hours hunched over grains of sand, marveling at shapes and colors I’d never noticed before.

---

A World Hidden in Plain Sight
Sand is a drab, brown blanket. But up close, it’s chaos. Grains are white, black, blue, red, green, pink. A riot of colors that blend into what we casually call “brown.” Each grain is unique, with sharp edges or smooth curves, polished surfaces or jagged angles.

There’s something unsettling about realizing how much detail lies hidden in the everyday. These grains beneath our feet, ignored and brushed aside, are tiny works of art shaped by time and chance.

The human brain doesn't like complexity and entropy. It makes reasonable guesses and shortcuts, optimising for survival. So, the sand looks brown. Nothing to see here.

---

Shells of Ghosts
Among the grains, I found something stranger: shells of creatures so small they looked like sci-fi. A quick series of google searches on my phone informed me that they're called foraminifera. Single celled, yet packing enough complexity to be unique. Some of these shells might belong to ancient creatures, their stories stretching back before dinosaurs.

I stared at them, spiraling and intricate, wondering how many footsteps had passed over these tiny fossils without knowing. Some of them might have died just last week, some might have withstood the last ice age. Their presence felt absurd, almost cosmic. Why should something so small and intricate exist, and why should it be beautiful and unique? Yes, that's the universe whispering in your ear about its endless wonder.

---

Banal, Endless Wonder
We talk about wonder like it’s rare. Something you have to chase to the edges of the earth, pay boatloads of money for... Maybe you'll find it on Netflix. But there’s wonder even in a handful of sand. Turns out I'd just trained myself not to look.

Why does sand look brown when its grains are rainbow-colored? Why do tiny shells persist for millennia? Why do we ignore the things of inexplicable wonder right in front of us? I have no answers, just a lingering awe for how the world works without us even noticing.

---

What it taught me about B2B sales
Next time someone asks me to explain the gap in my career, instead of asking them politely to stuff it, maybe I’ll tell them this story. I’ll tell them I spent hours poring over sand through a microscope, trying to grasp its absurd diversity and failing. I’ll tell them I found tiny shells of ancient creatures and wondered what it means to mark time.

Maybe that’s the point of the gap. To exist, unnoticed, for a while. To look closely at something you never thought to examine. To find wonder in the banal. To heal from forced, unnatural order.

TL;DR: Emotions aren’t the enemy of logic - they’re its greatest ally. A good engineering manager doesn’t just build systems; they build emotionally aligned teams that don’t burn out, but burn bright.

Back at Gojek, my team was building a tool for 360-degree employee feedback. Things were going smoothly - until, very late in the game, a massive new feature request landed on our plate. The deadline? Unmovable. The company needed the tool ready for annual appraisals.

Conventional wisdom says good decisions are made without emotions. You weigh the facts, analyze the risks, and proceed logically. But that approach overlooks something crucial: emotions aren’t just noise - they’re data. In fact, ignoring the emotional state of the team can lead to poor decisions and, worse, burnout.

We paused and did something unconventional: a "reverse retrospective" on a board. Everyone added cards about how they were feeling - confident, scared, uncertain. Simply putting those emotions out there made them tangible, something we could talk about and acknowledge. It helped us understand not just how each of us was individually feeling, but how others were feeling, too.

https://twitter.com/Space_Cadet_Glo/status/1454516004046864387?t=oB3GB1-AlUXtWeff4UA9ow&s=19

This wasn’t just a one-off trick - it’s the way we should always be making decisions. By understanding where everyone stood, we rallied, stretched ourselves just enough, and hit the goal. That’s the power of “reading the room” as a team - and it’s a skill every great engineering manager helps their team build.

---

What Is Collective Emotional Awareness?

Collective emotional awareness is the ability of a team to recognize, understand, and respond to its shared emotional state. Unlike individual emotional intelligence, which focuses on personal emotional awareness and regulation, collective awareness requires alignment across the group. And here’s the key: individual emotional intelligence isn’t optional - it’s the foundation, a necessary precondition.

A good engineering manager knows this and invests time and emotional labor in 1-on-1s. These aren’t just status updates; they’re opportunities to deeply understand how each team member is feeling and to help them become more emotionally self-aware. This groundwork is essential for the team to function as a cohesive unit. Without individual awareness, group alignment is almost impossible.

Why does this matter? Three reasons should be enough:

1. Avoid burnout: When a team is emotionally disconnected, stress can go unnoticed until it’s too late. Collective awareness helps surface tensions early and enables managers to intervene before burnout spreads.

2. Build emotional alignment: For a team to be effective, they can’t just see their goals - they have to feel them. Emotional alignment means the team is genuinely motivated and invested, not just checking boxes.

3. Become greater than the sum of its parts: A team that’s emotionally aware can leverage its collective energy and creativity in ways that go far beyond what individuals could achieve alone. As Patrick Lencioni writes in The Five Dysfunctions of a Team, trust and vulnerability are the cornerstones of high-performing teams.

Daniel Goleman’s Emotional Intelligence underscores this as well, showing how emotional awareness builds communication, strengthens relationships, and creates resilience under pressure.

Building collective emotional awareness isn’t a luxury - it’s a necessity for any team aiming to excel. And it starts with managers who prioritize emotional intelligence, both individually and collectively.

---

Why teams struggle with collective emotional awareness

Engineering teams are uniquely prone to emotional blind spots. Here’s why:

1. The tyranny of logic

The engineering mindset often glorifies cold, unemotional rationality. As Benjamin Franklin once said, "If passion drives you, let reason hold the reins." But this oversimplifies how decision-making really works. Neuroscientist Antonio Damasio, in Descartes’ Error, showed that emotions are essential for rational thinking. People who can’t process emotions - due to brain damage or other factors - struggle to make even simple decisions. Emotions don’t derail logic; they complete it.

Ignoring this reality in team dynamics is where many engineering teams falter. Emotions, both individual and collective, provide critical data about alignment, motivation, and potential roadblocks. Without understanding this, teams risk making decisions that seem rational on paper but fall apart in practice.

2. Social conditioning and "Normative Male Alexithymia"

There’s also a societal factor at play. The tech industry has a gross overrepresentation of men, and research shows that men are often conditioned to suppress or ignore emotions. This phenomenon, sometimes called "normative male alexithymia," leaves many unaware of their own emotions, let alone those of others. When you scale this across an engineering team, collective emotional awareness becomes a steep uphill climb.

3. Centralized decision-making

A lack of distributed ownership can further stifle awareness. For example, at Appsmith, my teams used a transparent framework for work assignments to avoid this trap (Work assignment: aka who works on what). This approach allows team members to self-select tasks, reducing the risk of emotional misalignment or frustration from top-down directives. Many teams, however, rely on a single authority figure to make these decisions, which can prevent group emotions from surfacing and being addressed. This means business. This means bad decisions.

4. The risks of emotional blind spots

Talking about emotions in a technical environment risks being dismissed as “woo-woo.” Emotional intelligence rarely makes it into engineering manager job descriptions, leaving room for disastrous hires - managers who are themselves emotionally unaware.

Even more concerning, many operational problems stem from leadership’s failure to regulate their own emotions. A reactive or poorly aligned executive team can trickle chaos down to engineering teams, forcing them to make tough decisions under avoidable stress. This is a massive topic in itself and deserves a post of its own. Again bad for business. Definitely not "woo-woo".

---

The Role of an Engineering Manager

An engineering manager plays a critical role in fostering collective emotional awareness by helping individuals and the group align emotionally. This involves creating spaces for reflection, open communication, and meaningful feedback. Here’s some ways to do it, but you can also let the universe guide you:

1. Individual alignment through 1-on-1s

1-on-1s are more than just status checks - they’re the foundation of emotional alignment. A great engineering manager uses these sessions to not only understand what’s blocking their team members but also to coach them toward greater self-awareness. These conversations help individuals process their emotions, align with team goals, and ultimately contribute more effectively to group dynamics.

2. Group alignment through retrospectives

Activities like retrospectives and reverse retrospectives bring group emotions to the forefront. I'll write a separate post if needed on how to run effective retros. In a reverse retrospective, team members can share how they’re feeling - confident, uncertain, or overwhelmed - and discuss how these emotions impact the team’s progress. These sessions help the team develop a shared emotional vocabulary and align on how to move forward together.

3. Feedback through Brown Envelope Sessions

Feedback is the lifeblood of growth, and it’s a manager’s job to make it a habit. Brown Envelope Sessions are a thing that I learnt from Ranjan Sakalley at Gojek. These are structured activities where team members exchange candid feedback in a psychologically safe environment (read more here). These sessions not only improve interpersonal dynamics but also surface unseen tensions or misalignments that might derail progress.

Why is feedback so important? As my candid reflections say here, feedback loops are essential for awareness - both individual and collective. Without them, teams can’t recognize patterns or adapt effectively to challenges.

4. Modeling emotional awareness

Perhaps the most impactful thing a manager can do is lead by example. By being open about their own emotions - sharing when they’re excited, concerned, or uncertain - a manager gives the team permission to do the same. This creates a culture where emotions aren’t ignored but embraced as part of decision-making and collaboration.

In short, a good engineering manager doesn’t just manage tasks and deadlines - they help build the emotional muscle of the team, ensuring that individuals and the group as a whole can navigate challenges with clarity and resilience.

---

Conclusion

Engineering teams are often seen as machines - logical, efficient, driven by data. But the truth is, teams are made up of people, and people bring their emotions, fears, and aspirations to work every single day. Ignoring that isn’t just a missed opportunity - it’s a recipe for burnout, disconnection, and wasted potential.

A good engineering manager doesn’t just guide their team through deadlines and deliverables; they create a space where emotions aren’t something to be hidden or ignored, but embraced as part of the work. They ask questions that matter: “How are you feeling?” “What’s holding you back?” “What do you need to thrive?” And then they listen - really listen and act - because they know that understanding the heartbeat of the team is as important as any metric or roadmap.

But here’s the catch: before you can help your team grow emotionally, you need to invest in your own emotional growth. Read books like Emotional Intelligence by Daniel Goleman or The Five Dysfunctions of a Team by Patrick Lencioni. Go to therapy and unpack your blind spots. Take that solo trip you’ve been putting off to better understand yourself. Drop acid. idk, just learn and practice real connection. Emotional self-awareness isn’t just a prerequisite for great leadership - it’s what makes it ✨magical✨.

When a team feels seen, heard, and aligned - not just on their goals, but on their emotions - they become something extraordinary. They navigate challenges with resilience. They take ownership not just of their work, but of each other’s well-being. They go from being a collection of individuals to a true team, greater than the sum of its parts.

So the next time you’re in a 1-on-1, a retrospective, or even just a casual chat, pause. Ask yourself: “What’s the emotional state of this team? What am I doing to help them understand it and grow from it?” These small moments of awareness and care can transform everything.

Because engineering management isn’t just about building systems - it’s about building people. And when you build people, you build something truly lasting - teams that don’t just meet goals but redefine what’s possible together.

Great engineering managers understand that technical excellence is only half the equation. The other half is emotional intelligence - the ability to lead with empathy, create alignment, and inspire trust. By investing in yourself and your team, you can unlock the true potential of the people you work with and create an environment where everyone thrives.

Because at the end of the day, great teams aren’t built on logic alone. They’re built on connection. Connection is fun, and fun is pleasure, which is the central driving principle of everything.

Chai chillum chapathi

You rail against the endless tides,
As though the ocean bends to man.
You wail and thrash, with broken cry,
Lost in the depths of all you’ve damned.

Ahab, Ahab, my thunderous son,
Alight again on the wondrous shore.
Let go the storm, the fight is done,
And let your soul find peace once more.

The stars still sing, the night is kind,
The waves will carry what you’ve lost.
Come home, beyond the restless sea,
Where grace is full and bears no cost.

The stars shine only for me,
In a private amphitheater’s light.

The jungle hums with ancient calls,
Beckoning me to drift, to fall,
Back to the wild, a primal night.

The soul within, it claws and scrapes,
Against the walls it cannot break;
Yet reason whispers, soft and low,
Stay, it murmurs, let hope grow.

Only to wake, at dawn’s embrace,
In a stifling, makeshift place,
Where days are drawn in measured lines,
Yet dreams still spark, and light still shines.

Each step retraced, each voice constrained,
The pulse of life in gears contained;
Yet still that distant song persists,
A call that draws, that gently lifts.

And so I wait, with heart held high,
For stars to pierce the darkened sky,
To drift beyond the cage’s bars,
And dance in freedom with the stars.