About


Hey hey, I’m Eric – a life long engineer, leader, (published) author, military combat veteran, and martial artist who enjoys helping people and systems perform at their best. Across my work in technology, consulting, and team leadership, I’ve learned that strong organizations are built through communication, structure, and thoughtful habits. I share those lessons through my writing, management training videos, and my podcast, “Beyond the Belt”, where I talk with other BJJ Black Belts who’ve pursued excellence in their passions and lives.

Whether it’s building software, coaching managers, or exploring the mindset behind high-level performance, I care about helping people grow in a way that feels real, practical, and sustainable.

Reach out to me if you have questions or come take a BJJ class with me at Fenriz Gym in Berlin, Germany.

If you want my posts delivered as they go live with no fluff, subscribe to the newsletter or follow me on Substack.

Latest Writing


All Writing

You Can Only Push Decisions as Far Down as Context Travels

I keep hearing a version of the same question: how do I get people to make more decisions themselves?

There are plenty of reasons people don’t make decisions. Analysis paralysis. No time to think. Unclear authority. Not wanting to own the outcome. But even when someone is willing and allowed to make a decision, they may not have enough context to do it responsibly.

To state the obvious, leaders tend to have more context because their roles put them in front of more information. They hear the customer commitment, the strategy discussion, the adjacent team’s plan. But when leaders push decisions down, the people receiving them often see only the part immediately in front of them.

You can’t “attend more meetings” your way out of this. Most people are already nearing information overload. And besides, people miss meetings, take vacations, get sick, and have their day jobs to focus on. Presence is finite. It always was. Context was concentrated in senior people long before things like automated meeting transcripts and summaries came onto the scene.

This is not an AI-created problem. But having AI tools at our fingertips does make a different response possible. And the fix isn’t in the calendar. It’s in where the context lives and how people can use it.

Authority Travels Further Than Context

Most organizations have absorbed the advice to push decisions to the lowest appropriate level. I give that advice myself; it’s core to how I think about leadership. But nearly all of the discussion around it is about authority. Are people allowed to decide? Will their manager override them? Will they be punished for being wrong? Are they being forced into decisions that they will have to own? Those questions and their answers are critical to how your organization functions. Sometimes, permission really is missing. Sometimes it exists, but nobody has made it clear enough for people to trust that they can use it. And sometimes, people know they are allowed to decide, but don’t have enough context to defend a difficult decision.

Frustratingly, all three look similar from above: the decision travels upward looking for approval, whether that approval was actually required or not.

The first two reasons decisions travel upward are permission problems. You fix them by making the authority clear and then behaving consistently when people use it. The third is different, because the right context is often hard to come by. It sits in leadership meetings, roadmap discussions, customer calls, too many Slack channels, and the heads of a handful of senior people. In distributed systems terms, this is a routing failure: the authority propagated to nodes the information never reached. Then everyone wonders why decisions keep escalating to the same three people.

You can only push decisions as far down as context travels.

The Advantage of Seeing More of the Organization

Watch what happens when an engineer decides to deprecate an endpoint. Traffic has been near zero for months, the code around it is brittle, and removing it is unambiguously the right technical call. This is something the engineer, as the maintainer, understands better than anyone above them. What they may not know is that one large customer still calls it from an integration nobody documented and that sales committed to supporting it through a renewal the next year. When they escalate to validate their decision, the senior person doesn’t answer with deeper technical insight. It usually sounds something like, “Not yet — there’s a customer commitment.” How could the engineer possibly have known about this?

Some of what looks like senior judgment is really senior access. Experience, pattern recognition, and accountability are all real factors. A staff engineer does not become a CTO because an AI read and summarized a stack of transcripts for them. But a non-trivial percentage of the gap between the person escalating and the person answering is that one of them has been part of more conversations.

That access gap compounds. More context gives someone a better basis for making a decision, which makes them more willing to own it. Each decision they make from that broader view also gives them more experience for the next one. Context does not guarantee the right call, but it helps build both the confidence and judgment required to make more of them.

That leaves the practical problem: how do you give more people access to that context without putting them in every room?

Stored Knowledge Is Not Available Context

Organizational memory isn’t a new idea. Tools like Confluence, Notion, decision logs, and shared drives have been preserving what organizations know for a long time. But that knowledge remained passive. To use it, someone had to know it existed, know where it lived, search for it, interpret it, and carry it into the decision.

The person was always the last mile. When retrieval is unreliable and disconnected from the work, people have less reason to keep the underlying knowledge accurate. That is one big reason wikis go stale even when the storage itself works.

AI changes the operating pattern, not the storage. When meeting transcripts, Slack channels, roadmaps, customer records, QBR notes, and code repositories become part of the same queryable memory, knowledge no longer has to wait for someone to find and carry it. A sales loss from two quarters ago can become an input to a strategy discussion. A customer insight from a QBR can surface in product work without the account team repeating it in yet another meeting. Meeting transcripts turn conversations that would otherwise disappear, into durable inputs the rest of the organization can use.

Wikis preserve organizational memory. AI lets that memory participate in the work.

This is what we’ve been building at Mapp, deliberately and incrementally, inside an existing organization rather than a blank-slate one. Strategy meetings, stand-ups, and leadership meetings are recorded and transcribed into Notion. The roadmap lives there. Agents watch specific Slack channels. I’ve written before that AI made delegation cheap and decision visibility expensive. This is part of what I am doing about it: making more of the context behind those decisions available when people need it.

The capability underneath all of it is not transcription or summarization (although those are capabilities). It is the ability to ask the organization what it knows: to pose one question across meetings, Slack, roadmaps, customer records, and code instead of searching each source separately or finding the right three people. What other teams does this impact, and what would we deprioritize to do it now? Does it conflict with an existing customer commitment or a direction that hasn’t yet reached the roadmap? Has something like this already been discussed by leadership? Answering those questions used to take several conversations, access to senior people, and/or knowing exactly where to look. Now they can be asked directly, and more importantly, they can be asked by people who were never in those rooms.

This is what people mean when they talk about democratizing access to information. You are not giving everyone access to everything. You are making relevant organizational context available to the people expected to act on it.

Context Needs a Predictable Home

A queryable memory is only as useful as the context it can reach. If QBR notes live in personal documents, customer commitments in DMs, and meeting transcripts wherever each team happened to put them, AI has the same problem people do: the information exists, but there is no reliable way to find it.

That doesn’t mean everything needs to live in one tool in one specific location. It means each kind of information needs a predictable home, and the systems containing it need to be connected. Recording meetings isn’t enough if nobody knows where the transcripts land or whether the meetings are being recorded consistently. Queryable also does not mean automatically visible to everyone in the company all the time, for every meeting. The system should only use the context that the person asking is permitted to have access to. Once those foundations are in place, the same infrastructure can support several different ways of moving context through the organization.

The Rooms You Couldn’t Be In

The first use is recovering context you missed. You just need to understand what happened in a room you couldn’t be in. Until recently there were two ways to find out: ask someone, or have someone write it down for you. Both spend somebody else’s time and your social capital.

In practice: a week of stand-ups

Most of our engineering teams transcribe their stand-ups. A director or VP can ask what happened across their teams that week: what shipped, what’s blocked, what’s quietly at risk, how something was implemented, or which topics consumed unusual amounts of airtime. The answer arrives without another meeting or another status report. Leaders still need regular conversations with their leads to interpret what they are seeing. But situational awareness no longer requires attendance at every ritual or another reporting layer.

There is an obvious “big brother is watching” vibe here. But looking for blockers and recurring risks is leadership work. Looking for who spoke the least during meetings is surveillance. People will work out which one you are doing much quicker than you think (don’t big brother people).

I use the same pattern before briefing my technology leadership team. I ask the AI to summarize what came up in the senior leadership meeting from a sales, marketing, customer, and operations perspective, then decide what belongs on our agenda and what doesn’t. I’m still the relay. I’m just a less lossy one because I’m no longer reconstructing the meeting from memory and notes I half-wrote while trying to pay attention. The time I used to spend remembering what was discussed can go to the part that actually needs me: explaining why it matters to them and their teams.

Ask the Organization What It Knows

The more interesting version of this is someone asking the organization what it knows before making a call. This is where decisions can start moving down the org chart. Once authority has genuinely been distributed, context becomes the next constraint.

In practice: checking against strategy that isn’t written down yet

Our Head of Product built an MCP server over our product roadmap in Notion so anyone in the company can ask roadmap questions from whatever tool they already work in. I described the whole system in What Gets Lost When Becoming AI-Native. The important part isn’t that the MCP answers roadmap questions. It’s that it doesn’t answer them from the roadmap alone. It combines the formal roadmap with surrounding context from Notion, Jira, and Slack so the answer arrives already framed for whoever is asking. The roadmap is the artifact; the surrounding context is the reasoning. A conversation can show emerging intent, but it does not become an organizational decision just because it was transcribed. The system preserves that distinction when it combines the two.

We’ve since extended what the Roadmap MCP can reach. Because it now spans conversations from across the organization, repetition itself becomes a signal. When the same idea keeps surfacing independently, someone can ask whether it appears to be part of an emerging direction, even if it hasn’t yet made it onto the roadmap, and see the evidence behind that conclusion. Recognizing that pattern used to require being in several of those rooms.

A local decision can be checked against both the formal plan and the organization’s emerging intent, which rarely live in the same document.

The Questions That Used to Require a Title

Checking one decision against strategy is only one version of this. The more important shift is that questions that once depended on senior access can now be asked much lower in the organization.

Engineers and other individual contributors ask “who does this impact?” more frequently than they get credit for. The harder part is knowing where the impact might show up. Asking about the blast radius is one thing. Knowing to check customer commitments, contracts, migrations, and adjacent teams is another.

Senior people are better at that partly because they have watched those failures happen before. They have seen an endpoint deprecation become a customer problem, collide with a contract, or disrupt another team’s migration. That pattern recognition is real, usually learned through pain, and no amount of querying for context can manufacture that kind of experience.

They are also more likely to know who to ask and where to look. That is a different advantage. Some of it comes from experience, but much of it comes from having had access to more of the organization for longer.

But knowing where to look only helps if the person can reach the information. They can understand which questions matter and still not be invited into the meetings, channels, or systems where the answers live. When organizational memory becomes queryable, questions that once depended on knowing exactly who to ask, can now be answered across the organization’s accumulated context.

The scoping gets cheaper even when the calibration doesn’t.

It becomes easier to identify which customers, commitments, teams, and systems a decision might affect. Deciding how much each one matters still requires judgment. And AI doesn’t give people better judgment. But it does give the judgment they already have more context to work with.

That is one mechanism for pushing decisions down: not another policy change or round of encouragement, but removing one of the reasons that decisions needed to keep traveling upward.

When Nobody Has to Remember to Ask

So far, a person has still had to know which question to ask. But some forms of triage repeat predictably, and the places to check are stable enough that a human doesn’t need to run through them every time.

In practice: the product-feedback pipeline

We have a #product-feedback Slack channel. One agent watches it, gathers more information from the feedback reporter when necessary, and stores every request in a Notion database. A second comes through behind it and performs the initial triage a human, usually a Product Manager, used to do manually. It checks whether the request resembles something we have already shipped, whether it intersects with the roadmap, which repositories it may touch, and whether it looks like a “quick win” (something achievable in a day or two of work). It then produces a rough feasibility assessment. A human validates the answer, adds context the system can use the next time a similar request appears, and decides whether the work moves forward. The decision is still theirs. The difference is that more of the surrounding context arrives with the request.

These are three different uses of the same infrastructure: recovering context you missed, asking the organization what it knows before you decide, and letting an agent answer recurring questions or perform repeatable triage or investigations. I don’t think any one of them is more advanced than another. The right choice depends on how stable the questions are and how quickly the context underneath them changes.

“Is this a quick win?” is a fairly stable question. The places to check are known, and the shape of the investigation does not change much from week to week, so an agent can do the first pass.

Deprecating an endpoint is different. The customer commitments, migration plans, and strategy around it can all change. A person still needs to ask the questions, interpret what comes back, and own the call, even when AI gathers the context.

Across all three uses, the division of labor stays clear. None of these processes hands consequential decisions to agents. AI gathers and connects context. A person interprets it and, when there is a decision to make, remains accountable for the call. The quick-win workflow produces an assessment, not a roadmap change or a shipped feature.

Operational memory should expand what people can see before they decide, not blur who owns the outcome.

What Doesn’t Travel

This isn’t a perfect system. Nothing that involves humans ever is. But some of the gaps are structural rather than temporary.

Queryable memory still misses what nobody thinks to ask about. An ad hoc meeting can be perfectly recorded and transcribed and still disappear because nobody knows it happened or realizes it contains relevant context.

Presence used to create some of this discovery by accident (think water-cooler talk). You overheard something, got pulled into a conversation, or heard the same issue come up in several places. Search does not recreate that on its own. Trigger-based agents can surface recurring patterns without waiting for a question, but novel context can still remain hidden.

That leaves a job the tools don’t do for you: giving people enough of a map to know what information exists and what they can ask, without recreating the same information overload the system was meant to reduce.

Transcripts don’t preserve weighting. A person in the room hears the hesitation before the yes, the emphasis, and the thing half-said and then dropped. A transcript has the words without the weighting. That’s an interpretation problem, not a retrieval problem.

That missing human interpretation matters less when the source itself is authoritative. A signed contract, an explicit customer commitment, or a recorded decision can stand on its own.

But when the question is not simply what was decided, but what seems to matter, repetition across independent conversations becomes another valuable signal. If the same concern appears in a QBR, a strategy meeting, and several stand-ups, the pattern tells you something even if none of the individual transcripts preserved the tone.

Humans have the same limitation. Someone who attends only one meeting can also have an incomplete view. Judgment often comes from hearing the same concern in different ways and in different places. Querying makes that kind of triangulation much easier than being in every single conversation yourself.

Querying doesn’t build the pathways attendance built. Being present for the conversation, whether that means sitting in a conference room or joining a call, does more than transfer information. It builds relationships, trust, and an instinct for how the organization actually makes decisions.

Queryable organizational memory recovers part of the context function of attendance, not the developmental one. But it can create a different learning path when the questions are visible. Showing someone the answer is useful. Showing them the question that produced it — what other teams does this touch, which commitments constrain us, what does this make harder later — teaches them how broader decisions get thought through.

That is not the same as participating in the conversation, but it gives people a way to practice asking those questions and getting those types of answers before they hold a senior title and more responsibility.

Some people will still wait for the next meeting rather than ask the system. That’s fine. Some people make sense of context by talking it through, hearing the uncertainty, and asking follow-up questions in real time. A strong organization needs people who process information in different ways at different speeds. Queryable memory creates another path to context. It does not require everyone to process information the same way.

Escalation Isn’t the Failure

Those limits are also why escalation still has a place. Some decisions need more experience, another person’s judgment, or a live conversation before anyone should act. The failure is not that a decision moves upward.

In the broken version of escalation, a decision stalls in a Slack thread until the right senior person gets back from vacation, reads through the backlog, and finally decides what should happen.

In the better version, the person closest to the problem asks the organization what it knows. Sometimes they find the customer commitment they were about to break and make a different call themselves. Sometimes they still push the decision upwards. But when they do, they arrive with context already prepared: the relevant commitments, dependencies, and tradeoffs.

When leaders ask me how to get people making more decisions, the answer is rarely encouragement alone. It’s making sure decisions don’t travel upward simply because the context needed to make them was trapped somewhere else.

You can only push decisions as far down as context travels. And when the decision still needs to move, the context should travel with it.

Latest Manager Trainings Videos


All Training Videos

Motivation

In this episode, Eric explores motivation as a core leadership skill—what it is, why it matters, and how it shows up (or disappears) in day-to-day work. He breaks motivation down into intrinsic and extrinsic drivers, then walks through common causes and observable signs of demotivation, emphasizing the importance of knowing your people well enough to spot meaningful changes in behavior. Eric also draws a clear distinction between demotivation and clinical depression, outlining what a manager should watch for and how to respond with empathy and appropriate support rather than trying to “fix” it. The episode closes with practical strategies for re-engaging individuals and teams—through purpose, clarity, feedback, recognition, autonomy, and healthier working environments—plus question prompts leaders can use in 1:1s to uncover what genuinely motivates each person.

Building a Strategy

In this episode, Eric discusses the importance of building a strategy, emphasizing that it is often overlooked but crucial for effective leadership. He provides a framework for differentiating between strategic and tactical thinking and focusing on outcome-oriented approaches. The episode highlights the need for collaboration between product management and engineering to align goals and create a unified vision. Eric also stresses the importance of understanding market trends, customer needs, and competitive analysis to inform strategic decisions. He introduces various analysis frameworks like SWOT, SOAR, and NOISE to help teams evaluate strengths, weaknesses, opportunities, and threats. The episode also covers the significance of setting clear KPIs and proxy metrics to measure success and guide strategic execution. Finally, Eric encourages transparency and frequent communication to build trust and ensure understanding and alignment across teams.

Latest Beyond the Belt Episodes


All Episodes

Don’t Buy My Book, It’s Old

Straight to Your Inbox

Videos

Manager Training

Beyond the Belt

Writing Archives

contact