Forem: Balthazar de Moncuit

Your Demo Slot Is a Leadership Opportunity

Balthazar de Moncuit — Tue, 20 Jan 2026 07:45:00 +0000

Every two months, I stand in front of stakeholders and present what my team shipped.

For years, I did what everyone does: walked through features.

"We added an error page to the docs."
"We improved the callback API."

Checkbox. Checkbox. Next slide.

It's efficient. It's safe. And it's forgettable.

More importantly, it quietly trains the organization to think in outputs, not situations. A demo becomes proof that work happened — not a place where shared understanding is built.

But a demo slot is stage time.
And stage time is influence — whether you intend to use it or not.

Trying Something Different

Last Friday, I had a PI demo. New features in our component library.

The old version of me would have said:

"We added a comprehensive error documentation page listing all error codes and explanations."

That's accurate.
And it would have evaporated instantly.

Instead, I tried something else.

I told a story — and I gave the user a name.

"Meet Bob.
Bob is a developer integrating our authentication component into his research platform.

Without us, Bob is staring at weeks of work: identity provider quirks, permission matrices, undocumented edge cases.

With the component, he copies the quick-start example. Five minutes later, it runs.

Then it crashes.

He binds the error callback — like the docs suggest — and gets this message:
'Your test user lacks permission XYZ. Send this email to support. Response time is usually two days.'

Bob sends the email.
Two days later, it works. He's not stuck anymore.

Later, he discovers our error reference page and realizes something important: every failure mode is documented. He's no longer guessing. He can build."

Same features.
Same code.
Same sprint.

Different framing.

One is a deliverable.
The other is a worldview.

Why This Matters

Demos quietly teach people what kind of work matters.

A feature list teaches:

"Progress is shipping things."

A story teaches:

"Progress is changing someone's situation."

Those lessons don't show up as questions in the meeting.
They show up later — in how problems are framed, in what's considered "done," in which gaps feel uncomfortable.

They show up when someone says "Bob" — and everyone knows what that means.

A named character is a compression mechanism.
It turns an abstract "integrator" into a reference point the organization can think with.

In environments where "safe" means status reports and checklists, this models something else: that alignment comes from empathy, not precision slides.

The Signal I'm Looking For

I'm not expecting applause.

The signal I care about is delayed — and indirect.

Weeks or months from now, I'll listen for:

"Bob is stuck at this step."
"Bob's journey breaks here."
"Bob needs one last thing to close the loop."

If "Bob" ever reappears in a ticket, a meeting, or a backlog item, I'll know the framing landed.

If Bob never comes back — that's data too.

What Actually Happened

Nobody asked questions. No follow-up messages. No visible reaction.

It was a Friday afternoon PI demo on Teams. We wrapped. People went into the weekend.

The experiment is running. No results yet.

Try It Once

Nobody asked me to do this. Nobody rewarded it. The slot was mine. So I used it differently.

This connects to something I wrote recently: you often have more agency than you think — but only if you take it.

I came up with the story ten minutes before the demo. It showed. And I didn't even name the character — "Bob" arrived while writing this.

But I did it once. Imperfectly.

Next demo, pick one feature. Don't describe what it does. Describe who uses it. Give them a name.

Then watch what comes back.

Views and experiments described here are my own and don't represent my employer.

Most Micromanagement Is Invited

Balthazar de Moncuit — Tue, 13 Jan 2026 11:58:37 +0000

I spent years blaming management for micromanaging me. Turns out I was begging for it.

Not consciously. Nobody walks into a meeting thinking “please, take this decision away from me.” But that’s what I was doing. That’s what my team was doing. That’s what most teams do.

It took me three companies to see the pattern. And to realize I was part of it.

Nobody designed it. But once it exists, people with authority decide whether it continues.

The Accidental Education

My first real engineering job was in a startup. Tiny. No process. No handbook. No one to ask.

When something needed deciding, I decided. Not because I was competent—I was a mass of anxiety and Stack Overflow tabs—but because there was nobody else. The alternative to deciding was not shipping.

I made mistakes. Plenty. But I learned something I didn’t know was rare: when there’s no safety net, you build judgment. You learn to estimate consequences. You ship, you watch what breaks, you fix it, you remember.

I thought this was just how software worked. It wasn’t.

The Institution

A few years later, I joined a large public organization. Big digitalization project. Agile transformation. I thought I’d finally learn how “real” engineering worked.

We had sprints. Ceremonies. Retros. I had latitude on my UI and implementation details. It felt like ownership.

Then I hit authentication.

We were building a suite of internal applications. Users needed to move between them seamlessly. Basic requirement: log into App A, and App B knows who you are. That requires a central identity provider.

We didn’t have one.

I raised the issue. The response was polite and absolute: the infrastructure had been decided years earlier. In meetings. By people unreachable by the integration team. The architecture was politically frozen.

Reversing it would have meant admitting those meetings got it wrong. That had a cost. So the decision lived on.

I hacked together a workaround. Shared cookies under the same subdomain. It mostly worked. I documented the edge cases where it didn’t. Then I quit.

What I learned later is this: decisions made in rooms full of people tend to fossilize. Not because they’re good, but because undoing them has political cost. Seniority becomes a shield against revisiting them.

The Title Comes With Authority (On Paper)

Later, I joined a large organization as a tech lead. This time, I had real authority—at least formally.

The onboarding was full of modern language: lean product thinking, agile principles, outcome-driven development. I was optimistic.

It took time to understand how decisions actually flowed. Who influenced what. Where power really sat.

And then the frustration crept in.

Product decisions felt locked before the problems were even discussed. I blamed leadership. All of it. People preaching agility while it quietly failed underneath.

That story was comforting. It was also incomplete.

The Mirror

I started watching a very specific kind of meeting: decision meetings.

Here’s the pattern. A developer faces a technical choice—a library, a pattern, an approach. Instead of deciding, they book a meeting. Five or six people. An hour. At least one senior person present.

The stakes are usually low. A recoverable mistake. Something a well-paid senior engineer could decide alone.

The developer presents options. Discussion follows. Some engage, others stay silent. Forty-five minutes pass.

Then the most senior person says: “OK. Let’s go with option B.”

Meeting over. Decision made. Everyone was in the room. Nobody owns the outcome.

The manager didn’t want to be there. But by staying and breaking the tie, they become the decision mechanism. Every time.

They decide. They get invited again. The team notices. It confirms the belief they already had: decisions need approval from above.

The cycle feeds itself because authority intervenes at the wrong level: deciding outcomes instead of defining decision boundaries.

And who calls these meetings? Not management.

Developers. Tech leads. Us.

We ask to be micromanaged — and management rarely refuses.
We just don’t call it that. We call it “alignment.” We call it “collaboration.”

Agile without ownership is theater.

The Word We Don’t Use

Agile assumes ownership. Teams own decisions. Teams own outcomes.

But “ownership” isn’t a word we actually use. We talk about tasks and responsibilities. Ownership implies something harder: when something fails, it’s yours. Not the committee’s. Yours.

That’s terrifying in most corporate cultures.

“Fail fast” assumes failure is survivable. That a wrong call doesn’t follow you for years. That the market is liquid enough to absorb mistakes—you fail here, you learn, you get hired there.

In Switzerland—and across much of Europe—failure is expensive. I’ve seen it in my own career, and I’ve heard the same pattern from engineers at other companies across industries: a bad decision becomes a story. It resurfaces in calibrations. It colors perception for years. It accumulates as reputation debt.

The rational move isn’t to decide fast. It’s to make sure you’re never wrong alone.

The fear is rational. But rational fear is not a design constraint — it's a signal the organization has failed to make ownership safe.

So people optimize for shared responsibility. Meetings aren’t decision tools. They’re insurance policies. If this blows up, at least six people approved it. Including someone senior. Nobody’s career dies alone.

What Ownership Actually Requires

Across multiple organizations, in Swiss tech, healthcare, and finance, I’ve seen the same pattern. When I stopped blaming individuals, the real gaps became visible.

Vocabulary. We avoid “ownership” because we don’t mean it. Accountability happens after something breaks. Ownership happens before—the decision, the risk, the bet. Most organizations have rich language for blame and almost none for intent.

Data. You can’t own decisions about users you don’t know. Many developers can’t describe their users beyond job titles. Not “pharmacists”—which ones? The rural ones juggling three legacy systems? The hospital ones with workflows imposed from above?

If you’ve never watched a user struggle with your product, you don’t have insight. You have assumptions.

Domain boundaries. Every domain has red lines—legal, financial, safety, reputational. If you don’t know where they are, you can’t evaluate whether a decision crosses them.

This isn’t an excuse to escalate everything. It’s a reason to learn.

Method. People aren’t taught how to evaluate impact, reversibility, or blast radius. We assume judgment is absorbed through experience. It isn’t. It’s built by deciding, observing consequences, and adjusting.

Most organizations never allow that loop to run.

These aren’t nice-to-haves. They’re prerequisites. Everything else is process theater without them.

A Simple Way to Sort Decisions

Once those prerequisites exist, most decisions can be sorted quickly using two axes: reversibility and impact.

	Low impact	High impact
Reversible	Decide alone, document	Propose async, validate
Irreversible	Tech lead decides	Meeting justified

Three boxes out of four don’t require a meeting.

The hard part isn’t the matrix. It’s honesty about which box you’re actually in.

Fear upgrades everything to “irreversible, high-impact.” That’s the reflex to fight.

A gut check: if the worst-case cost of being wrong is less than roughly 10% of your annual salary, you can probably decide alone. That covers most library choices, most refactors, most architectural micro-decisions.

If you’re unsure, ask one peer. Just one. Dialogue sharpens thinking; committees dilute it.

If you’re escalating below that threshold, you’re not being careful. You’re being afraid.

Making It Stick

Frameworks don’t change culture. Habits do.

Ownership doesn’t have to be granted globally to exist locally.

It can be created inside a team, within explicit boundaries, even when the wider organization isn’t ready for it — and without waiting for permission.

The decision log. Decisions made alone still need visibility—not for approval, but for learning. Date, decision, context, alternatives rejected, owner. Public to the team.

When something breaks, you don’t hunt for blame. You trace thinking.

Normalize recovered mistakes. When a decision goes wrong and someone fixes it, say it out loud. Celebrate the loop, not just the outcome.

Protection from above. None of this works if the first mistake gets punished.

Tech leads: when someone on your team makes a call within their authority and it’s wrong, you own it upward.

Managers: same principle, higher leverage.

Break the cycle actively. If you’re in a position of authority, stop attending the theater.

Every time you show up and decide something that didn’t need you, you train the system to need you.

The Uncomfortable Truth

Ownership is uncomfortable by design. The real test isn't letting your team decide; it's letting them decide differently.

Most organizations don't actually want that. Ownership means mistakes. It means managers letting go. This is why it rarely survives contact with hierarchy.

If you can't watch your team make a call you disagree with without stepping in, you don't want ownership. You want compliance with extra steps.

Ceremonies are easier. But stagnating safely has a cost too—it's just not on any dashboard.

We're all training the system. But not all roles train it equally. We can also untrain it.

Views and experiments described here are my own and don’t represent my employer.

The DoD Experiment: A Diagnostic Tool in Disguise

Balthazar de Moncuit — Mon, 22 Dec 2025 19:49:37 +0000

This is part 2 of a series documenting an experiment with Definition of Done. Part 1: Trying to Fix 'Done' Before It Breaks Us

Two sprints in, the original hypothesis remains largely untested. The experiment was under-executed: one refinement session with the DoD, one ticket meaningfully shaped by it, and too much environmental noise to draw conclusions about delivery time.

But something unexpected emerged. The DoD didn't primarily change estimation—it forced the creation of a handbook. That handbook is now reshaping how the team talks about code, and surfacing problems the DoD itself can't solve.

Six items became fourteen pages

The DoD itself is minimal. Six items under "always included," a few conditional ones, explicit "never assumed." One page.

But enforcement requires shared definitions. "Errors are handled" points to a page describing the DomainError pattern and how errors bubble through the state layer. "Styling uses prefixes" needs concrete examples. "Code follows existing patterns" is meaningless unless those patterns exist somewhere outside people's heads.

The DoD became a table of contents. The handbook is the system it forces into existence.

This was anticipated—documented knowledge architecture was always a prerequisite. What wasn't anticipated was the volume, and how much of that knowledge had previously been implicit. Writing it down didn't invent complexity; it revealed how much implicit knowledge the system had been running on—and hiding. Fourteen pages today—fewer once the linter stops being technical debt and starts enforcing what shouldn't need prose.

Keeping documentation alive

Fourteen pages is a liability if it remains one person's opinions dressed as consensus.

The mitigation is structural: the handbook lives in the monorepo, written in markdown and mermaid, editable in the same PR as the feature that depends on it. "Update handbook" is a DoD item itself.

The logic: when you introduce a pattern, document it in the same commit. When you notice something missing, fix it where you are. The handbook isn't a parallel artifact owned by someone—it's part of the codebase, subject to the same review process.

So far, this structure is holding. Multiple developers have edited the handbook unprompted, in the same PRs as feature work. That's validation that ownership is starting to distribute.

What hasn't happened yet is pushback—someone proposing to change an existing pattern rather than just adding to it. A handbook nobody challenges may indicate passive compliance rather than genuine shared ownership. That distinction matters, and it's something I'm now watching for explicitly.

Documentation depersonalizes feedback

Before the handbook, code review feedback felt personal. "You should name this variable differently." "This error handling isn't complete." Each comment implicitly claimed authority.

Now there's a page. Naming conventions exist in writing. Error handling has a flowchart. When a comment says "per the naming conventions, this should use the hci- prefix" and links to documentation, the conversation shifts.

The reviewer isn't asserting taste; they're invoking an agreement. The correction comes from the system, not the person.

In these two sprints, about a third of PRs explicitly referenced handbook items—links replacing opinionated comments. Developers proposed additions when they noticed gaps. The handbook created shared language, but more importantly, it created distance between people and feedback.

One ticket, real numbers

Theory is one thing. Here's what the data actually looks like.

A technical debt ticket: document and consolidate error codes. Estimated at one day after refinement using the DoD. Actual time: two to three days.

The developer started the work and found a mess—error codes scattered without consistent patterns. The instinct was natural: fix the system while you're in there. He began refactoring how error codes work across the codebase. Necessary eventually. Not in scope.

"Refactoring adjacent code" sits explicitly under "never assumed" in the DoD. The ticket had been refined with that in mind. The refactor wasn't part of the estimate because it wasn't part of the agreement.

The intervention happened mid-refactor, not before. The response was simple: the DoD had just gone live, so this one passes—but look at the line. The estimate didn't include this work. Without it, the ticket would have landed on time.

There was no pushback. In Sprint Review, the developer brought up the conversation himself as an example of how the DoD would help going forward. The DoD didn't stop the refactor. It made visible an investment that would otherwise have stayed hidden in "it took longer than expected." That visibility is the leverage.

What Product saw

Product didn't resist the DoD—they adopted it. Refinement became methodical: take the ticket, run through the DoD. "Always included"—how long? "Never assumed"—do we need any? What's the cost?

Their response wasn't compliance. They proposed embedding DoD items directly in the ticket template.

The real test hasn't come yet: a ticket where DoD-complete estimates are dramatically higher than expected. When that happens, the system either produces explicit trade-offs—include the work or defer it as documented debt—or it buckles under pressure to "just ship." That moment will reveal whether this is process or theater.

Adoption at capacity

In direct conversations, motivations diverge.

Some see the system working and advocate for it. Others are more guarded—process frameworks have come and gone before, and this one looks like more overhead without guaranteed payoff.

The framing that landed with skeptics wasn't aspirational. It was defensive: this is for us, not for anyone else. It clarifies what we agreed to build. It tracks technical debt explicitly. And if gaps become problems later, there's a paper trail—tickets written, trade-offs documented, decisions made with eyes open.

Cynical? Maybe. But practical. And it works. Skepticism hasn't blocked adoption; it's shifted the motivation. Some believe the DoD will make things better. Others believe it will make things defensible. Both are contributing.

What the DoD made visible

The DoD was meant to clarify what "done" means for a ticket. It ended up clarifying something else: scope.

The handbook documents error handling, WebComponent patterns, state management, styling conventions, SSR concerns, authentication flows. Fourteen pages of technical decisions—all within a coherent perimeter.

Here's what that looks like in practice: when a handbook pattern needs discussion in standup, 80% of the room has no context. When Sprint Review evaluates DoD compliance, most attendees can't assess it. The coordination the DoD requires doesn't map to the current rituals—not because the rituals are wrong, but because they serve a broader group.

Reading the handbook back, a question surfaced: whose work is this actually describing?

The answer isn't "the frontend half of a full-stack team." It's closer to "a product team that consumes an API." Our monorepo has its own backend concerns—auth, session, SSR. Our touchpoint with the backend team is contractual: API shape, response formats, error codes. Day-to-day, the collaboration is minimal.

This isn't a criticism. Teams evolve, structures shift. But the DoD forced an articulation of what we actually build—and that articulation suggests a perimeter that might deserve its own coordination rhythms.

What that looks like, I don't know yet. But the next step is concrete: map the actual coordination flows, evaluate options for dedicated frontend rituals, and test whether the mismatch is friction or fracture. That's Part 3.

The current state

The estimation hypothesis remains unvalidated. Testing it properly requires protected refinements, tracked estimates versus actuals, and more samples.

What exists now: a 14-page handbook in the monorepo, edited by multiple developers. A DoD that Product wants embedded in ticket templates. A shared language that depersonalizes feedback. A structural mismatch now impossible to ignore.

The DoD was meant to fix estimation. Instead, it surfaced what estimation had been compensating for.

Whether it ultimately improves delivery is still open. But for the team, the question has shifted from "why did this take so long?" to "what are we actually agreeing to build?"—and that's a different starting point.

Views and experiments described here are my own and don't represent my employer.

The DoD Experiment: Trying to Fix ‘Done’ Before It Breaks Us

Balthazar de Moncuit — Fri, 21 Nov 2025 22:17:43 +0000

This is the first in a series documenting an experiment: bringing clarity and explicit agreements to a distributed engineering team. Starting with something deceptively simple—the Definition of Done.

I've been putting off writing about my work for years. The excuse was always the same: "I'll write once I've figured it out."

Which is bullshit, obviously. You never figure it out. You just accumulate scar tissue and call it experience.

The truth is simpler: I was waiting to have a success story worth telling. Because who wants to read "here's what I'm trying, it might crash"?

Turns out, that's exactly what's interesting. The messy middle where you don't know if your hypothesis is brilliant or stupid.

So here we go. I'm a frontend lead at a Swiss healthcare company, and I'm about to try something that will either improve how we work or confirm that I've been solving the wrong problem for months.

Place your bets.

How it starts...

Last month, we shipped a fairly standard feature.

Straightforward on paper: some UI, some interactions, some integration points.

Estimation: 3 days.

Reality: 9 days.

The search for answers

I spent evenings reading the GitLab handbook. Procrastination disguised as professional development.

I fell in love with it. The async-first culture. Everything written down. Everything accessible. No one's productivity held hostage by someone else's calendar.

My first thought: "We should do this. Better Confluence structure. Better Teams channels. Clear async workflows."

I started sketching out the infrastructure. How we'd organize channels. What notifications would go where. How documentation would flow.

Then it hit me: I was designing the plumbing for a house with no foundation.

The culture problem

GitLab's async-first approach doesn't work because of their tools. It works because of their culture.

But what is that culture, exactly?

Trust? Sure, but trust in what?

Shared understanding? Getting closer.

The ability to read something once and know what's expected? That's it.

When everyone agrees on what "complete" means, you don't need meetings to clarify. When systems are documented, you don't need to interrupt someone to understand them. When definitions are explicit, you don't need to negotiate scope on every ticket.

The async infrastructure is the result, not the cause.

What was under my nose the whole time

During sprint reviews, developers had been pointing it out: "We don't have a Definition of Done."

Not as an accusation. As an observation. A problem they saw but couldn't fix themselves.

Basic stuff. In every agile textbook. Some of my developers were actively advocating for it.

And I'd been nodding along, thinking "yeah, we should have that," while not realizing the obvious: as the lead, bootstrapping that Definition of Done is my job. Not Product's job to define. Not the team's job to spontaneously create. Mine to initiate.

I needed it to come from GitLab—from somewhere that felt authoritative—to actually understand what I was looking at.

Slow learner. Or maybe just immune to anything that doesn't come wrapped in a 300-page handbook from a company I admire from a distance.

The hidden cost of implicit contracts

That feature that took 9 days instead of 3? Here's what actually happened:

I forgot to apply my own error system and spent overtime retrofitting it. We had to refactor how Tailwind works in our monorepo—something we'd never anticipated. Public documentation wasn't in the scope, but integrators needed it. We fixed technical debt along the way because we couldn't ignore it once we saw it.

None of this was hidden complexity. It was all knowable work. We just never made it explicit.

The problem isn't unique to that ticket. We work on implicit contracts everywhere.

I expect tests. You expect tests only for critical paths. Another developer expects tests only when explicitly requested. Nobody's wrong. We just never agreed.

Every ticket becomes a negotiation: "Is this really done, or done enough?"

The experiment: make the implicit explicit

So here's what I'm trying: a Definition of Done. A shared agreement about what "complete" actually means.

Not a theoretical document. Not a 50-item checklist. A living agreement that says:

Here's what's always included
Here's what depends on context
Here's what's never assumed

When a developer picks up a ticket, they know the complete scope without asking. When Product writes a ticket, they understand what they're buying. When I review code, I can point to specific missing items without it feeling arbitrary.

Making it stick

The DoD doesn't stand alone. It references systems we already use but never documented properly.

Our error system exists—I built it, it's in the code, it works. But it's scattered across READMEs, tribal knowledge, and code examples. The DoD will say "error handling: follows Error System," and that system will be properly documented with why it exists, how it works, and what to check.

Same for internationalization patterns, monorepo structure, naming conventions—systems that exist implicitly but need explicit documentation.

Where does this live? Confluence. Yes, Confluence. I know. Nobody's excited about it. But it's what we have, and perfect is the enemy of done—ironic, given the topic.

What happens Monday

Monday morning, I'm running a workshop with the frontend team.

We're not defining "my" DoD. We're defining ours. Co-created, not imposed. Because if they don't own it, they won't use it.

The agenda:

List everything that should always be done on tickets
Classify each item: always included, sometimes included, or never assumed
Estimate the real impact on ticket time
Decide where to document it
Agree on how to apply it

Then I spend this week consolidating what we decided. Documenting the DoD, migrating our scattered systems to one place, creating the structure we agreed on.

Next week, we test it on real tickets with real measurements.

What happens when estimates meet reality

I expect estimations to roughly double compared to our current "feature only" estimates.

But—and this is critical—the total time from ticket start to actual completion should stay the same or improve. Because we're making visible what we were already doing: the rework, the forgotten requirements, the debt accumulated silently.

Before: estimate 2 days, deliver in 5 days (with hidden rework). Product sees 2, gets frustrated when it takes 5.

After: estimate 5 days, deliver in 5 days. Product sees 5, makes informed decisions.

The second scenario is honest. And honesty creates space for actual optimization.

What could go wrong

Product might refuse the higher estimates. "We can't afford that."

The team might find the DoD bureaucratic. "More overhead."

The documentation might not get used. "Nobody reads Confluence anyway."

I might be solving the wrong problem entirely.

These are real risks. I don't have guarantees.

What I do have: a team that's already asking for this, clear hypotheses to test, and a plan to measure actual impact over two sprints. If it doesn't work, we'll know why. If it does, we'll have data to expand it.

Why I'm doing this anyway

Because the current state isn't sustainable.

Estimations are fiction. Overtime is normalized. Technical debt accumulates silently. New developers take months to understand implicit rules.

Something has to change.

A Definition of Done won't solve everything. But it might create a shared language about what work actually involves.

And when people share a language, fewer things need real-time clarification. Documentation gets referenced instead of people getting interrupted. Decisions get recorded instead of lost.

Not because we engineered an async-first culture. Just because we removed enough friction that clarity became the default.

Why I'm writing this now

So why write about this before I know if it works?

Partly because writing forces me to think clearly. If I can't explain the hypothesis without handwaving, I probably don't understand it.

Partly because public documentation creates accountability. Harder to quietly abandon an experiment when you've told the internet about it.

And partly because I'm tired of reading polished case studies where everything worked perfectly and everyone clapped. The sanitized success story teaches nothing. The messy reality—the resistance, the pivots, the "oh fuck I was completely wrong about that"—that's where the actual learning lives.

In two sprints, I'll know if this DoD experiment holds or crashes. Either way, I'll write about what actually happened. Not the LinkedIn version. The real one.

If you're dealing with similar chaos—estimations that are fiction, teams speaking different languages, the eternal question of "is this really done?"—drop a comment with your biggest scope creep disaster. Especially if your "solution" failed spectacularly.

The failures are usually more instructive anyway.

This is the beginning of the experiment. Let's see if I'm solving the right problem.

Update: Part 2

Views and experiments described here are my own and don't represent my employer.