The article is mostly right: we have learned to build software in certain stages. There is usually a moment where we try to understand why something should exist in the first place (Product DNA). Then we move into design (RFC/Design Document), where we compare approaches and make sense of tradeoffs. Then we plan the delivery, break the work into pieces, and start building. And eventually we decide whether something is ready to ship (Definition of Done).
I strongly believe this basic shape still holds. I do not think it is going away.
What has changed, at least for me, is the kind of certainty we can expect at each stage. The structure is still there, but the meaning of the stages is shifting. What used to feel like a fairly direct path from problem to solution now feels more like a process of narrowing, testing, and discovering what the problem really is.
The first place I notice this is in Product DNA / Requirements. In the old sense, the document is supposed to help us define the problem clearly enough that the rest of the work can follow. That is still true, but with more AI-shaped work, the early stage feels less like a definition and more like an exploration. You start with a direction, a rough understanding of the user need, maybe even a strong intuition about the outcome you want. But you are often not writing down a truth so much as writing down the best version of your current understanding. The point is not to lock in the answer, it is to make the question explicit enough that the team can reason about it together.
That distinction matters. When the thing you are building has a more probabilistic or adaptive quality to it, the problem rarely reveals itself all at once. You might think you are solving one thing, and then the first real interactions show you the actual problem lives somewhere else. Or that the original problem was real, but incomplete. Or that the right framing is slightly different from what everyone first assumed.
So Product DNA becomes less about saying “this is exactly what we are building,” and more about saying “this is the space we are trying to understand, and this is the outcome we care about.” It is still useful for alignment. It just needs to leave room for discovery.
Design docs change in a similar way. They still matter, because they are where we make tradeoffs visible and force ourselves to be honest about the implications of different approaches. But in a world where system behavior is not always fully predictable from the outset, design docs feel less like a final specification and more like a way to structure the investigation.
That does not mean they become vague. It means they should be more explicit about uncertainty. A good design doc in this world should say not only what we think we will build, but what we still need to learn before we trust that direction. It should capture the options we considered, the assumptions we are making, and the places where we expect to change our minds once we have more signal.
That leads naturally into the part of the process that often gets treated as secondary, but should probably be treated as central: exploration. Call it a POC, a prototype, an experiment, or just “trying it out.” The label does not matter much. What matters is that some questions cannot be answered by documents alone.
You can write a convincing product brief and still be wrong about whether the experience is actually useful. You can produce a thoughtful design and still miss how the system behaves once a real user gets involved. You can plan a delivery perfectly and still discover that the thing you thought was a milestone was really just the beginning of the work.
That is why the exploratory phase starts to feel less optional. It is not a side quest before the “real” project begins. In many cases, it is where the real project becomes visible. The role of exploration is not just to de-risk implementation, it is to reveal what the system actually needs to be. That is a different job.
Delivery plans also carry a slightly different meaning now. They still help us sequence work, manage dependencies, and create a sensible path forward. But when the thing being built requires more learning along the way, milestones become less about completion and more about confidence. A milestone is not just “the code exists.” It is also “we know enough now to make the next decision with less uncertainty than before.”
That is a subtle but important shift. Progress is not just measured by output, it is measured by what we have learned. Sometimes the most valuable thing a milestone gives us is not momentum, but a correction. It tells us the original idea was close, but not quite right. Or that the system needs a different shape than we expected. Or that the thing we thought would be central turns out to matter less than something we discovered along the way.
This is the part of the workflow that tends to stay the most recognizable, because there is still a real need to ask whether something can be operated safely and reliably. That does not go away. If anything, it becomes more important. But the standard for readiness shifts too. It is not enough to know that something runs. We also need to know whether we can understand its behavior, measure its quality, and notice when it begins to drift.
That is where observability and evaluation start to matter in a deeper way, not just as operational hygiene, but as a way of owning the behavior of the system after it ships. The more adaptive or probabilistic the system is, the more important it becomes to understand not only whether it is up, but whether it is still doing the right thing. That means closing feedback loops earlier, and making sure the system can teach us when it is getting worse rather than just failing loudly.
I do not think the answer is to invent an entirely new lifecycle (though there are attempts, like asdlc.io). The old structure still gives us something valuable. It creates shared language. It creates checkpoints. It keeps teams from skipping the hard conversations.
The process stays, but the meaning shifts.
]]>The app is intentionally simple: no database, a fake checkout flow, a status page, a few API failure modes, and Grafana Faro for frontend telemetry. That made it a good environment for one question I kept coming back to:
if something breaks in production, how do I move from a signal to actual understanding?
What I ended up learning was that Digital Experience Monitoring is not really about collecting more signals. It is about how quickly you can move through the steps that matter: detect, scope, select a session, view what happened, diagnose, fix, and validate.
Digital Experience Monitoring (DEM) is often described in terms of signals: synthetic checks, frontend observability, logs and traces and so forth. Coming from the outside, that framing made sense. But once I started using the system, something became clear very quickly: the problem isn’t collecting signals, it’s making sense of them when something breaks
You can have all the right data and still feel stuck.
Individually, each of these is useful. Together, they should tell a coherent story and in practice that story is not always obvious.
To make sense of this, I started walking the system the way a user would. Not as an insider, but as someone trying to debug a real issue.
What emerged was a fairly consistent pattern:
Detect → Scope → Understand → Diagnose → Fix → Validate
This is not a new framework. Most teams already operate this way implicitly. But walking through it step by step exposed where things feel smooth—and where they don’t.
One of the simplest ways I tested my understanding was by creating a synthetic browser check against a demo app and then intentionally breaking it.
The synthetic check failed. That part worked exactly as expected.
Synthetic Monitoring is very effective at this because it gives you a controlled, repeatable version of a user flow. When it fails across multiple probes, you know something is off.
But at that moment, I realized something: I knew that something was broken, but I didn’t know if it mattered.
The next step was figuring out whether this failure showed up in real user behavior.
Looking at frontend signals helped answer that:
This is where the picture started to form. The failure wasn’t just synthetic, it was visible in real usage. That shift—from “signal” to “impact”—felt like a key transition.
This was the most interesting part of the experience. Knowing that users are affected still leaves a gap: what actually happens when the flow breaks?
Logs and metrics can help, but they require interpretation.
What helped more was looking at behavior:
Instead of correlating multiple graphs, I could follow the flow itself. That made the problem much more concrete.
At this point, something clicked for me:
Synthetic Monitoring tells you where to look, Frontend Observability shows you what actually happens.
Those two together reduce a lot of guesswork.
Once I had a clear picture of the failure, moving into logs and traces felt very different.
Instead of exploring the system broadly, I was looking for something specific:
That narrowed the search space significantly.
After applying a fix, I followed the same path again:
This closed the loop. And it highlighted something I hadn’t fully appreciated before:
Synthetic Monitoring isn’t just about detecting failures. It’s also a reliable way to confirm recovery.
Before this exercise, I thought about DEM mostly in terms of capabilities (checks, signals, integrations, etc). After walking the lifecycle, I started thinking about it differently: not as a collection of signals, but as a workflow
Each part answers a different question:
The value is not just in having these answers, but in how quickly you can move between them.
This exercise also made some tensions more visible. As systems grow more flows get monitored and more teams interact with them. At that point, small inconsistencies start to matter(naming, time ranges, missing context). None of these are new problems. But during an incident, they become very noticeable.
Walking the product as a user gave me a much clearer lens on DEM. The challenge is not collecting more data. It’s maintaining a clear path from detection to resolution.
Detect → Scope → Understand → Diagnose → Fix → Validate
Most systems have the pieces, but the difference is how well they connect.
]]>When I made the decision, I expected complexity. What I didn’t expect was how disorienting the transition would feel.
In the first week, I almost felt like I hadn’t just changed teams - I had changed companies. A new domain. A new vocabulary. New product surfaces. New stakeholders. Different operational realities.
And somewhere in that first week came a quiet realization: if I didn’t approach this intentionally, I’d spend months reacting instead of learning.
So I treated onboarding as a project. Not something that “just happens,” but something I would design.
I split my onboarding into four concrete phases. Not because I thought reality would follow the plan perfectly, but because without structure, everything feels urgent and nothing feels clear.
Before officially starting, I focused on building a rough mental map. I read strategy documents, OKRs, roadmaps, past retros, Slack threads. I tried to understand how the department talked about itself.
The goal was not depth. It was orientation. By the time Day 1 arrived, I didn’t understand the system, but I knew the vocabulary.
In the first two weeks, I deliberately biased toward conversations over diagrams.
I asked:
I resisted the urge to dive deep into software too early. Understanding how the team experiences the system is more important than understanding the system itself. You can always learn code. Trust is slower.
This is where I forced myself to stop reading and start using.
I walked the lifecycle end-to-end as a user.
Not to test the product, but to test my understanding. This phase revealed more gaps in my mental model than any document could. It also surfaced something important: friction often lives at the boundaries between products, not within them.
At the four-week mark, I wrote and shared a reflection. Not a polished summary, a real one.
One uncomfortable realization was this: my job at that moment was to ask better questions, not to provide fast answers. If that sounds obvious - it’s not.
As a manager, there’s pressure to demonstrate clarity quickly. But clarity in a new domain takes time. Pretending to have it only creates fragility later.
Naming what I didn’t understand reduced the pressure to fake confidence. It also created space for the team to help me build context. Transparency during onboarding builds trust faster than posturing.
One of the exercises I tried early on was to reverse engineer the squad’s goals. I synthesized what I thought the real objectives were and asked the team and PM: “Did I get this right?”
In hindsight, the document was probably too verbose and too heavy. It’s not something I would keep long term. But the exercise forced me to confront misalignment early.
Sometimes the value of a document isn’t in keeping it. It’s in thinking through it.
For the first month, I aggressively took notes.
I didn’t try to be elegant. I tried to be exhaustive. Over time, I started structuring those notes more intentionally. Onboarding, especially in a technical domain, is a data collection phase. You’re mapping a system that already exists, with its history, assumptions, and tensions.
Here are some patterns that helped me structure that data:
1. One-sentence summaries.
After each major conversation or topic, I tried to write one sentence I could rely on later. If I couldn’t summarize it clearly, I probably didn’t understand it well enough yet.
2. Facts and open questions per domain.
For each product or sub-system, I separated what I knew from what I didn’t. Writing down open questions made uncertainty explicit instead of vaguely uncomfortable.
3. An observation log - who said what.
Not in a political way, but in a pattern-detection way. Different perspectives reveal different parts of the system. Over time, themes start to emerge.
4. Hypotheses and tensions.
As patterns formed, I wrote down emerging hypotheses:
“Is private probes actually a product within a product?”
“Are we optimizing for enterprise customers over small ones?”
Capturing tensions early helped me avoid jumping to conclusions too quickly.
5. A decisions log.
Some decisions I intentionally deferred during onboarding. I wrote them down explicitly. That way, deferring wasn’t avoidance - it was conscious sequencing.
Later, I used AI tools to summarize and cluster my notes. Not to replace thinking, but to accelerate synthesis. Onboarding is not about having opinions quickly. It’s about building a clear mental model over time.
First gather signal. Then refine.
Rather than assuming alignment, I asked explicitly:
Is there anything you were expecting to see from me that you’re not seeing?
That question changed the tone of onboarding. It surfaced implicit expectations that no checklist would have captured.
Feedback during onboarding isn’t about evaluation. It’s about adjusting trajectory.
Most importantly, being intentional created momentum.
Reverse engineering goals was useful but time consuming.
But onboarding is not about finishing. It’s about trajectory.
Switching teams as an Engineering Manager isn’t about proving yourself quickly. It’s about building clarity - of the domain, the people, the risks, and the direction.
You don’t need all the answers in the first month. You need structure. You need signal. And you need the humility to admit what you don’t yet understand.
In a follow-up post, I’ll write about what I learned when I tried to understand Digital Experience Monitoring by walking the lifecycle as a user, and why that exercise reshaped how I think about product clarity.
]]>Growth is different than performance. Often (more often than ideal), high performers experience growth pauses more than others. It’s critical to not confuse growth with performance. Growth is not the same as doing your job well. It has also been shown that growth is crucial for company retention, which is why you usually find the “Am I growing?” question on annual surveys.
For many years, I’ve done a quarterly assessment to measure growth by answering three questions.
I wrote about this more here. This framework served me well for a long time, but as I grew as a leader, it started to feel insufficient. I was searching for a new lens when I came across this idea while reading Ego Is the Enemy by Ryan Holiday. In the book, there’s a reflection (originally from Epictetus) that stayed with me:
“It is impossible to learn that which one thinks one already knows.” - Epictetus, as cited in Ego Is the Enemy.
This resonated because it reminded me of a simple truth: growth depends on how you orient yourself relative to others.
In this context, I started thinking about growth not only as what you do, but who you relate to:
This framework struck me as a useful meta model for growth. These levers don’t measure performance. They measure growth conditions.
I didn’t have a teacher for a very long time. Could that be why my growth felt stalled?
We often ask, especially in leadership roles, whether someone has mentored others, and sometimes even make it a prerequisite for promotion. There is an obvious aspect to this: when you mentor, you create leverage and maximize your impact in the organization. That’s what is expected from a leader.
But it’s less discussed that mentoring is fundamentally about teaching. When you teach someone, you are practicing the third component of the framework.
So what about the other two components?
The subtle trap here is ego. The more experience you have, the more likely it is that ego can convince you that you don’t need a teacher. But that’s exactly when you need one most.
A teacher doesn’t have to be from your company or professional circle, it can be anyone: someone from the internet, a neighbor, a former colleague, anyone whose perspective challenges you.
In many careers (especially technical ones), almost everyone who passes the basic bar eventually reaches a “senior” level. Some companies even treat this as a terminal point with a defined progression timeline. But after that, growth becomes hard to define.
You can learn more stuff, but does that necessarily mean you’re growing? For me personally, merely accumulating knowledge is not enough.
So what’s the formula? I don’t think there is one. But having a teacher, a peer, and a student creates necessary, if not fully sufficient conditions for growth to happen.
]]>We often treat performance as a static grade: “She is a high performer,” or “He is struggling.” But performance is actually a function of speed. Specifically, the speed at which you detect gaps and the speed at which you close them.
Over and over I see people making the same mistake by looking at their or their team’s performance as a “grade”, but the reality changes when you start looking at the clocks of performance instead.
Time to Awareness is the latency between reality changing and you realizing it. This is the most dangerous clock because it ticks silently. You can have a TTA of six months and feel perfectly fine the entire time.
In engineering systems, we have tools (like the Grafana ecosystem) and alerts to keep TTA near zero. If a server goes down, we know in seconds. In human systems, we have… “politeness.” We rely on social signals, which are often noisy. Managers delay feedback to “gather more data.” Peers don’t want to be “mean.” We avoid self-reflection because it’s uncomfortable.
High TTA is usually a symptom of a low-feedback environment (or a low-receptivity mindset).
Time to Resolution is the latency between knowing the truth and fixing it. Once the first clock stops (you know there is an issue), the second clock starts. This is where the work happens.
High TTR is rarely about laziness, it’s usually about ambiguity. “Improve system design” is a terrifying, vague goal. It’s too big to fix on a Tuesday afternoon. So we procrastinate. We wait for a “perfect time” to study that never comes.
High TTR is a symptom of poor definition.
If you plot these two against each other, you can map every stage of your career:
You cannot wait for your manager to tell you the truth. You have to hunt for it. Quantify your output: Don’t just “work.” Log what you shipped. Look at it at the end of the week. Does it look like a Senior Engineer’s week? If you don’t know, ask.
Ask for “leading” feedback: Instead of “How am I doing?”, ask “What is the one thing I could have done better this week?”
The only way to reduce TTR is to break the fix down until it looks like a ticket. Turn “Growth” into “Input”: Don’t put “Get better at communication” on your to-do list. Put “Write a 1-page RFC for the API migration” on your calendar.
Measure the inputs: If you want to improve, track the effort, not just the result.
The best engineers I know treat their career like a production system. They hate latency. They don’t wait for the quarterly review to find out if they are on track. They look in the mirror every week. They catch the drift early and course-correct before anyone else notices.
]]>But it hasn’t all been rainbows, I had moments where I wondered if I was actually growing or just hanging around. So, I’ve been reflecting on the reality of staying put in a hyper-growth environment. To stay in a “cliché” zone, I thought to write 5 learnings and 5 challenges from the last years.
You can’t cheat evolution: I see many startups today scaling to $100M revenue in six months with zero infrastructure or telemetry to sustain it. Then they hit the wall. You can cheat many things, but you can’t cheat evolution. It takes time to mature. Time works for you, but only if you let it. Scaling isn’t a magic trick; it requires repetition, mistakes, and corrections.
The ROI of people: I always knew the theory, but seeing it play out in real life is different. People are the most expensive investment and the biggest return. Scaling from 4 to 1200 doesn’t happen without continuous investment in people. Grafana Labs is remote, but the level of care I’ve seen here restored my belief that corporations can actually be humanistic.
Diplomacy is not politics: We overuse the word “politics” so much that everything becomes politics. But that isn’t true. Politics is power-playing; diplomacy is navigating complexity in a way that preserves trust. Scaling organizations require the right diplomacy.
Community is the strategy: Customers and community are not “third parties” you occasionally interact with and need to sell a product. They are part of the strategy. Honestly, they are part of the family. Long-term success comes from a symbiosis of internal and external collaboration, thus you cannot build in a vacuum.
Your career is built, not given: No matter how supportive your environment is, no one will steer your career except you. The moments where I grew the most were the ones where I actively shaped my own path—changing scopes, redefining responsibilities, and asking for alignment. Your career does not “happen.” It is built, step by step, by you.
The tectonic plates of scale: The complexity of scale sneaks up on you. At 200 people, everything feels manageable. At 800, invisible cracks appear. At 1200, the cracks turn into tectonic plates. Navigating that shift required relearning what “alignment” even means.
Emotional asymmetry: Remote work is incredible, but it is emotionally asymmetric. You don’t see people in the hallway. You don’t sense tension early. Sometimes you discover problems only when they are fully grown trees, not when they are seedlings. You have to work twice as hard to keep your finger on the pulse.
Uneven growth pace: The speed of growth means not everyone grows at the same pace. Some people outgrow their roles, some fall behind, and some freeze. Managing that dynamic in fair and humanly way is one of the hardest parts of leadership.
Adrenaline vs. Systems: The temptation to optimize for short-term output is always there. The industry chases “ship faster” and “deliver more.” But great teams don’t survive on adrenaline; they survive on systems. Resisting the adrenaline rush was often harder than embracing it.
Uncomfortable truths: Being honest about culture is uncomfortable. Every company has blind spots, and pointing at them can feel like poking the bear, but avoiding it only makes the culture smaller. Learning how to name uncomfortable truths without being destructive, that was the real challenge.
Here is to the next chapter. Grafana Labs here to stay! Also, we are almost always hiring
]]>But lately, I’ve been realizing that this advice, while well-intentioned, is often vague. Worse, it’s unfair. When we tell engineers to aim for “impact,” we are asking them to set a goal based on a variable they have almost no control over.
In my posts about quantifying performance, I often use a simple formula:
Performance=w1(Input)+w2(Output)+w3(Outcome)+w4(Impact)
The further you move to the right of this equation, the less control you have. Impact is often a lagging indicator, sometimes lagging by years.
Telling someone to “control business impact” is just gambling.
Let’s look at a human example. Say you spend months supporting a colleague who is struggling. Thanks to your mentorship, they turn a corner and, two years later, they are absolutely killing it. How do you calculate the “business impact” of those coffee chats you had two years ago? You can’t. But the input, the act of mentoring was high quality.
Why do we managers keep saying this? Because measuring performance is incredibly hard.
As I wrote in Performance of an Engineering Manager, managers are often judged by the output of their team. We fall into traps like “Hero-based success” or “Burnout-driven delivery.” When we don’t know how to measure our own inputs, we look for shortcuts. “Go find high impact” is an easy way out. It avoids the hard work of defining what excellence actually looks like on a Tuesday morning.
So, if you get this feedback, how do you handle it? You don’t just hope for a lucky project. You need a system.
In Ready for Promotion, I talk about the concept of “Working Backwards.” Don’t wait for the cycle. Write your promotion case now.
This shifts the focus from “hoping for impact” to “behaving at the next level.” Promotions aren’t about potential; they are about demonstrated ability.
There is a flip side. Sometimes, you execute perfectly, your inputs are solid, your outputs are great, but the impact never comes. Maybe the market changed. Maybe the strategy pivoted.
This is where you need to look at your Career Map.
If your daily inputs aren’t resulting in value, you have to sit with the harsh reality. It’s not about “chasing impact” anymore. It’s a question of fit. Does your current role align with your values? Are you solving the right problems?
If your horizon for promotion is 12 months, but the company’s “high impact” projects take 2 years to materialize, the math doesn’t work.
Incentives in our industry can be messy. But you can bring order to the chaos. Reframe the conversation: Don’t accept “high impact” as a goal. Ask to define the inputs and outputs that represent success.
Focus on what is in front of you. That is where the work actually happens.
]]>A few weeks ago, his school gave us feedback: he should try to influence group dynamics more and speak up in group activities. Fair enough. I caught myself realizing that I often delivered the same feedback to my team members, peers, and colleagues as well.
Why is group influence always the goal? Why do we assume that the ability to perform well in groups is a universal skill everyone should master?
Most of us grew up learning that teams are the foundation of success. Schools encourage group projects. Startups celebrate collaboration. Companies structure everything around squads, pods, and cross-functional units. And I’ve believed that too. For the longest time, I held the view that the smallest unit of meaningful delivery is a team.
There’s something we don’t talk about much. Some of the most important breakthroughs in human history happened in solitude. Einstein. Wozniak. Ada Lovelace. These weren’t group brainstorms - they were quiet moments of focused, deep thinking. Time spent alone.
Of course, they didn’t operate in complete isolation, no one truly does. But their foundational work came from within. And the more I reflect, the more I wonder: are we over-indexing on collaboration and underestimating the power of solitude?
As a leader, this topic has hit close to home. I’m someone who loves a fast-paced discussion. I’m energized by meetings. I’m that person who can make snap decisions and improvise on the spot. For years, I saw that as not just my strength, but the best way to work - maybe even the only way to get great results.
What I’ve learned is that not everyone works like that. And more importantly: they shouldn’t have to.
Instead of trying to get everyone to thrive in meetings, I’ve started asking: What would it look like to create environments where solitude is not only allowed, but celebrated?
Remote work helped me see this more clearly. In most office environments, there’s almost no real solitude. There’s always noise—conversations, distractions, context switches. It’s often assumed that working together physically means working better. But for deep thinkers, introverts, and reflective types, that environment is exhausting.
Remote setups can create more space - literally and figuratively. But even then, we have to be intentional. Solitude doesn’t just happen - it needs design.
I often ask myself: How can we build systems that include people who think better alone? Not as an afterthought, but as a design principle.
We recently ran the “Subarctic Survival” exercise in our team. If you’ve done it, you know the drill: everyone ranks survival items individually, then does the same as a team. What was surprising? A few individuals actually outperformed the group.
It’s not peer-reviewed science. But it reminded me again that the common wisdom - “teams are always smarter than individuals”, isn’t always true. It depends. And it deserves nuance.
I don’t have a perfect formula, but I’ve started to gather some principles and habits that seem to help.
Set aside days where the default is focused, individual work. No meetings. No Slack pings. No group check-ins. Just quiet, uninterrupted time. Yes, it has trade-offs. But it also trains the “solitude muscle” for those who rarely use it, and gives space to those who need it.
In onboarding, 1:1s, or team-wide rituals-create space to share how each person prefers to work. What drains them? What helps them recharge? If someone thrives in writing and hates real-time debates, it shouldn’t be a secret.
This isn’t just “getting to know each other” - it’s operational knowledge.
If most people in your team are verbal, fast, and collaborative, they will naturally dominate decision-making. That’s not bad, but it is biased. Introduce systems to balance it out. For example, default to writing before discussing. Give everyone time to think before deciding. Normalize saying, “I need a day to sit with this.”
Asynchronous work isn’t just a scheduling trick. It’s a form of inclusion. It allows people to reflect, articulate, and contribute without being “on” in the moment. Use it for more than status updates. Use it for decisions, feedback, even brainstorming.
Silence is valuable. In most group settings, silence feels awkward - so someone fills it. But that “filler” often silences the people who need time to think.
Teach your team that silence isn’t a problem. It’s space. Don’t rush to fill it and let it breathe.
Not everyone wants to lead a discussion. Not everyone wants to whiteboard an idea in front of others. And not everyone should have to.
Some of the most thoughtful people I’ve worked with are slow to speak, but fast to understand. Their work doesn’t always show up in a meeting, but it shows up in impact. We need to make space for that kind of contribution.
We treat teamwork as a skill to build. But solitude is a skill too. One that’s often overlooked, dismissed, or even discouraged.
I’m learning to stop seeing solitude as a deficit. It’s not something to fix. It’s a strength to recognize, nurture, and design for.
Because not every great idea is born in a brainstorming session - some are born in silence.
]]>Until it isn’t.
Over the past few months, I’ve noticed something subtle but persistent happening in one of the platform efforts I’m part of. We have two squads working toward a shared goal. Responsibilities are clear enough, we have DRIs in place, and we all show up as one unified team to our stakeholders. But underneath that surface-level alignment, sometimes decisions are getting stuck.
Not because of conflict. Not because of apathy. But because of kindness.
When ownership is distributed but not tightly coordinated, you start to see a familiar pattern: people waiting. Waiting for others to chime in. Waiting not to overstep. Waiting for the product manager. Waiting for a consensus that never quite arrives.
It’s a polite pause. Everyone wants to do the right thing. No one wants to push too hard. But the result is the same: time slips away, decisions take their own time, and progress feels slower than it should.
I’ve been guilty of this too. As a manager, I try to practice servant leadership. I want the team to lead, to grow, to own. But that can quickly become a trap - you wait just a bit too long to intervene, trying not to be too directive, and then realize that everyone else was waiting too.
So the question becomes: how do we keep our culture kind and collaborative, while still moving forward with momentum?
One simple practice to explire is the idea of a temporary DRI (Directly Responsible Individual) - someone who steps up to own just the next step or decision. Not the whole project. Not the full outcome. Just the moment that’s currently stuck.
It doesn’t have to be the manager. Or the product owner. Anyone can say: “I’ll take temporary DRI on this until we close the loop.”
That’s it. It gives the team a driver without creating hierarchy. It builds agency and it keeps momentum. And it reduces the ambiguity that often paralyzes distributed teams.
The second cultural shift you can try is to reframe how you think about escalation. Instead of treating it like a failure mode, you treat it as a service.
“I’m escalating this not because someone dropped the ball, but because I want us to decide and move on.”
Escalation as a service helps people feel safe surfacing blockers. It prevents things from quietly drifting. It respects people’s time and mental energy.
It also normalizes one of the hardest things in distributed systems - surfacing uncertainty early, rather than waiting for perfect clarity.
Sometimes we defer decisions too long by saying, “this is a product call.” And yes, sometimes it is. But more often than not, it’s a team call. And what’s missing is not clarity of responsibility - it’s clarity of decision authority.
One small but powerful change you can make is to add a section to design docs and RFCs:
**Decision Owner**: [Name here]
Responsible for reviewing input and making the final call. Consults with stakeholders, listens to feedback, then decides.
This removes ambiguity. It makes decisions feel real. And it avoids the quiet deferrals that otherwise accumulate in shared work.
What I’ve learned in all this is that kindness and clarity are not opposites. You can lead with care - and still make calls. You can empower others - and still frame the boundaries. You can stay quiet, but only until the pause becomes a drag on the team.
Distributed ownership works. But it needs small rituals to keep it moving. These aren’t heavy processes. They’re small tools to help us do what we already want to do: Work well together, move forward and stay kind along the way.
]]>You can train yourself to handle these situations well, build the muscle, develop frameworks, but it never becomes easy. And deep down, I’ve always wanted it to be easier.
Over time, I learned to do the hard thing. But I kept wondering: is there a way to make it simpler?
When it comes to performance, a few challenges keep showing up:
Feedback - whether you’re giving or receiving - triggers insecurity. We crave safety and predictability. There’s a primitive survival mechanism in our brains: if we can predict what’s coming, we feel safe. If not, our alert systems fire up. That’s why the darkness is scary and daylight isn’t. So the core question becomes: how do we make performance predictable? What leading indicators can increase our chances of knowing where we’ll end up in N months?
These two metrics - TTA (Time to Awareness) and TTR (Time to Resolution) - quietly drive a huge portion of performance outcomes.
Together, they lead to misalignment, wasted time, and preventable exits. So I ask myself: how do I reduce both TTA and TTR?
Some level of self-awareness is common. But radical self-awareness - the kind that forces you to face uncomfortable truths about your performance, strengths, and growth gaps - is rare. And that’s understandable: the truth can feel threatening. But I believe performance quantification can be a powerful trigger to start this kind of self-inquiry.
I’ve written about these ideas before - how I think about performance quantification for individual contributors and engineering managers. And while the theory made sense, putting it into practice has always felt hard.
So I decided to try something new: make it simple. At least, simple enough.
My starting point was a single idea:
Imagine a world where nobody has to tell you how your performance is going - because you already know.
Not only that, you know your strengths (with evidence), your growth areas (with clarity), and you know what to do more of or less of. You’re not waiting for feedback or calibrations to course-correct. You’re running your own process.
But that world is hard to reach. Most people get stuck on two things:
I explored this in another post: managing growth and your career, which outlines a journey that starts with:
But I felt we needed more than a framework. We needed a tool.
So I built one. It’s a small web application called performance mirror, based on the ideas from my blog posts. It’s still early and basic, but here’s what it can already do:
The whole thing was vibe-coded in Cursor. It felt great to build, because it felt useful. This is a tool I wish I had for the past 10 years.
As a proof-of-concept, the app does its job. But like any first version, it has its limits. The architecture is messy. It’s growing in complexity.
So now I’m asking: What’s next?
We’re living in a time where building apps is easier than ever-thanks to AI, you don’t even need to vibe-code from scratch anymore. What matters most is choosing a narrow, real problem to solve. If it’s a real pain, the solution doesn’t need to be fancy. It just needs to help.
So here’s where I’m going next:
A career coach that knows your journey
Tracks your history across jobs, accomplishments, struggles. Helps you find growth opportunities and make smarter moves.
Pluggable integrations
Pulls in data from GitHub, RFCs, project tools-wherever your work lives.
Quantified performance with real recommendations
IOOI-based performance tracking with tailored advice. Helps you reframe, recover, and progress.
Faster feedback loops
Helps you reduce TTA and TTR-so performance issues don’t linger, and progress doesn’t stall.
This is not a performance monitoring tool for managers or HR.
It’s a mirror. A tool to enable radical self-inquiry. A private coach. And a choice: to reflect, to share, or not.
Super excited about this journey. Let’s see where it goes.
]]>