tig.log - Geeky Leadership Rants by Tig Kindel

If you feel behind on AI, you probably are. The tools are improving faster than most teams are changing how they work. I see this daily in my coaching of individuals and teams in industries spanning medtech, space, consumer electronics, and even AI.

The good news is that catching up doesn’t require a grand strategy, a transformation program, or perfect clarity. It requires a different posture; and a willingness to act before you feel ready.

What follows is the advice I’ve been giving leaders and senior engineers repeatedly, in real conversations, about what actually works. This advice is not just me regurgitating what I’ve read; I’ve been spending almost all of my free time (neglecting car projects) for the past 9+ months actually using the AIs “in anger” in getting Terminal.Gui to Beta. Terminal.Gui is a beast of complexity, and while it’s mostly for fun, it has serious engineering, legacy, and existing customers behind it.

---

1. Lead With Curiosity → Doing (Not Reading → Doing)

The teams that make progress don’t start with confidence; they start with curiosity.

Specifically: curiosity about a real problem they already own.

What I see stalling teams is not ignorance, but the desire to be right before they act. They want a complete mental model of AI, a clear strategy, and confidence they’re “doing it correctly.” That mindset guarantees delay.

The better pattern is:

• Be curious about a concrete problem in front of you.
• Try AI on that problem immediately.
• Treat whatever happens as information, not success or failure.

Curiosity creates permission to experiment without certainty. Action creates the understanding you thought you needed first.

Reading and watching others can support curiosity; it cannot substitute for it. Curiosity that never turns into action is just procrastination with better branding.

---

2. Prototype Aggressively; Be Careful Later

Most organizations default to caution, evaluate thoroughly, compare tools, run pilots, socialize decisions. That instinct used to be reasonable. Right now, it’s counterproductive and, frankly, stupid in this age of rapid acceleration of AI capabilities.

The AIs are evolving weekly. Three weeks ago, Copilot’s CLI sucked. Now it’s surpassing Claude Code in some ways. And Claude Code has added capabilities just this week that make Copilot look dumb. Any evaluation process measured in months is obsolete before it finishes.

The guidance I keep repeating is simple:

• Prototype fast.
• Expect throwaway results.
• Optimize for learning speed, not correctness.

There is almost no downside to trying something quickly on a real problem, other than spending some time. The upside is insight you cannot get any other way.

You can be careful later after you’ve learned something worth being careful about.

---

3. Use AI on Real Work, Not Toy Problems

You don’t learn much about AI by playing with trivial examples. You learn by pointing it at messy, production-adjacent work and seeing where it breaks, surprises you, or helps more than expected.

That means:

• Real codebases.
• Real constraints.
• Real edge cases.

Even when the output isn’t production-ready, and often it won’t be, the speed at which you can explore ideas, validate approaches, or prototype alternatives changes how you think about the work.

Toy problems produce toy conclusions.

---

4. The Skill Has Shifted: From Prompting to Orchestrating

A year ago, the differentiating skill was “prompt engineering.” That mattered. It still does—but it’s no longer the frontier.

The emerging skill is orchestration: breaking a large problem into parts, delegating those parts to multiple AI agents, coordinating dependencies, and intervening when things go sideways.

I describe it as herding cats. Remember Tamagotchi? Orchestrating AI agents is a bit like trying to keep a bunch of Tamagotchi’s happy and healthy.

Two things are consistently true:

• This is a very different skill than traditional software engineering.
• You cannot do it well unless you already understand the technology deeply.

Actionable move:

• Identify someone on your team who’s curious and motivated.
• Make it an explicit goal for them to become excellent at managing AI agents—ideally on work you actually own, not side demos.

---

5. Principle‑Driven Prompting: Use Amazon PE Standards Explicitly

One of the highest‑leverage techniques I’ve seen is principle‑driven prompting.

Instead of asking AI “what should I do,” define who it should be and what standards it must uphold.

For example: prompting the AI to act as an Amazon Principal Engineer, explicitly grounding it in principles like pragmatic judgment, long‑term maintainability, empathy for operators, and raising the engineering bar.

The difference is stark:

• With PE principles: you get targeted, realistic refactoring guidance.
• Without them: you often get elegant but impractical greenfield rewrites.

This reveals something important: AI amplifies the values and judgment you give it. It does not supply them for free.

Here’s a prompt you might use:

“You are a Principlal Engineer who raises the bar for the Amazon Principal Engineering Community Tenets. Your role is to be a design reviewer for new engineering plans for my team. As you review and guide my engineers on their plans, you will continue to raise the bar for these tenets.”

I tweeted about this here:

Telling your coding AIs to act like an Amazon Principal Engineer who raises the bar for all the Amazon PE Tenets works wonderfully. Especially when asking for a review of a design.

This was Grok 4.20 reviewing two proposals. One by codex and one by Opus 4.3. Interesting how… pic.twitter.com/5ywUiPuHJ1

— Tig (@tigkindel) February 19, 2026

---

6. Set Goals That Force Usage, Not Interest

“Use AI more” is not a goal; it’s a wish.

The goals that actually change behavior are usage‑forcing. Examples I’ve been recommending:

• Use AI so much that leadership asks why token costs are spiking.
• Designate a go‑to person for deciding which model to use when.
• Increase, month over month, the number of issues where AI does the first pass.
• Apply AI to processes—not just code.

If your goals don’t force different behavior, they won’t produce different results.

---

7. Apply AI to Processes Before Code

Writing code faster is obvious. Improving the system around the code is often higher leverage and lower risk.

Good starting points:

• Log analysis.
• Bug triage.
• Updating stale documentation and code comments.
• Reviewing designs and requirements for clarity and modularity. See the Amazon PE prompt above.

These uses build trust, save time immediately, and help teams develop intuition about where AI helps and where it doesn’t.

---

8. Intentionality Beats Permission

The teams making real progress aren’t waiting for an official AI strategy. They’re acting with intent.

That means:

• Making exploration explicit, not “when you have time.”
• Assigning ownership.
• Setting concrete goals.
• Sharing learnings early, even when results are imperfect.

Waiting for permission is just another way to fall further behind.

---

The Bottom Line

If you’re behind, acknowledge it and move. You don’t catch up by being careful, exhaustive, or perfectly informed.

You catch up by being curious, acting quickly on real work, and learning faster than your comfort level would prefer.

AI doesn’t reward hesitation. It rewards momentum.

I’m happy to chat about this with anyone curious to learn more. My office hours are free and open.

The post You Are Behind in Using AI. Here’s How to Catch Up first appeared on tig.log.

For the past few months we’ve been architecting, refactoring, and refining. 146 commits. Dozens of PRs. One PR touched 493 files.

The long-awaited Beta isn’t just about revolutionary features. It’s about getting the architecture right and ensuring the API is stable for the future.

Terminal.Gui v2 is the ultimate framework for building cross-platform Terminal UI (TUI) apps with code that belongs in 2026, not 1999.

Here’s the stuff I’m the most proud of. To learn more and get started head to https://gui-cs.github.io/Terminal.Gui.

Killing the Static Singleton

Terminal.Gui v1 was built on a static singleton. Application.Init(), Application.Run(), global state everywhere. 2007-era architecture that survived into the 2020s through inertia.

You can’t test static singletons properly. Can’t mock them. Can’t run multiple instances. Modern C# developers expect better.

So we fixed it. Backward compatibility matters, so Tom built an instance-based IApplication interface and made the static API a thin (obsolete) wrapper.

How it was:

// Global. Singleton. The 2000s called, they want their pattern back.
Application.Init();
Window top = new Window();
top.Add(myView);
Application.Run(top);
Application.Shutdown();

How it is now:

// Proper resource management. Testable. Feels right.
using (IApplication app = Application.Create().Init())
{
    Window top = new();
    top.Add(myView);
    app.Run(top);
}

The difference matters for tests, dependency injection, and running multiple app instances (useful for testing different drivers). The old way made all of that painful or impossible.

The new way: views get their IApplication through context. Tests create mock applications without global state pollution. Disposal actually cleans up.

Type-safe dialog results:

using (IApplication app = Application.Create().Init())
{
    app.Run<ColorPickerDialog>();
    Color? selectedColor = app.GetResult<Color>();
}

No casting. No object?. Generics doing their job.

On Naming Things

Renamed Application.TopLevels to Application.SessionStack. “TopLevels” made sense in 2007, confused everyone in 2025. “SessionStack” describes what it is: a stack of session tokens.

// Clear stack-based session management
SessionToken? main = app.Begin(mainWindow);    // Push
SessionToken? dlg = app.Begin(dialog);         // Push (dialog becomes modal)
app.End(dlg);                                   // Pop (restore main)
app.End(main);                                  // Pop (empty, app stops)

---

Prompt<TView, TResult>

Creating custom dialog classes for every input type is tedious. Need a color? Create ColorPickerDialog. Need a date? Create DatePickerDialog. Each with its own result property, cancel handling, buttons.

Now any view can become a type-safe dialog.

Before:

ColorPickerDialog dialog = new();
Application.Run(dialog);
if (dialog.Canceled) return null;
Color? color = dialog.SelectedColor;

After:

Color? color = mainWindow.Prompt<ColorPicker, Color?>(
    resultExtractor: cp => cp.SelectedColor,
    beginInitHandler: prompt => prompt.Title = "Pick Color"
);

One line. Type-safe. Returns null on cancel. Compiler checks result types at build time.

IValue<T>

For views that hold a value, there’s IValue<T>:

public class ColorPicker : View, IValue<Color?>
{
    public Color? Value { get; set; }
    // Events follow the Cancellable Work Pattern
}

Now Prompt knows how to extract the result automatically:

Color? result = mainWindow.Prompt<ColorPicker, Color?>();

No extractor needed. The system recognizes IValue<T> and extracts automatically.

---

The 493-File Mouse Refactoring

PR #4472. Four hundred ninety-three files changed. Complete rewrite of the mouse system, ANSI driver, and input injection.

Input injection means programmatic mouse events—clicks, double-clicks, drags—injected directly into the application pipeline. With virtual time control. Millisecond precision. No manual testing, no UI automation tools, no hacks.

Here’s a test for double-click detection. An actual, working test:

[Fact]
public void Button_DoubleClick_RaisesEvent()
{
    VirtualTimeProvider time = new();
    using IApplication app = Application.Create(time);
    app.Init(DriverRegistry.Names.ANSI);

    Button button = new() { Text = "Double-Click Me" };
    var doubleClicked = false;
    button.Accepting += (s, e) => {
        if (e.Context?.Binding is MouseBinding {
            Mouse.Flags: var f
        } && f.HasFlag(MouseFlags.LeftButtonDoubleClicked))
        {
            doubleClicked = true;
        }
    };

    // Inject first click
    app.InjectMouse(new() {
        Flags = MouseFlags.LeftButtonPressed,
        ScreenPosition = new Point(0, 0)
    });
    time.Advance(TimeSpan.FromMilliseconds(50));
    app.InjectMouse(new() {
        Flags = MouseFlags.LeftButtonReleased
    });

    // Inject second click within threshold
    time.Advance(TimeSpan.FromMilliseconds(200));
    app.InjectMouse(new() {
        Flags = MouseFlags.LeftButtonPressed
    });
    app.InjectMouse(new() {
        Flags = MouseFlags.LeftButtonReleased
    });

    Assert.True(doubleClicked);
}

The test injects mouse events at specific timestamps, advances virtual time, asserts on double-click flags. Runs in milliseconds, deterministically.

VirtualTimeProvider controls time in tests. Two clicks 200ms apart? Advance time 200ms. No waiting. Tests run instantly whether on a fast desktop or slow CI runner.

---

The ANSI Driver

I have a thing for terminals. Spent time customizing shells, studying ANSI escape sequences, caring about CSI vs SS3 sequences. My original post mentioned fonts—it extends to the whole terminal stack.

When we rebuilt the mouse system, I wanted a proper ANSI driver. Pure escape sequences. Cross-platform. VT100-era standards that still work in 2026.

What Makes It Special

The ANSI driver doesn’t use platform-specific APIs for anything but reading & writing terminal IO. No Win32 Console calls. No Unix syscalls. Just ANSI escape sequences—the same ones terminals have understood since the 1970s.

Input parsing:

• Mouse SGR Format (CSI < Pb ; Px ; Py M/m) – The modern mouse reporting format that actually works
• Keyboard CSI sequences (CSI final[;modifiers]) – Arrow keys, function keys, the whole gamut
• SS3 sequences (ESC O final) – Because some terminals still use them for function keys
• Escape-as-Alt – ESC followed by another key = Alt modifier (the Unix way)

Output:

• DECSCUSR (CSI Ps SP q) – Those seven cursor styles I mentioned earlier
• SGR attributes (CSI Ps m) – Colors, bold, underline, all the formatting
• Cursor positioning (CSI Ps ; Ps H) – Direct addressing, no abstractions
• Device Status Reports (CSI 6 n, DSR) – Query the terminal for screen size changes

Why This Matters

Every terminal speaks ANSI. Windows Terminal, iTerm2, gnome-terminal, Alacritty, WezTerm—all ANSI.

One driver. Every platform. Consistent behavior. No “works on Linux, weird on macOS” bugs.

The Parser Pipeline (For the Terminal Nerds)

The ANSI parser is actually three parsers working together:

Console Input → Raw Bytes → Parser Triage
                              ├─→ AnsiKeyboardParser → Key events
                              ├─→ AnsiMouseParser → Mouse events
                              └─→ AnsiResponseParser → DSR responses

Each parser handles its own sequence format. Keyboard parser: CSI and SS3. Mouse parser: SGR. Response parser: terminal replies.

When you inject a mouse event in tests, it goes through AnsiMouseEncoder (converts to raw SGR format like ESC [ < 0 ; 10 ; 5 M), then AnsiMouseParser (back to mouse event structure). Round-trip encoding.

Another hat tip to contributor Tom; his work on this was brilliant.

The Cost

Edge cases: terminals that send SS3 for F1 but CSI for F2. Mouse coordinates 1-based in ANSI but 0-based internally. Escape sequences meaning different things depending on modifiers.

Took months. Now we have a driver that works everywhere. When someone reports “doesn’t work in my terminal,” switching to ANSI driver usually fixes it.

Testing the Driver

This is where input injection pays off. Want to test how Terminal.Gui handles a Shift+F5 keypress? Inject the ANSI sequence:

app.InjectKey(AnsiKeyboardEncoder.Encode(
    Key.F5.WithShift
));

Want to test mouse wheel scrolling?

app.InjectMouse(AnsiMouseEncoder.Encode(new Mouse {
    Flags = MouseFlags.WheeledDown,
    ScreenPosition = new Point(10, 5)
}));

The encoders produce actual ANSI sequences—the same bytes a real terminal would send. The parsers consume them. We’re testing the real path, not a mock.

---

Cursors

Terminal emulators support seven cursor styles via ANSI DECSCUSR sequences. Blinking block, steady underline, blinking bar.

Terminal.Gui’s cursor handling was scattered—state everywhere, no explicit model. Fixed:

An Immutable Cursor Record

public record Cursor
{
    public Point? Position { get; init; }  // Null = hidden
    public CursorStyle Style { get; init; } = CursorStyle.Hidden;
    public bool IsVisible => Position.HasValue && Style != CursorStyle.Hidden;
}

Seven Cursor Styles (The ANSI Standard)

public enum CursorStyle
{
    BlinkingBlock = 1,        // █ Traditional terminal cursor
    SteadyBlock = 2,          // █ Steady (no blink)
    BlinkingUnderline = 3,    // _ Classic
    SteadyUnderline = 4,      // _ Steady
    BlinkingBar = 5,          // | Text editor style
    SteadyBar = 6,            // | Steady editor cursor
    Hidden = -1               // No cursor
}

Maps directly to ANSI DECSCUSR (CSI Ps SP q). Windows driver translates to Win32 API automatically. Cross-platform cursor styles.

Using it in a view:

protected override void OnDrawContent(Rectangle viewport)
{
    int cursorCol = _cursorPosition - _scrollOffset;

    if (cursorCol >= 0 && cursorCol < Viewport.Width && HasFocus)
    {
        Point screenPos = ViewportToScreen(new Point(cursorCol, 0));
        Cursor = new Cursor
        {
            Position = screenPos,
            Style = CursorStyle.BlinkingBar
        };
    }
    else
    {
        Cursor = new Cursor { Position = null };  // Hidden
    }
}

Immutable record, value-type semantics, thread-safe. Caches intelligently—99% of PositionCursor() calls were redundant.

---

Simplified Command System

The command system had CommandContext<TBinding>. Generic, type-constrained. You had to know the binding type at compile time. Extending meant fighting the type system. Pattern matching was awkward.

Simplified:

Before:

public record struct CommandContext<TBinding> : ICommandContext
{
    public TBinding? Binding { get; set; }
}

After:

public record struct CommandContext : ICommandContext
{
    public IInputBinding? Binding { get; set; }
}

No generics. Just a common IInputBinding interface that KeyBinding, MouseBinding, and InputBinding all implement. Now you can pattern match:

var source = ctx.Binding switch
{
    KeyBinding kb => $"Keyboard: {kb.Key}",
    MouseBinding mb => $"Mouse: {mb.MouseEvent?.Flags}",
    InputBinding => "Programmatic",
    _ => "Unknown"
};

Pattern matching works when you let it. Best design gets out of the language’s way.

---

Documentation

Every API now has awesome (until you find bugs and report them) API reference documentation that includes sample code and cross-references. I take pride in this, so if you find problems, please submit issues!

Start here: https://gui-cs.github.io/Terminal.Gui/api/Terminal.Gui.App.html

The Deep Dives go deep and broad. See https://gui-cs.github.io/Terminal.Gui/docs/index.html

---

Other Work

Upgraded to .NET 10 and C# 14. Modern language features, collection expressions.

Modernized TextView to use the new Viewport/ScrollBar system. Touches more code than expected, makes everything slightly better.

Fixed macOS test runners that randomly hung. Fixed keyboard test timing issues. Stabilized stress tests.

---

What This Actually Means

If you’re building apps with Terminal.Gui: You get type-safe dialogs, testable mouse interactions, proper resource management, and an architecture that feels like 2026, not 2006.

If you’re contributing to Terminal.Gui: The codebase is now testable in ways it never was. Input injection works. The architecture has proper separation. The docs explain the “why” not just the “what.”

If you have a Terminal.Gui v1 app: You will need to port. Tons has changed. But we’ve provided a migration guide that will help. In the end, you’ll find the updated API is far simpler, easier to understand, and most of your porting work will be removing code that’s no longer needed. Pro-tip: Just point your favorite AI coding agent at https://gui-cs.github.io/Terminal.Gui/docs/migratingfromv1.html and let it do it for you.

---

Beta, Not 2.0

This is a Beta. The architecture is solid and we are now holding a very high bar for further API changes.

Use it. Test it. Tell me what’s broken. GitHub issues are open.

https://github.com/gui-cs/Terminal.Gui/issues

---

Thank You

To @BDisp, who tests thoroughly and catches bugs I miss. He’s always eager to dive into the trickiest bugs and work until they are resolved.

To @tznind, who’s architectural insights made IApplication and the new driver model possible. Plus Terminal.Gui.Designer is da’bomb.

To @dodexahedron, who regularly challenges us to do things right.

To all the dozens more who’ve submitted Issues and PRs!

To the AI agents (Claude, Copilot); you know your role.

And, of course, to Miguel de Icaza who started this 17 years ago.

1. Still maintaining a terminal UI framework. Still ridiculous. Still wonderful.

-Tig

The post Terminal.Gui: Still Absurd, Now Beta! first appeared on tig.log.

I’ve heard “program” used to mean everything from a team to a project plan to a portfolio to lines of code. At some point, someone has to stop and say: you keep using that word—I don’t think it means what you think it means.

A shared Taxonomy and Lexicon essential for focus and execution. Without one, organizations descend into semantic chaos. Few places create more confusion than the “P” words: Pfunction, Program, Project, Product, and their associated management functions.

Every company eventually trips over these. People use them interchangeably, often without realizing it. “Program” means one thing to engineering, another to marketing, and something else entirely to finance. The result is fuzzy ownership, blurred priorities, and circular conversations.

As I described in How We Scaled Alexa: One Problem, One Leader, scaling complex work requires single-threaded clarity. You can’t have one leader accountable for “the product” if half the org defines “product” as an app and the other half thinks it’s a platform. Leaders must explicitly define the boundaries: who owns what, what success means, and how each piece fits into the larger system.

This post defines the “P” words as I use them and explains how aligning on them creates clarity, focus, and scale.

Pfunction

A Pfunction (that’s a joke to make the “P” theme work) is what a person contributes to the company. Every employee provides one or more functions.

A CEO’s pfunctions might include executive leadership, fundraising, and investor relations. A software engineer’s pfunctions might include design, implementation, and testing. Pfunctions are not roles or titles; they describe what the role delivers.

Ok, I’ll stop using pfunction now and just use function. You get the point.

When an organization is small, people wear multiple functional hats. As it scales, clarity about each function’s purpose becomes the scaffolding for specialization. Confusion about functions is often the first crack in the foundation of focus.

Program

A Program is a long-term (measured in years) human effort to deliver customer value in a well-defined scenario area.

Programs are the durable units of investment; they are what the company will care about indefinitely. A great program has a clear vision, a defined customer set, and measurable outcomes that endure over time.

Programs are usually led by a Single-Threaded Leader (STL) who is fully accountable for the program’s success. The STL owns both strategy and execution, bringing together all pfunctions (engineering, design, marketing, operations) behind one clear goal. STLs of Programs are strong in all four of the CBTO perspectives.

Examples from my time at Control4: Smart home customers will always care about lighting, so we had a Lighting Program that built all of our connected lighting products. Jeff, a kick-ass, traditionally trained Product Manager, was the STL for Lighting (a vertical). People living in smart homes will always care about how scenarios that combine smart home verticals (Lighting, Whole Home Audio, Security, etc…) come together in a unified way, so we also had a horizontal Program for Home UI. Joel’s team built the Control4 mobile app and the experience on touch screens. He was a very technical engineering manager type. 1

Programs produce Products over time. Each Product emerges through one or more Projects. Or, as I like to say, “Programs poop out Products, using Projects.”

Project

If Programs define the long-term why, Projects deliver the short-term what.

A Project is a short-term human effort to fix a problem or deliver something specific by a certain date. Projects are measured in days, weeks, months, or sometimes years. When a project is complete, the people involved move on to something else.

Projects are how organizations make progress in the short term. They are temporal, discrete, and measurable. A project without a defined end state isn’t a project; it’s a program pretending to be one.

Projects work best when their goals ladder up cleanly to a Program’s long-term outcomes.

A Project can also have an STL. The best ones do. The STL of a Project has full ownership of getting the thing done on time, on spec, and aligned with the broader program. Generally, STLs of Projects are super strong on Technical execution and appropriately strong in the other CBTO perspectives.

Product

A Product is a cohesive bundle of functionality that customers experience as a whole.

Products are what customers see, touch, and pay attention to (and often pay for). They can be physical, digital, or experiential. They can be literal boxed products or software as a service. Products deliver the promise of a Program.

Programs evolve through a series of Projects that create and improve Products. Over time, a strong Program poops out new Products: each one a milestone in the Program’s lifecycle of customer value.

When we scaled Alexa, teams had wildly different ideas of what “the product” was. Some thought it was the Echo device, others thought it was the Alexa voice service, and others still said it was the developer platform. Clarity only came when we defined “product” in customer-centric terms: the thing customers experience and value.

Products are the bridge between customer value and company execution. Misdefining them breaks that bridge.

For early-stage companies the Product and Program are usually one and the same. If the startup is successful with the first product, then the Program becomes distinct. The danger comes when growth blurs this line, turning a scrappy Product into a sprawling Program without reassigning ownership.

---

The Heart of the Confusion: Program vs. Product Management

Microsoft and Intuit2 in the 1980s and 1990s, invented a discipline called Program Management.3 A Program Manager’s job was to be the single threaded leader for a product area: define what should be built, why, and ensure it got built the right way.

“A Program Manager is the advocate for end-users and customers” who bridges engineering and usability while driving execution.” — Steven Sinofsky

That model worked brilliantly. It fused customer obsession, technical depth, and operational rigor into one role. It forced alignment between strategy and execution.

But when Microsoft alumni scattered across the industry, the terminology mutated. Other companies borrowed the idea but changed the labels. The same role that Microsoft called Program Management eventually became known everywhere else as Product Management.4

The result: decades of linguistic confusion. Today, Product Managers rarely “manage products.” Program Managers rarely “manage programs.” And Project Managers often do a bit of both.

There should be a single function that defines what to build and ensures it gets built the right way. That function bridges strategy and execution. I wish the world still called that Program Management because that’s what it really is. But since most of the industry uses Product Management for this function, I use that term to stay consistent.

---

Function Taxonomy Project Management

Project Management is the function responsible for ensuring a specific body of work is completed according to plan. Unlike Program Management and Product Management, there’s little confusion around the terminology: Project Managers manage Projects.

The skills required for Project Management are the fundamental blocking and tackling required to drive the mechanics of execution: schedules, dependencies, risks, and reporting. Somone skilled at Project Management is able to keep lists of details organized, up-to-date, and accurate. They master tools like Google Sheets, Jira, and Microsoft Project. They are good at herding cats.

Project Management is tactical by definition (recall from above, a Project is an effort literally bounded by time) and essential. The best project managers anticipate failure modes, surface tradeoffs early, and enforce accountability with discipline and humor.

Program Management (PgM)

Program Management is a supporting function that provides systems, tools, and mechanisms for consistency, coordination, and delivery at scale. Dedicated Program Management resources are not needed when the scale is small (startups, early-stage Programs). Dedicated PgMs are valuable when an organization has scaled to dozens of Programs with interdependencies and a need for cross-Program consistency.

At Amazon, there’s a function called Technical Program Management (TPM). These folks are very technical, really good at influencing others, and excellent at holding teams accountable to dates. They provide the most value when they manage complex arcs of dependencies across organizations.

At the scale most startups operate at, and when something new is hatched within a larger organization, dedicated Program Manager resources are a bad idea and a sign that the Program’s STL is not the right person for the role. Put another way, adding a PgM to an early-stage effort both robs the STL of ownership and just adds another chef to the kitchen.

Product Management (PM)

Product Management owns both the “what” and the “how.” The Product Manager leads the PROGRAM. He or she is the STL for the area of functionality that customers will care about over the long haul. I use PM as the acronym for Product Management.

World-class Product Managers (STLs of Programs) have little ego, are skilled at starting with the customer and working backwards, and consistently raise the bar for Ownership..

The best Product Managers are really good at Project Management (being the “a-hole with a clipboard”). If they’re not, they’re really good at hiring or delegating to someone who is. Likewise, they’re really good at Program Management (driving consistency and coordination).

One does not have to hold the title of Product Management to provide the function of Product Management. I’ve delivered amazing, magical, customer value via a Software Development Manager who acted as his own PM. A recent thread on X, by Nikia Bier, is a great example:

---

How to Reconcile Internal and Industry Terms

I obviously have strong opinions, strongly held on these terms. Maybe you agree with my definitions. Regardless, the real point I’m trying to make is:

Most people are confused and unclear on these terms and it’s very common within teams for there to be disconnects and misalignment. As a leader it’s your job to recognize this and be intentional about fixing it. Stop the semantic sword fights; define your ‘P’ words, arm your STLs, and watch execution accelerate.

Here’s how:

1. Define Internally First
   Decide what each “P” term means inside your company. Write it down. Review it regularly. Teach it to every new hire.
2. Map to Industry Terms
   Recognize where your definitions differ from common usage. Create a simple mapping document so you can explain your language to external partners and candidates.
3. Be Consistent Across Mechanisms
   Use your taxonomy consistently in planning, budgeting, reviews, and reporting. If your systems use “project” differently, adapt them or clearly translate.
4. Keep the STL Principle Front and Center
   Every Program and every Project should have one clearly defined leader who is responsible for the outcome. One problem; one leader.

When these definitions are explicit and mapped to reality, your organization gains coherence. People stop fighting over things that don’t matter and get to the crux of debate faster.

---

If your team struggles with blurred ownership or mixed terminology around programs, projects, and products, I’ve helped many leaders build taxonomies that scale. You can grab time with me during my office hours to talk.

1. In my post on Anti-Silo Mechanisms, I described a similar setup we used for Alexa Smart Home. ︎
2. The History and Evolution of Product Management (Part 3) | by Rafayel Mkrtchyan | Agile Insider | Medium ︎
3. See Steven Sinofsky’s 2005 Microsoft TechTalk on Program Management, summarized by EECS 481, University of Michigan. ︎
4. Learning by Shipping (Medium, 2018): https://medium.learningbyshipping.com/functional-versus-unit-organizations-6b82bfbaa57 ︎

The post Program: You Keep Using that Word, I Don’t Think You Know What it Means first appeared on tig.log.

In my user’s manual post on Mechanisms, I argued that “good intentions never work; you need good mechanisms to make anything happen.” Mechanisms are complete processes—owned by a leader, built around a tool or ritual, broadly adopted, and continually inspected and improved—that make the right behavior the default. Rather than hoping people do the right thing, great leaders engineer processes that guarantee it.

This post shows those ideas in action. The tech giants—Amazon, Microsoft, Google, Meta, and Apple—owe much of their scaling success to well-designed mechanisms. They might not use that word, but their systems fit the definition exactly: end-to-end processes, deliberately invented to solve real problems, adopted company-wide, and refined over time.

At the end, I’ll introduce one practice most organizations miss: the User’s Manual—a simple but powerful way to keep mechanisms alive and healthy.

---

1. Make the Routine Routine: Google’s OKRs and Amazon’s Planning Cadence

Every successful company runs on a few recurring processes that, if left ad hoc, become chaos. Google tackled this early with its famous OKR (Objectives and Key Results) system. Each quarter, every team sets measurable goals, publishes them, and grades results. Everyone’s OKRs are visible to everyone else—from interns to the CEO.

This works because it’s not just goal-setting; it’s a complete process:

• Tool: shared documents and dashboards; a universal format.
• Ownership: each manager ensures OKRs exist and are scored; operations teams run the calendar.
• Adoption: it’s how Google runs, not an optional exercise.
• Inspection: executives read and comment; teams refine every cycle.

The result: alignment, agility, and focus without micromanagement. Google’s quarterly OKR cadence is the organizational equivalent of breathing.

Amazon’s version follows the same logic: an annual and three-year planning mechanism (OP1 and OP2), supported by Weekly Business Reviews. Each happens on a set cadence, in a fixed format, with data-driven inspection. Routine becomes rhythm, and rhythm becomes clarity. As I wrote in The 5Ps: Achieving Focus in Any Endeavor, structure and cadence are what make focus sustainable. Make the routine routine, or you’ll be stuck in constant firefighting.

---

2. Details Matter: Amazon’s Working Backwards and Apple’s DRI

Meetings often end with everyone thinking they agree—until reality proves otherwise. Mechanisms that crush assumption are worth their weight in gold.

Amazon’s “Working Backwards” process forces teams to write a mock press release and FAQ before building anything. The document describes the finished product as if it already exists, spelling out who the customer is, what problem it solves, and why it delights them. If the narrative isn’t compelling, the idea isn’t ready. Leaders silently read the memo, critique it, and send it back for revision until it’s airtight. That is inspection in action.

Apple solves a similar problem with the Directly Responsible Individual (DRI). Every deliverable and meeting item has exactly one owner. No ambiguity, no “I thought you were handling that.” It’s simple and brutally effective. I use the term Single Threaded Leader.

Both mechanisms prevent confusion by institutionalizing clarity. They force alignment early instead of discovering disagreement late—echoing the principle from The First Rule of Skills: define what “good” looks like before you start doing.

---

3. Audit Mechanisms: Amazon’s Andon Cord and Blameless Post-Mortems

Even with the best planning, things break. Audit mechanisms ensure problems surface fast and drive learning.

Amazon’s Andon Cord lets any customer service rep halt sales of a product if recurring issues appear. The system automatically flags defects, pauses listings, and triggers root-cause analysis. Leaders track pulls as a health metric: too few means issues are hidden; too many means systemic failure. That’s continuous auditing, not periodic review.

Google and Meta use blameless post-mortems for every outage. Engineers write a full report—what happened, why, and what will change. No blame; just learning. Facebook enforces code reviews and automated “push karma” scores that audit quality continuously. These mechanisms make reliability structural, not aspirational.

The lesson: don’t hope for heroics. Design systems that catch defects before customers do. As I outlined in The Secret to Delivering Outsized Results, excellence scales when your system—not your people—does the enforcing.

---

4. Behavior Change Mechanisms: Microsoft’s Hackathons and Google’s 20% Time

Culture shifts are hard to decree; you have to architect them. Microsoft’s OneWeek Hackathon and Google’s 20% Time are mechanisms that create space for new behaviors.

At Microsoft, tens of thousands of employees take a week each year to build anything they want, often with people outside their usual teams. Executives sponsor it, resources are allocated, and winning ideas are celebrated. The mechanism tells everyone: innovation is expected, not extracurricular.

Google’s 20% Time did the same for curiosity. By institutionalizing a day a week for side projects, Google birthed products like AdSense and Google News. Even as the practice evolved, the message stuck: explore, experiment, improve.

The Broken Windows Mechanism I implemented at Control4 dramatically changed the culture of how the company approached technical debt/product rot.

These mechanisms worked because they were codified and repeated. Culture didn’t shift by memo; it shifted by mechanism. That’s exactly how Tenets work—codify a few non-negotiables, then back them with mechanisms so they live in the daily work.

---

5. Anti-Silo Mechanisms: Facebook’s Bootcamp and Google’s TGIF

Silos form naturally; leaders must fight gravity with structure. Facebook’s Engineering Bootcamp ensures every new engineer spends weeks rotating across systems before joining a team. They build a network, learn shared tools, and internalize the culture. The result is an organization that scales without fragmentation.

Google’s TGIF all-hands did the same for transparency. For years, anyone could ask the founders any question live. The ritual connected offices, flattened hierarchy, and kept information flowing. It was a structural guardrail against the left hand not knowing what the right was doing.

I’ve built smaller versions of these in startups—weekly cross-team updates, internal newsletters, quick Friday syncs. The pattern is the same: design a communication mechanism that forces intersections to happen. As I described in Customer, Business, Technology, Organization (CBTO), healthy systems depend on deliberate cross-function alignment. Anti-silo mechanisms make that alignment automatic.

---

6. The User’s Manual: Every Mechanism Needs One

Here’s the piece most leaders miss. Every mechanism should have a User’s Manual—a short, living document written and maintained by the mechanism’s owner. It treats participants as customers and explains exactly how to use the mechanism.

Why? Because mechanisms degrade when people forget how they work. A clear manual keeps adoption high, training easy, and inspection simple.

The User’s Manual defines:

• Purpose: what outcome this mechanism guarantees.
• Owner: who maintains it (name, not team).
• Cadence: when it runs.
• Participants: who does what, with what inputs.
• Procedure: numbered steps in plain language.
• Outputs: what artifacts or reports are produced.
• Inspection: what gets reviewed, by whom, and how often.
• Health metrics: 1–3 signals that show if it’s working.
• Change log: what’s been improved and why.

Keep it on your internal wiki. One page if possible; two at most. Version it, link to live data, and update it as the mechanism evolves. If it’s too complex to fit, simplify the mechanism first.

The best manuals read like product docs: easy to follow, visual where helpful, and written for the user, not the author. Treat them as part of the mechanism’s design, not an afterthought.

---

How to Build Your Own Mechanisms

When I coach leaders on mechanism design, I use the 5Ps framework as a scaffold:

1. Purpose – What behavior or outcome you want.
2. Principles – The truths that guide how it should work.
3. Priorities – What must happen first.
4. People – The owner and the key participants.
5. Plan – The cadence, tools, and inspection loop.

Start small: one mechanism, one page, one owner. Document it. Run two cycles. Review what worked. Update the manual. Repeat. In a quarter, you’ll see clarity increase and chaos drop.

---

From Process to Culture

Mechanisms might sound mechanical, but they actually free humans to do their best work. When people know the playbook, they spend less time guessing and more time creating. Big Tech’s secret isn’t endless resources; it’s disciplined process design.

The right mechanism doesn’t just make something happen once—it makes it happen every time. That’s how you scale good intentions into consistent results.

If you want help designing your own, bring a real example to my office hours. We’ll turn your recurring headache into a clean, inspectable mechanism—with a user’s manual that keeps it humming long after the heroics end.

---

Because in the end, good intentions are cheap. Good mechanisms compound.

---

Linked references summary

• Mechanisms
• The 5Ps: Achieving Focus in Any Endeavor
• The First Rule of Skills
• The Secret to Delivering Outsized Results
• Tenets
• Customer, Business, Technology, Organization (CBTO)

The post Mechanisms In Action: How Tech Giants Scale “Good Intentions” first appeared on tig.log.

Every complex system, whether an organization, a product, or a culture, tends toward entropy. Left alone, it drifts from excellence to mediocrity. Most leaders respond by adding reviews, reports, and dashboards, trying to inspect their way to quality. That does not scale.

Fitness Functions help teams become excellent and stay excellent. Fitness functions are measurable signals that reveal whether things are getting better on their own.

The idea comes from evolutionary computing, where algorithms “evolve” by measuring how fit each candidate solution is against a goal. Amazon adapted the concept to assess whether a system, technical, operational, or organizational, is improving over time without direct supervision.

A fitness function is a measure of system health and learning capacity. It does not replace goals or OKRs; it complements them. OKRs tell you what to achieve. Fitness functions tell you whether your system is getting better at achieving anything at all.

You can define fitness functions across any dimension of your organization using the CBTO lens: Customer, Business, Technology, and Organization.

---

Customer: Are we delighting customers more over time?

• Amazon Retail Page Load Time → Revenue
  Amazon teams discovered that page load speed directly affected conversion. Tracking median page load time (weighted by revenue) became a fitness function for customer experience. If pages got faster and conversion improved, the system was fitter.
• Delta Airlines “Net Promoter Recovery”
  Delta measures how many detractors, or low NPS scorers, they successfully convert to promoters after a bad experience. The upward trend shows whether their service recovery system is improving.

Customer fitness functions measure how effectively customer delight compounds over time.

---

Business: Are we improving the long-term engine, not just quarterly results?

• Amazon Innovation Velocity
  Amazon tracks the percentage of revenue from products or services launched in the past three years. It is a proxy for how quickly the business model refreshes itself. A rising number signals a company that continually invents on behalf of customers; Think Big in measurable form.
• Google “Budget-to-Learning Ratio”
  Google has tracked how much R&D spending results in new validated learnings such as experiments run, patents filed, or new models deployed. A healthy ratio signals a business that is investing wisely in future value, not just executing the current plan.
• SpaceX Launch Reliability
  SpaceX measures anomaly closure rate and recurrence. When issues close faster and repeat less often, the business system of design, supply chain, and quality is learning faster than it breaks.

Business fitness functions measure whether your engines for innovation and investment are compounding, not stagnating.

---

Technology: Is our system getting stronger on its own?

At Amazon we used COEs (Correction of Error reports) to measure how fast systems learned from failure. Each COE documented what happened, why, and what correction was engineered to prevent recurrence. A key fitness function was latency: how long it took from error detection to permanent fix. When that latency trended down, the system was getting fitter.

Later, at Control4, my team built a similar process called EECs (Engineering of Error Corrections), pronounced “Eek!” (like Bill the Cat). It had the same purpose: capture each failure, identify the root cause, and design a fix that made recurrence unlikely. Faster EEC closure meant a more resilient product and organization.

Meta (Facebook) uses a comparable approach through its SEV review process. Every production incident is assigned a severity (SEV1 for major outages, SEV2 for partial impact, and so on) and triggers a structured review. Meta tracks SEV-to-fix latency, the time between detection, mitigation, and full resolution. When that latency shrinks while incident volume stays flat or declines, Meta knows its infrastructure is learning faster than it fails.

Other leading tech orgs show the same pattern:

• Google’s Site Reliability Engineering (SRE) teams monitor Mean Time to Detection (MTTD), Mitigation (MTTM), and Recovery (MTTR) to balance reliability with speed.
• Netflix deliberately injects failure through Chaos Monkey, using MTTR as its core fitness signal.

Different names, same logic. A healthy system detects, corrects, and recovers without heroics.

Technology fitness functions measure execution and operational excellence; the system’s immune response.

---

Organization: Are our people and culture getting stronger without heroics?

Most leaders rely on engagement surveys or turnover stats, but those are outcomes, not signals of organizational health. A fit organization learns, adapts, and sustains performance without managerial firefighting.

• Spotify Squad Health Check
  Spotify teams score themselves on autonomy, purpose, and learning. Leadership tracks trends, not snapshots. When those scores rise without intervention, the culture is scaling effectively.
• Microsoft Employee Thriving Index
  Microsoft measures the percentage of employees who say they are learning, energized, and empowered. When that number rises alongside productivity and retention, the organization is fitter. I used a similar metric called Employee Engagement to great effect at SnapOne.
• Regretted vs. Unregretted Attrition
  The ratio of regretted to unregretted departures is a direct cultural fitness measure. When high performers stay and low performers move on, leadership systems are working. A spike in regretted attrition means the Ghost of Mediocrity is creeping in.
• Persistent Vacancies
  Roles open more than 90 days are a sign that hiring, onboarding, or development pipelines are lagging behind business needs. As time-to-fill declines, it shows the system is learning how to attract and integrate talent faster.

When these signals move in the right direction, it means the organization’s leadership and culture are evolving faster than complexity is increasing.

Organizational fitness functions measure the rate of cultural learning and leadership maturity.

---

Leading by Fitness Function

Fitness functions are not vanity metrics or inspection rituals. They are how teams know their systems are improving their ability to produce results, consistently, and without constant intervention.

OKRs tell you what to achieve. Fitness functions tell you whether your organization is becoming more capable of achieving anything.

Define them across your CBTO stack: Customer, Business, Technology, and Organization. Review them regularly. When your fitness functions are trending in the right direction, excellence becomes self-reinforcing.

This is how great organizations deliver outsized results. They do not rely on inspection. They build systems that learn.

How do you know your system is getting fitter?

If you would like help designing fitness functions for your team or company, my office hours are open.

The post Leading by Fitness Functions first appeared on tig.log.

Back in March 2019, I posted a thread on X about a feedback tool that changed how I lead and coach: the SBI model. With my 30+ years in all sorts of orgs, I’ve seen how the right kind of feedback can transform teams, while the wrong kind erodes trust and performance. SBI, which stands for Situation–Behavior–Impact, is a structured way to give feedback that’s clear, non-defensive, and actionable.

In this post, I’ll expand on that thread, share why SBI works so well, and show how it fits into modern performance management. I believe the Center for Creative Leadership (CCL) is where the SBI model originated.

What Is the SBI Feedback Model?

SBI keeps feedback factual and focused. It breaks into three parts: the specific situation, the observed behavior, and the resulting impact. The structure is simple, but using it consistently takes discipline.

Here’s how it works:

1. Situation: Set the context. When and where the behavior happened. Be specific enough to jog memory without debate. “During our team meeting on Tuesday at 10 a.m.” is better than “last week.”
2. Behavior: Describe exactly what you saw or heard. Avoid assumptions about intent and focus only on actions. For example: “You raised your voice and interrupted the speaker,” not “You were rude.”
3. Impact: Explain the effect. How it affected you, others, or the work. “It made me frustrated because it disrupted the discussion and the team checked out after that.”

CCL suggests adding a fourth element: Intent. After describing the impact, ask, “What were you hoping to accomplish?” This simple question turns feedback from a statement into a conversation.

Why SBI Reduces Defensiveness

In my 2019 thread, I wrote: “Most people understand, pretty deeply, that they are not perfect and they have behaviors they can change.” That is why SBI works. It isolates behavior from character. When feedback targets what someone did, not who they are, it is much harder for them to feel attacked.

By anchoring feedback on facts and impact, SBI helps both parties stay calm and curious. It lowers emotional temperature and invites reflection instead of resistance.

CCL’s research supports this: people are more open to feedback delivered in SBI form, and managers are more likely to give it regularly because it is quick, fair, and repeatable.

SBI is not just for criticism. It works just as well for reinforcing positive behaviors and recognizing when someone handled a client meeting well or led a productive sprint review. Because it stays non-defensive and specific, it builds confidence as easily as it corrects mistakes.

From Documentation to Development

I have used SBI to handle everything from tough performance conversations to promotion write-ups. Writing SBI feedback over time creates a clear, factual record of behavior, useful for performance reviews or coaching logs.

Positive SBI examples, meanwhile, become the backbone of promotion cases. They replace “gut feel” with evidence: concrete examples of leadership and impact.

This fits with my view that annual reviews should give way to regular 1:1s and quarterly check-ins. Frequent SBI conversations make feedback continuous and expected. They turn evaluation into development.

SBI Is Contagious

Once you start using SBI, others adopt it. I have seen it ripple through teams. When people experience feedback that is specific and non-judgmental, they mirror it. Before long, it becomes part of the culture.

Adding Intent amplifies this effect. It turns feedback into a habit of listening and understanding. You are not just telling someone what they did; you are learning why they did it.

Give SBI a Try

As I said in my original thread: “Go ahead and give SBI a try. A little practice makes perfect.”

Try it this week: Find a co-worker (your boss, a report of yours, or a peer) who’s interested in learning SBI with you. Have them read this blog post, or the CCI webpage.

Then, each of you give it a try on each other: Pick a recent moment, describe the situation, note the behavior, and explain the impact. Try it for both positive and critical feedback.

If you want to get better at feedback, SBI is one of the most practical tools you can use. I teach SBI and other feedback mechanisms in my leadership coaching sessions. You can explore these ideas or book free office hours at kindel.com/officehours.

The post The Secret to Giving Feedback Without Triggering Defensiveness first appeared on tig.log.

Terminal.Gui is a .NET UI framework for cross-platform terminal apps. It started life as gui.cs, created by Miguel de Icaza. Miguel, being Miguel, casually dropped a complete cross-platform console UI stack into the world, made it just great enough to be dangerous, and moved on.

I was submitting fixes to, and poking around in gui.cs, when Miguel became enamored with Swift. I asked him if I could take it over. I wanted the experience of maintaining a real OSS project at scale. My previous open-source efforts (like WinPrint) were solo affairs where I was not only the only developer, but pretty much the only user. Nobody really cared.

Terminal.Gui, on the other hand, had traction. Devs were using it, and I was itching for something to tinker with that would scratch three long-running obsessions: fixed-pitch fonts, the command line, and UI frameworks.

I have a thing for fonts—especially monospace ones. When Microsoft released Cascadia Code, I needed to see it sing. Just staring at it in VS Code wasn’t enough, so I rewrote WinPrint. That helped. But not enough.

I grew up on the command line and have spent an embarrassing amount of time customizing shells and re-learning bash, CMD, and PowerShell magic incantations. It’s a lifestyle. And don’t even get me started on UI frameworks. The Windows vs. OS/2 battle was MY battle. I wrote some of the earliest Windows shareware and forgot more about Win32’s USER subsystem than most people will ever know.

Fast forward to today: Terminal.Gui has become a vibrant project with over 10,000 stars on GitHub and a growing community of contributors and users. We’re approaching alpha on v2, a massive refactor grounded in a real architecture. We added layout and style engines, modernized input handling, and built a system that doesn’t collapse when someone blinks at it sideways. It’s still absurd—but it’s cohesively absurd.

Along the way, we kept bumping into a familiar problem: How do you let consumers customize or override behaviors without forcing them to subclass everything? That’s where the Cancellable Work Pattern (CWP) came from.

CWP fell out of the code. We were solving real-world framework problems and suddenly this pattern kept appearing: structured phases of work, cancellable, interceptable, with optional hooks. Eventually I gave it a name, formalized it, and wrote it up.

Is it novel? Probably not. It’s a mashup of things you’ve seen—Template Method, Observer, pipelining, events-with-cancel args—but it works well in a UI framework. I’m proud of how clean and extensible it’s made v2.

If you’re a real CS person (or just play one on GitHub like me), I’d love your critique. Go read the CWP deep dive and tell me what’s wrong with it. Or what’s obvious. Or what I should’ve done differently.

This project has been weirdly validating. I have a BS in Systems Engineering, Software Option. But I’ve never felt like a real developer—not compared to the brilliant minds I’ve worked with: Curt Palmer, Todd Laney, Henry Sanders, Anders Hejlsberg, Jeffery Snover, Bob Atkinson, Jim Gray, David Weiss, Jim Lyon, and more. I have massive impostor syndrome.

But somehow, I ended up maintaining a terminal UI framework in 2025. It’s ridiculous. And wonderful. And brings me joy.

If you think it’s cool, confusing, or just plain dumb, leave a comment. I’m all ears.

The post Terminal.Gui: My Beautiful Absurdist Adventure first appeared on tig.log.

Most leaders claim they’re customer-focused or business-savvy, but let’s be brutally honest—most aren’t. They’re stuck prioritizing what they’re already good at, not what actually matters most or what gives them the most joy.

Here’s a simple yet powerful exercise, the CBTO Stack Rank, designed to force you into uncomfortable clarity about where you really stand.

CBTO (full blog post explaining it here) aligns clearly with the foundational elements of successful organizations:

• Customer = Product: What customer-facing value are we creating?
• Business = Strategy: How will we succeed and thrive long-term?
• Technology = Execution: How do we build and deliver effectively?
• Organization = People: Who will make it happen (and ensure we have fun along the way)?

Here’s how the CBTO Stack Rank Exercise works:

1. Understand CBTO (PSEP) – Effective leaders balance four critical lenses; each directly connected to a foundational element:
   • Customer (Product): Deeply understanding and fiercely advocating customer needs to deliver meaningful value.
   • Business (Strategy): Crafting clear, sustainable paths to achieve long-term success.
   • Technology (Execution): Skillfully leveraging technology and processes to ensure effective implementation and delivery.
   • Organization (People): Building, developing, and nurturing high-performing teams and cultures to execute the vision—while making sure it’s enjoyable and fun.
     
2. Current Strengths Stack Rank – Honestly rank yourself from strongest to weakest across these four dimensions.
   
   You might say: “I’m strongest in Technology, decent in Organization, weaker in Business, and weakest in Customer—so T-O-B-C.”
   
3. Future-Focused Stack Rank – Now ask yourself: “Where should I intentionally invest my energy and focus over the next 5–10 years?”
   
   You might say: “I’m already an excellent Software Development Manager, but I really want to become a multi-discliplinary leader and also be excellent leading Product. So for the next few years I’m going to prioritize learning Product skills. So, C-O-T-B.”
   
4. Role Alignment Stack Rank – Finally, stack rank again based on what your current company or manager expects most from your role moving forward.
   
   You might say: “I actually just asked by boss, and she says she needs me to be much stronger in O. She doesn’t need another Product leader, but she does need more Sr. Manager’s of Software Development. So, O-T-B-C.”

This straightforward exercise reveals uncomfortable truths about personal biases and organizational gaps. And yes, it’s equally powerful when applied at the team or organizational level, helping clarify strategic priorities and identifying critical growth opportunities.

Most leaders find that their most significant development isn’t about patching weaknesses—it’s about intentionally aligning their growth with doing work that’s fun, future roles, team needs, and market demands.

Want brutal honesty and clarity about your leadership approach? I’m available to help during open office hours: kindel.com/officehours.

The post Your Leadership Priorities Are Probably Backwards (And How to Fix Them) first appeared on tig.log.

Organizational Silos Are Like Gravity. You Don’t Hope Them Away. You can’t culture-doc them into nonexistence. You Engineer Around Them.

There is no perfect organization. Silos are inevitable.

They form naturally — geographic, functional, operational gravity.

They form intentionally — when you design a structure to scale accountability, you create new boundaries.

The mistake leaders make isn’t creating silos.

The mistake is failing to install anti-silo mechanisms that detect, dampen, and bridge them over time.

Silos are like gravity. You don’t fight gravity with good intentions. You fight it with engineering.

Silos Are the Cost of Scale

When humans group up, they specialize.

Specialization creates local optimization.

Local optimization creates walls.

At small scale, you can brute-force collaboration through proximity and relationships.

At scale, you can’t. Even if you design the org chart perfectly today, silos will emerge tomorrow. New projects. New leaders. New pressures. Entropy is relentless.

Structure is necessary — but structure alone isn’t sufficient. Without active anti-silo mechanisms, every org eventually rots behind its own walls.

Anti-Silo Mechanisms: The Only Real Defense

If you’ve read Mechanisms, you know:

“A mechanism has an owner, clear inputs and outputs, and exists independent of any one leader’s energy.”

An owner is always a named individual, never a team.

A mechanism without a single, accountable human is a dead mechanism.

Silo-busting doesn’t happen because you tell people to “collaborate better.” It happens because you install mechanisms that force visibility, trust, and shared accountability across boundaries.

A Pragmatic Inventory of Anti-Silo Mechanisms

Not all anti-silo mechanisms are obvious.

Some are classic.

Some are non-intuitive.

The best organizations use both.

Classic Anti-Silo Mechanisms

• Cross-Team Reviews
  Input: Work in progress across teams
  Output: Cross-team feedback, surfaced dependencies
  Owner: Named individual (e.g., program manager)
  
• Shared OKRs
  Input: Jointly accountable key results
  Output: Alignment that forces teams to work together to win
  Owner: Named executive across participating orgs
  
• Cross-Functional Projects
  Input: Temporary teams built around a customer outcome, not a silo boundary
  Output: Customer impact that no single org could deliver alone
  Owner: Named initiative lead

Non-Intuitive Anti-Silo Mechanisms Peer Coaching Across Silos

When I built the Alexa Smart Home org, we created STOs (Single-Threaded Organizations) for each domain. Each domain — Lighting, Cameras, Locks, etc. — represented a distinct customer-facing scenario area within the Alexa Smart Home product. Each had a dedicated STO (Single-Threaded Owner) — a leader accountable end-to-end for that experience.

The structure worked — but it created silos. To bridge them, I installed a cross-coaching mechanism.

• Sharbani (STL for Cameras) was a Product leader.
• Ganesh (STL for Lighting) was an Engineering leader.

I paired them:

• Sharbani coached Ganesh on Product leadership.
• Ganesh coached Sharbani on Engineering leadership.

Inputs: growth ambition, cross-silo pairing
Outputs: cross-functional empathy, trust, early tension detection
Owner: Me
Durability Mechanisms: Quarterly check-ins and baked into STL expectations

This wasn’t just mentorship. It was a mechanism.

Embedded Roles

Embed specialists (PM, marketing, finance) into adjacent teams. Dual loyalty forces context-sharing and breaks down walls.

Rotation Programs

Temporary stints in another org build empathy that lasts. You only need a few — not a program at scale.

Customer Journey Reviews

Instead of reviewing output team-by-team, inspect full customer journeys. Force everyone to see how their work connects (or doesn’t) from the customer’s perspective.

Cross-Org Operational Updates (Recruiting Example)

For Alexa Smart Home, I grew the team from 7 to 150 people in under a year. I ran a Weekly Recruiting Update where every hiring manager reported:

• Open positions
• Pipeline status
• Blockers

The primary goal was hiring velocity. The secondary effect: people managers who didn’t normally interact got exposed to each other’s context. It built empathy and alignment across org boundaries.

Inputs: Hiring data from all people managers
Outputs: Hiring urgency, cross-org visibility, informal bridges, and coaching moments.
Owner: Me
Durability Mechanisms: Dashboard + Weeky Cadence

Auditing Mechanisms

Silos thrive on a lack of visibility. Auditing kills that oxygen. Auditing isn’t about punishment. It’s about systematically inspecting details so you can detect decay before it metastasizes.

Leader Dive Deep Audits

Diving deep does not mean micromanagement. Senior leaders personally inspect:

• Random support tickets
• Raw service metrics
• Cross-team tech designs

Inputs: Unfiltered operational artifacts
Outputs: Early detection of hidden friction, sloppiness, duplication
Owner: Named VP/GM
Durability Mechanisms: Cadence-based inspections and sampling

Systematized Surface Audits (Paper Cuts Example)

At Control4/SnapOne, I inherited 4,700+ SKUs — many were aging and neglected.
I created the Paper Cuts Mechanism.

A Paper Cut (also called a Broken Window) is bug, defect, or missing feature directly impacting the customer experience that won’t normally get fixed due to resource constraints. Broken Windows exist in products, code, packaging, documentation, bug database, knowledge management systems, etc.

Inputs: Minor issues from across the product portfolio
Outputs: System-wide visibility into sloppiness, permission to obsess over customers
Owner: Head of Product
Durability Mechanisms: Paper Cuts Dashboard + Monthly Review

Pragmatic Guidance

If you aren’t building explicit anti-silo mechanisms, you’re not leading — you’re hoping.

• Name your silos — Visibility beats resentment
• Install real mechanisms — With single human owners
• Normalize inspection — Audit people, processes, and mechanisms themselves
• Reward surfacing issues early — Punish hiding, not imperfection

Silos aren’t evil.

Pretending they won’t form is.

Want help engineering anti-silo rockets? I coach execs through this exact stuff. My open Office Hours are here.

See Also

• Exorcise the Ghost of Mediocrity
• Mechanisms
• People Management Is Not a Hobby
• How We Scaled Alexa: One Problem, One Leader

The post Your Org Is Sinking in Silo Gravity. Build a Damn Rocket first appeared on tig.log.

Every great org starts the same way: a handful of people with conviction, urgency, and the energy of a shared mission. The best ones are driven by clarity of purpose, crisp principles, and a team that believes in building something that matters.

But then… something changes. Not all at once. Slowly. Subtly. A mood creeps in.

That’s the ghost of mediocrity.

It doesn’t smash the windows or light anything on fire. It just takes the shine off everything. It dulls your edges. It makes okay feel fine. It feeds off ambiguity, comfort, and leadership that’s afraid to rock the boat.

You don’t need a reorg to get mediocre. You just have to start being intentional.

Symptoms of the Ghost

The ghost shows up in ways that are easy to dismiss—until it’s too late:

• Meetings feel “meh.” – Nobody’s pushing. Nobody’s fighting for great. People show up, nod along, then leave without making decisions or holding each other accountable.
• Missed Dates Go by Silently – Slipping milestones is viewed as acceptable. It’s ok to promise to deliver something without saying when. Delays late in the game somehow come as a surprise.
• Decisions drift – They don’t get made, or they get made by accident. Or every decision is treated the same. No clarity, no urgency.
• Everything feels urgent but nothing actually moves – The team is reactive, not proactive. “We’re so busy” becomes an excuse for not doing the important work.
• Ownership is fuzzy. – “That’s not my job” creeps in. Everyone’s responsible, so no one is.
• The bar silently lowers – “It works” starts replacing “It’s awesome.” “That’s how we’ve always done it” replaces “How hard could it be?” or “What would it take?”
• Management theater replaces leadership – Managers manage—but they’re not leading. Being a people manager is treated as hobby, not the job.
• The fun is gone – And no one even notices.

How to Exorcise the Ghost of Mediocrity

This isn’t about a pep talk or a new process. It’s about getting back to what made you great in the first place. Here’s how:

1. Re-ground in mission—and principles

Your mission is your “why,” but your principles are your “how.” If you haven’t written down your team’s tenets, do it now. If you haven’t reviewed them in the last 30 days, do it tomorrow. If you don’t have mechanisms that re-enforce them, build some. Use them to evaluate decisions. Ask your team: Which tenet did we ignore here? If you don’t, people will make up their own.

See: Tenets

2. Use prioritization to create clarity, not chaos

If everything’s a P1, nothing is. This is where the Something Needs to Starve model comes in: stack rank your team’s priorities 1-N. If N is greater than 3 or 4, stop working on anything greater than 4. Don’t let your team confuse activity with progress. Make the tradeoffs explicit and be okay letting things slip on purpose.

See: Something Needs to Starve, 90% of the Decisions You Make Don’t Matter

3. Slow down to move fast

If your team is stuck in a loop of urgency—always reacting, never leading—it’s time to pause on purpose. That means pulling your leadership team out for a full offsite. Three days. No laptops. Facilitated.

Yes, it feels like you don’t have time. That’s the point.

You need time to step back, reset shared understanding of mission, principles, and priorities. Make real decisions about what not to do. That clarity will save you months of wheel-spinning.

I routinely do this kind of work with teams. Grab time on my office hours and let’s talk.

4. Default to action

Create a culture that moves. Replace weekly status meetings with fast daily standups: “What did you ship?” “What’s blocking you?”

Don’t accept “It’s not possible”. Instead, ask “How hard could it be?” Or “What would it take?“

Get in a room. Get it off Slack and Email. If you think travelling around the world to meet face-to-face is expensive, imagine how expensive it is to be mediocre.

90% of decisions do not matter. Just pick a direction and GO!

See: 90% of the Decisions You Make Don’t Matter, One-Way and Two-Way Doors, Taxonomy and Lexicon, The 5Ps: Achieving Focus in Any Endeavor, Tenets

5. Treat Dates with Sanctity

In project management, the ideal is No Date Is Ever Missed. Build a culture that strives to get asymptotically close to that ideal. Nothing scares away mediocrity more than dates, dates, and dates for dates.

Make it unacceptable to say, “I’m working on X” without saying “…and I’ll be done by [date].” If a milestone is missed, treat it as an error, and engineer the sh*it out of it.

See: Have a Plan (With Dates) Path To Green, The 5Ps: Achieving Focus in Any Endeavor, How Meeting/Not-Meeting Goals relates to Earn Trust and Insist on Highest Standards

6. Give one person the wheel

Every major initiative needs a Single-Threaded Leader. That person owns the outcome. They’re not a figurehead. They don’t need a committee to move. If something doesn’t have a name next to it, it won’t happen. If it doesn’t have a date, it doesn’t exist.

Every owned initiative needs both a human and a deadline. No fuzzy timelines. No passive verbs. Ambiguity is the ghost’s playground.

See: Single-Threaded Leadership

7. Raise the bar—relentlessly

Don’t just ask “Is it done?” Ask, Would we want to do it this way again? Do post-mortems where you grade the work against your tenets. Look at failure modes—especially when customers are impacted—and engineer the sh*t out of them. Don’t just tolerate bugs or outages. Treat them like opportunities to show your standards in action.

Get in the habit of saying “this isn’t good enough” without shame or drama. High standards aren’t toxic—unclear standards are.

See: Engineer the Sh*t Out of Errors Everywhere, How Meeting/Not-Meeting Goals relates to Earn Trust and Insist on Highest Standards

8. Management Theater

This is where the O in CBTO breaks down. You see managers who are “handling the team,” keeping the lights on—but not raising the bar. They hire for convenience, avoid hard conversations, and optimize for stability over excellence.

That’s how the ghost gets in the door.

Great managers lead. They actively curate the team, give feedback that stings and helps, and never treat people management like a side project. If your managers aren’t coaching, developing, and inspiring, your org will drift—quietly, slowly, and dangerously.

See: People Management Is Not a Hobby, CBTO

9. Make it fun again

Fun doesn’t mean ping-pong tables. It means people laughing in meetings because they care. It means a team that celebrates wins and tells stories that live on. It means making space for joy—not as a luxury, but as a signal that you’re building something real. It means taking the customer & business seriously, not yourself.

Celebrate the small victories. Visibly. Every day. Re-enforce bar-raising behaviors with thanks. Enable a team-member to send dorky jokes of the day to everyone.

The ghost of mediocrity doesn’t show up with a name tag. It whispers. It erodes. And if you don’t actively push back, you’ll wake up in an org that looks fine on paper but feels hollow inside. Above, I’ve articulated pragmatic tips you can start using right now to build a culture of excellence. Use my office hours to dive deeper.

The post Exorcise the Ghost of Mediocrity first appeared on tig.log.

The Single-Threaded Leader (STL) model was born inside Amazon and became foundational to how we scaled and delivered customer-obsessed innovation—especially in the early years of Alexa. I wrote the original doc that helped crystalize the model, and it’s been gratifying to see how the idea has since echoed through other orgs, blog posts, and companies trying to scale impact without scaling chaos

“The best way to fail at inventing something is by making it somebody’s part-time job.”
— Dave Limp

This post is about how I now explain STL to the teams and leaders I coach—and how to apply it to build durable, focused organizations.

What is a Single-Threaded Leader?

A Single-Threaded Leader (STL) is one person—fully dedicated, fully accountable—for solving a specific customer problem over time.

This does not necessarily mean they are a people manager. STLs may have teams reporting to them. Or they may lead via influence. Either way, they are the one person with the long-term mandate to own the problem and deliver results.

They are not part-time. They are not spread across multiple areas. They don’t just “support” the work—they own it, end to end.

What is a Single-Threaded Organization?

A Single-Threaded Organization (STO) is the structural extension of the STL model. It means organizing teams around long-term programs, not around short-term projects, functional silos, or headcount allocations.

A good STO:

• Is aligned to a well-defined scenario area with durable customer value.
• Operates over a time horizon measured in years.
• Enables autonomy and end-to-end ownership for the STL and their team.

In most cases, STOs should align with Programs—large, strategic areas where the organization expects to invest “forever.” Sometimes, an STO may be aligned with a Product, if that product is enduring. But STOs should almost never be built around Projects, which are temporary by nature.

Organize your team for continuity, not convenience.

Why It Works

The STL/STO model works because it optimizes for clarity, focus, and accountability:

• You always know who owns what.
• You reduce dependencies and cross-team friction.
• You build institutional knowledge that compounds over time.
• You structure your org in ways that naturally lead to better, more modular system architectures (Conway’s Law works both ways).

And if you’re in a scaling environment? STL/STO is a force multiplier. It enables faster decision-making and better long-term thinking—at the same time.

Leadership vs. Ownership

The STL model unifies two powerful, often conflicting ideas:

• Ownership means you’re accountable. You’re on the hook for outcomes.
• Leadership means you inspire and influence others to follow.

Too much ownership without leadership = bottlenecks and burnout.
Too much leadership without ownership = fuzzy responsibility and slow progress.

A strong STL embodies both. They lead—often without direct authority—and they own, without excuse.

Tenets of STL/STO Teams

Great tenets are written as if they are already true. These are.

• STLs are single-threaded. Each STL has exactly one long-term problem space they are 100% dedicated to. They are not shared across domains or overloaded with side hustles.
• STOs are organized around Programs. STO teams are aligned to long-term areas of customer value, not short-term projects or matrixed functions.
• Team size is intentionally small. A STO team is small enough to be fed with two pizzas—typically 3 to 8 engineers and no more than ~15 people total. Small teams move faster and make better decisions.
• Org structure matches system architecture. Team boundaries are designed with Conway’s Law in mind, enabling clean interfaces and modular architecture.
• We start with focused engineering effort. We don’t wait for perfect org charts. We start by giving one engineer total focus on a customer problem, and grow the team as needed.
• Engineers are athletic. STO teams require engineers who can work across disciplines—infra, product, design, operations—to solve real problems end to end.
• The STL defines the model. We are not dogmatic about structure or process. Each STL determines the right operating model for the problem space they own.

Whether you’re building a startup or refactoring a massive enterprise org, the STL model forces the conversations that matter:

• Who owns this?
• What problem are we solving?
• What’s getting in the way of focus?

And if you’re a leader trying to scale, ask yourself: Are you designing for coordination… or for ownership?

Want help implementing STL/STO thinking in your org? I’m available for coaching—and my office hours are open.

Appendix: Lexicon

Here’s how I define the terms that underpin effective STL/STO thinking:

• Program – A long-term (measured in years) human effort to deliver customer value in a well-defined scenario area. Programs are generally defined around areas where the company will invest “forever.” For example, a Rocket Engine Program might include reusable engine R&D and associated infrastructure.
• Project – A short-term (measured in days, weeks, or months) effort to deliver something specific. When a project is done, the resources move on. Projects are how we deliver incrementally inside Programs. For example, building a test stand for an engine is a Project inside a larger Program.
• Product – A bundle of functionality delivered to customers as a cohesive whole. Products are launched via Projects, and great ones are often supported long-term by Programs. For example, a 100% reusable launch vehicle is a Product resulting from multiple Projects.

STOs should be built around Programs, sometimes Products, but rarely Projects.

The post How We Scaled Alexa: One Problem, One Leader first appeared on tig.log.

There are three states a leader can be in relative to people management:

The Builder

This is the Individual Contributor (IC) track. Builders go deep on the T, C, and B parts of Customer, Business, Technology, Organization: they write code, close deals, publish policy, and drive execution. Their leadership shows up through ownership, influence, and follow-through. Their product is what they ship.

Builders can and should influence the entire company. This is why engineering job ladders include rungs like Principal Engineer and Technical Fellow.

The Apprentice

A time-boxed phase—ideally 9–12 months—where a Builder tries on the role of people manager. Apprentices intentionally try to discover if a focus on the O is fun. Apprentices are evaluating “Do I love this work?“ while the company is asking “Are they growing into it?” If either answer is no, that’s not failure—it’s clarity. Back to Builder. No harm, no foul.

But only if the org is designed to support that.

Without psychological safety and leadership buy-in, the “no harm, no foul” frame collapses. Too many leaders stay in limbo because stepping back would look like failure. That’s a systemic failure.

The Steward

This is the People Manager track. Stewards don’t dabble. Their product is the people, the team, and the org. The engineering they do is the engineering of the O; People, Culture, and Scale. Stewardship means hiring as the highest priority, designing orgs, aligning humans, and driving accountability. Any IC work is extra credit—done only when it reinforces the core job of leading.

The Dangerous In-Between

What’s not allowed?

Some vague in-between “I’m still mostly doing IC work but I have a few directs” state.
That’s how you get the Pointy-Haired Boss from Dilbert: a confused middle-manager who never really wanted the job and won’t treat it like one.

Being a great People Manager isn’t a promotion. It’s a profession.

And like any profession, it requires focus, discipline, feedback, and reps.

What to Focus on as an Apprentice

When you’re in the Apprentice phase, IC work should fade into the background. Instead, you’re leveling up across these core skills (or discovering you hate the work involved):

• Influencing Without Authority – Lead through alignment, not title. See Lead Without Authority.
• Giving and Receiving Feedback – Learn and practice frameworks like SBI (Situation–Behavior–Impact). Make it safe and actionable.
• Coaching vs. Directing – Know when to give answers and when to pull the answers from your team.
• Delegation – Don’t just hand off tasks—hand off ownership. See Dive Deep != Micromanaging.
• Running 1:1s – Build trust, unblock work, develop people.
• Conflict Management – Don’t avoid tension. Step into it and resolve it productively.
• Communicating Up, Down, and Across – Match your message to your audience. Keep context flowing. Become excellent at clear Lexicons and Taxonomies.
• Ruthless Prioritization – Discover and master the skills that enable teams and individuals to stay focused. See One-Way and Two-Way Doors and The Shocking Truth About Prioritization.
• Recruiting, Interviewing, Hiring, and Onboarding – Learn to raise the bar, not just fill headcount. Master.
• Performance Management – Setting and holding a high bar. Recognizing excellence and celebrating victories. Addressing gaps quickly. Practicing the skills that ensure employees are never surprised by a bad review.

If the answer at the end of this is “Yes, I love this” and “Yes, they’re thriving”—great. You’re ready to become a Steward.

If the answer is no? Great. You’re a Builder. Now with better self-awareness.

The Attributes of a Great People Manager

Here’s my ordered list:

1. Treats People Management as a Profession
2. Has High Empathy and Emotional Intelligence
3. Has Exceptionally High Standards, Especially Regarding Principles
4. Can Carry a Vision and Leads From the Front
5. Continually Hones Conflict Management Skills
6. Is Biased Towards Teaching to Fish vs. Fishing
7. Is Positive and Optimistic
8. Advocates for People
9. Loves to Learn, Is Curious, and Adaptable
10. Is Problem Oriented, not just Results Oriented
11. Is More than Technical Enough

I scoured the internet—and yes, even asked the AIs—for lists like this. Most get 2 through 11 right.

But almost no one puts #1 first.

Treating People Management as a profession is the foundation. Without it, everything else is just a hobby. Or worse, theater.

I’ve seen firsthand how organizations fail when they treat people management as a checkbox instead of a craft. I work with senior leaders and execs to fix the underlying systems and incentives that lead to mediocrity—the cultural rot that lets the Pointy-Haired Boss archetype persist.

If you’re building a company—or rebuilding one—and want a world-class people management culture, I’d love to help.

My office hours are free and open. Let’s talk.

The post People Management Is Not a Hobby first appeared on tig.log.

The first rule of skills is simple: know the skill exists.

That sounds obvious, but most people—especially growing leaders—aren’t intentional about skills. They focus on outcomes. Goals. KPIs. But they don’t stop to ask: What specific skill am I building right now? What skill does this teammate need?

When you’re intentional about skills, you grow faster. You get better at execution. And you help others do the same.

This matters. Because leadership is a set of skills. Not magic. Not charisma. Skills.

And just like in sports, music, or meditation—skills are learnable. You don’t become a great goalie by accident. You drill. You study. You get coached. Leadership is no different.

So, how do you build a skill?

1. Know the skill exists. If you don’t know “naming things well” is a skill, how would you ever get good at it?
2. Get curious. Curiosity fuels learning. Without it, you’ll stall. With it, you’ll fly.
3. Practice. A lot. Think 10,000 reps, not 10. You’ll make mistakes. Good. That means you’re learning.
4. Celebrate small victories. This is also a skill—knowing how to recognize progress and reinforce it.
5. Study examples. Watch the pros. Emulate. Steal with pride.
6. Get coaching. Critique, reinforcement, cheerleading. All of it matters. Don’t go it alone.
7. Teach. If you can teach it, you truly understand it. It’s the final boss of skill-building.
8. Keep practicing. Forever. Skills are either growing or dying. There’s no neutral.

---

Here’s an inventory of real leadership skills I’ve come to recognize—especially the non-obvious ones, or the ones so obvious they’re ignored. Many are unpacked further in my blog:

• Driving Change – How to be a Secret Agent (of Change)
• Being Principled (Driving Clarity and Alignment) –
  • The Secret to Delivering Outsized Results
  • Crafting Tenets
  • Debating Tenets
  • The Tension is Intentional
  • Just Right Porridge and Leadership Principles
  • Work Backwards From The Customer
  • Focusing on users is not Customer Obsession
  • Ownership | tig.log
  • Have Backbone, Disagree and Commit | tig.log
  • Dive Deep != Micromanaging
  • How Meeting/Not-Meeting Goals relates to Earn Trust and Insist on Highest Standards
• Influencing without Authority –
  • Lead Without Authority
  • Don’t Sell Ideas – Debate Them
  • Have Strong Opinions, Weakly Held
• Being Planful Date-Oriented (vs reactive) –
  • The 5Ps
  • Have a Plan (With Dates)
  • Path To Green
• Using Mental Models Effectively – Mental Models
• Naming things well – Taxonomy and Lexicon
• Making Decisions That Stick, Fast –
  • One-Way and Two-Way Doors
  • Don’t Make Your Team Say No To You
• Execution Excellence –
  • Ruthless Prioritization – No Starving Children? The Shocking Truth About Prioritization.
  • Don’t Rely on Good Intentions – Mechanisms
  • Focus on the Important, not Urgent – Make the Routine, Routine – Blow up Dunbar’s Number
  • Send in the Wolfes: Why Hard Problems Need Fixers, Not Just Leaders
  • Engineer the Sh*t out of Errors – Everywhere
  • Path To Green
  • How Meeting/Not-Meeting Goals relates to Earn Trust and Insist on Highest Standards
• Thinking Big – Biases and Fallacies Lead to Smol Thinking
• Writing things down to sharpen thinking
  • How To: Write a Working Backwards Doc
  • Details Matter in Presenting Narratives
  • A FAQ About Frequently Asked Questions
  • Clear Narratives Show Instead of Tell
  • Let Word Work For You
  • Be a Great Reader
• Giving and Receiving Feedback –
  • Have Specific Conversations, not General Conversations
• Celebrating small victories (authentically)
• Saying “I don’t know” and meaning it
• Making people feel seen
• Repetition without sounding like a broken record
• Defusing tension without sugarcoating the truth
• Asking questions that unlock new thinking
• Letting someone else take credit (on purpose)
• Staying calm when it would be easier to freak out
• Calling out excellence in real-time
• Taking the blame without qualifying it
• Making a boring meeting fun and useful
• Knowing when to walk away from a bad idea you were excited about
• Translating between exec-speak and engineer-speak

None of these are magic. They’re just skills. Like skiing powder. Like meditating. Like driving a manual transmission.

Learn them. Teach them. Practice them.

Just start by knowing they exist.

The post The First Rule of Skills first appeared on tig.log.

When an organization hits a wall—be it a product failing in the field, a critical project slipping off the rails, or a big customer walking away—the knee-jerk reaction is often to lean on the leaders already in place. After all, they’re the ones with the titles, the experience, and the authority, right?

Wrong. Hard problems don’t care about org charts. Once you’ve got a grip on what’s broken, the real trick is finding the right people to fix it, not just piling more responsibility on the folks already wearing the leadership hats.

I’ve seen this play out time and again: a team scrambles to patch a sinking ship, but the captain’s too busy steering to notice the hull’s cracked. Leaders are crucial—they set the vision, rally the troops, and keep the machine humming—but when the stakes are high and the problem’s gnarly, you need specialists, not just generals. You need someone who can walk in, assess the mess, and clean it up with precision—like a certain suit-clad fixer we all know.

“It doesn’t make sense to hire smart people and then tell them what to do; we hire smart people so they can tell us what to do.” – Steve Jobs

The temptation to default to existing leadership is real. They’re known quantities, and shuffling the deck feels risky when the clock’s ticking—like you’ve got 40 minutes to bury a problem before it spirals. But that’s a trap. Sticking with the usual suspects can leave you spinning your wheels, when what you need is a crew that can roll up their sleeves and get it done, no questions asked.

This isn’t about sidelining leaders—it’s about empowering them to do what they do best: lead, not fix every nut and bolt. Satya Nadella gets it: “Our industry does not respect tradition—it only respects innovation.” If your go-to move is throwing the same old playbook (or the same old people) at a new crisis, you’re not innovating—you’re stalling. Find the engineers who can debug the code, the customer whisperers who can win back trust, or the logistics wizards who can untangle the mess. Leaders should orchestrate, not operate. They’re the ones calling the shots from the diner, not scrubbing the blood out of the carpet.

So next time your organization’s facing a beast of a problem, resist the urge to just “leader harder.” Dig deeper. Who’s got the skills, the grit, the insight to crack it? It’s not about who’s already in the corner office—it’s about who can stroll in, cool as ice, and say, “I’m here to fix this.” Find those Wolfes—those fixers—and watch the impossible become doable.

The post Send in the Wolfes: Why Hard Problems Need Fixers, Not Just Leaders first appeared on tig.log.

Let’s start with a simple question: What kind of work do you like doing?

Go ahead, answer it in your head. I’ll wait.

…

Did you just describe what you like working on? Or who you like working with? Or maybe you veered into what you like accomplishing or who you like working for? If so, you’re not alone. Nine out of 10 leaders, when asked this question, end up answering a completely different one.

Here’s the thing: the dictionary definition of “work” is straightforward:

be engaged in physical or mental activity in order to achieve a result; do work.

But when it comes to understanding what kind of work energizes us (or drains us), we tend to get tangled in the weeds of tasks, people, outcomes, and environments.

One of my favorite ways to start a coaching session with a new leader (or an interview) is to ask, “What kind of work do you enjoy?”. Invariably, folks launch into a passionate monologue about the projects they love, the people they collaborate with, or the impact they hope to make. Folks talk about what they work on, not the actual work itself. It’s like describing a delicious meal by listing the restaurant’s interior design.

This confusion leads to a fundamental problem: how can you find fulfilling work if you don’t even know what “work” truly fulfills you? You might be chasing a title, a project, or a company, when what you really crave is a specific type of work.

I’ve seen this play out countless times with my mentees. They’re stuck, frustrated, and unsure why their current job (or career path) feels so…meh. They’re answering the wrong question, and therefore, getting the wrong answers.

So, how do we fix this? How do we cut through the noise and finally understand what work truly sparks joy? It’s time for a little self-reflection, armed with a pen and paper (or your favorite digital note-taking tool).

The Joy vs. Drain Matrix: Unearthing Your Joy (and Avoiding the Drains)

This simple tool is designed to help you answer the question actually being asked: What work do you like doing? And, just as importantly, What work drains you (even if you’re good at it)? This is about getting down to the nitty-gritty of what you actually do. Forget the fancy titles and impressive projects for a moment. We’re going deep.

Grab a piece of paper and create a three-column table. The columns are:

1. The Work: Be specific! Think about the actual activities involved. Instead of “managing projects,” think “facilitating meetings,” “creating spreadsheets,” “writing reports,” “negotiating contracts,” etc. The more granular you are, the better.
2. Joy?: Does this type of work bring you joy? A simple “Yes” or “No” will do.
3. Drain?: Does this type of work drain your energy, even if you’re good at it? Again, “Yes” or “No.”

Start listing examples of work you’ve done. Be specific. Don’t just write “meetings”. Instead, think about:

• Facilitating a brainstorming session
• Debugging a complex piece of code
• Writing a project proposal
• Coaching a junior team member
• Analyzing financial data

For each example, ask yourself:

• Did this work give me joy?
• Did this work drain me?

And here’s the kicker: Make sure you cover work across all four CBTO perspectives (Customer, Business, Technology, Organization). If you’re not familiar with CBTO, check out my post on it here.

For example, under “Customer,” you might list “conducting user interviews” (joy: yes, drain: no) and “resolving customer complaints” (joy: no, drain: yes). Under “Technology,” you might list “writing code” (joy: yes, drain: sometimes) and “troubleshooting hardware issues” (joy: no, drain: definitely yes).

The Aha! Moment (and What to Do With It)

Once you’ve filled out your table, you’ll likely have some “aha!” moments. You might realize you love the process of problem-solving, regardless of the context. Or maybe you discover that you’re energized by collaborative work but drained by solo tasks.

This isn’t just about identifying what you’re good at—it’s about identifying what energizes you. Because here’s the truth: you can be really good at something and still find it soul-sucking.

Why This Works

The Joy vs. Drain Matrix forces you to get specific. It cuts through the vague, feel-good answers and helps you pinpoint exactly what kind of work lights you up—and what kind of work leaves you running on empty.

It’s also a great tool for:

• Make better career decisions: Instead of chasing a specific job title, you can focus on roles that involve the types of work you enjoy.
• Improve your current job: Identify tasks that drain you and look for ways to delegate them or minimize their impact. Focus on incorporating more of the work that brings you joy.
• Communicate your needs: When talking to your manager or potential employers, you can articulate your work preferences clearly and confidently.

This exercise isn’t a magic bullet, but it’s a powerful tool for gaining clarity about what truly motivates you in your work. It’s time to stop answering the wrong question and start focusing on the work that makes you thrive.

What’s on your Joy vs. Drain Matrix? Let me know in the comments—or better yet, share your own insights and surprises!

Related Posts:

• The Job Decision Matrix
• Customer, Business, Technology, Organization (CBTO)
• Find Work That Does Not Feel Like Work

The post Stop Answering the Wrong Question: Unlock Your True Work Happiness first appeared on tig.log.

This post introduces the concept of Working Backward (WB) narratives and formalizes the mechanism through which a company can drive product development. The WB mechanism is a complete process designed to create a “virtuous cycle” that re-enforces and improves itself as the team participates in it.

“Put the customer first, have a plan, create a shared mission, get early victories, remove process, and make it fun.” – tig

A WB narrative is a form of written memo that articulates the customer experience of a proposed product, feature, or program concept. A great WB doc answers all the questions required for stakeholders to understand the deliverable (product, feature, or program). WB docs are the primary tool in our broader mechanism for “always working backwards from the customer.” Working backwards from the customer enables us to have clarity of thought on what we want to create, up front, so we can then figure out what needs to be invented to make the customer experience true.  

 “No battle was ever won according to plan, but no battle was ever won without one.”  – Dwight D. Eisenhower

Standardized tools for creating plans make organizations more effective because standardization drives consistency and reduces the mental burden for everyone involved. Plans always start with the customer and work backwards. Plans always have the 5Ps: Purpose, Principles, Priorities, People, and the Plan. WB docs are a standardized tool for the initial forming of plans. A great WB doc creates clarity of thought around the purpose, principles, and priorities for the plan. It enables a broader team (People) to invent and execute. It asserts an ambition about when something will happen (the end-date of the Plan).

Creation and Review Process

The process of creating a WB doc is iterative and involves all disciplines but is often led by a Product Manager. When the final WB narrative review is held, and everyone is done reading, everyone will have clarity on the product, feature, or program we hope to build.

We can be as flexible as needed on the steps involved in creating and reviewing WB docs. But the process typically looks like this:

1. Someone has an idea for a product, feature, or program. If there’s a PM that is already responsible for the domain the idea is related to, the PM is asked to add the idea to their “idea backlog”. If the PM can’t prioritize diving deep into the idea, he/she owns informing the person who thought of the idea of this fact. At some point there’s enough interest, passion, or direction around the idea that someone (could be anyone, but is often a PM) takes on ownership of writing the document. We’ll call that person the WB owner.
2. The WB owner creates a new document in Word using the WB Narrative template and writes a rough draft of the WB artifact to get the juices flowing. The owner then gets other stakeholders and interested parties to read the doc and provide ideas/input. The owner iterates until the doc feels complete and ready for the first review (this is a judgement call).
3. The owner schedules a WB doc review, inviting relevant stakeholders. This calendar entry is the forcing function for the owner to get the doc in shape in time.
4. The owner drives the WB doc review meeting, listening carefully to questions asked and input given.
5. The owner then incorporates the feedback, simplifying the document.
6. Repeat steps 3-5 until the stakeholders feel they all have clarity of thought and the idea has been boiled down to its most simple form. When they do, the process is complete. 
7. Archive the doc somewhere.

“The doc is complete when nothing more can be removed from it.” – anon

Document Structure

A great WB document steps the reader through a proposed customer experience and then answers all the obvious (and not so obvious) questions readers may have about the idea. To this end there are typically five sections in a WB doc:

1. The introduction – A few terse paragraphs that allow the review meeting to be effectively run with the owner saying, simply, “ok, let’s read”.
2. The working backwards artifact – This is the prose that describes the desired customer experience we will work backwards from.
3. A set of frequently asked questions (FAQ) [optional, see below] – This is a numbered set of questions, with answers.
4. Appendices [optional, see below] – Supporting data required to understand the concept. These are printed with the main document. These appendices are not counted against the six-page limit, but authors should plan on readers taking the time to read them during the review.
5. Back-pocket Appendices [optional, see below] – Supporting data that might clarify the concept. These are printed by the owner, but not handed out unless needed during discussion. 

Each of these five sections are described in more detail below.

Document Introduction

The best narratives are self-contained: the reader should not need someone to explain the goal of the document before (or after) reading it. The introduction is the narrative author’s tool for ensuring review meetings can start with a simple “ok, let’s read and then we’ll discuss.” The best introductions are terse. They say no more than necessary to give the reader the context required to read the rest of the document.

Less-effective introductions are duplicative of content further on in the doc.

It is sometimes useful to provide context by presenting customer, business, technology, or organizational data in the introduction. However, doing so should be a highly-considered decision because it might mean the WB artifact (described below) is not clear or complete enough. In other words, the author should ask herself when writing the introduction: “Am I using the introduction as a cheat for not having to do the hard work of making the working backwards artifact truly stand alone?”

The introduction should clearly articulate the stage the document is in. For example, “This is the first draft that’s been reviewed by a broad audience. We are looking for broad, foundational input today.” Or, “This is an iteration of the idea that we reviewed with you last week. Based on the last review we’ve pivoted this idea to focus more on end-customers vs. dealer-customers.”

Working Backward Artifacts

The WB artifact is the centerpiece of a WB narrative. It is the most critical part of the WB document and the thing the team should spend the most time crafting and iterating on. The goal of the artifact is to present an ultra-clear picture of the deliverable’s customer experience in as concise a form as possible.

Examples of WB artifacts include a press-release (PR), a product review, a blog post, and a set of release notes. The most common form of artifact is a “working backwards press release”. The PR should be written as though it is the REAL press release we send out when the product/feature/whatever is released. Over time we can experiment with other forms, but as the organization starts to learn how to use the WB mechanism it is recommended this artifact be a PR.[1]

The WB artifact should be, in priority order, complete, clear, and concise.

• Complete – After reading, will the reader have a complete picture of the important aspects of the product? It should clarify who the customer is, how the customer will learn about the product, how they will acquire it, how much it will cost, and, of course, how it works for the customer.
• Clear – If readers of the WB artifact say “I don’t understand this” then the writer has failed to make it clear.
• Concise – The best product ideas are simple. If the author can’t create a concise WB artifact then the idea has not been simplified enough.

Frequently Asked Questions (FAQs

A list of questions with answers written in English are a great way to drive clear thinking on all the stuff that surround the central idea presented in the WB narrative. This ‘stuff’ includes things like strategy, execution, technology, business, and resources. Appendix A contains the current set of FAQs required for every product related WB narrative Product Managers will own. See A FAQ About Frequently Asked Questions for a set of Tenets on how to write great FAQs.

The main text of any narrative should be so clearly written that FAQs are unnecessary. To accomplish this, make a list of ten questions a reader might ask. Answer them. Then determine if those answers should be integrated into the main text (e.g., as part of the WB artifact) or handled verbally in the review meeting. Put the answers that don’t belong in the document but might be needed during the meeting (verbally) in a back-pocket appendix (see section on Back-pocket Appendices below). Repeat. By doing this, the author is forced to do the critical thinking to generate more questions and answers.

As the author does this, she or he will find questions that simply can’t be answered cleanly in the main document or are too critical to leave for the back-pocket. These become FAQs in the FAQ section of the narrative.

Appendices

Often it is useful to provide readers with supporting data, diagrams, or pictures to help them understand the concept. These should be put in appendices to be printed with the main document. These appendices are not counted against the six-page limit, but authors should plan on readers taking the time to read them during the review. In other words, if you include an Appendix expect your readers to spend time on them which will make the document reading part of the meeting take longer. Use with care.

Back-Pocket Appendices

A back-pocket appendix is a separate document that you bring to the review meeting, printed out, but you do not hand out unless absolutely needed. The idea is to have them “in your back pocket, just in case.” This is totally optional.

Appendix A – Frequently Asked Questions about WB Docs 1. When should I use the Working Backwards narrative versus other narrative forms?

WB docs can be effective anytime an idea is being discussed where there will be customer impact. It is important to remember that customers exist everywhere. Yes, your company’s real customers are important. But if the idea is an improved code review tool used by our own developers, then the customer is your internal developers. I could have written this narrative as a WB doc, but that felt doing so felt forced and awkward, so a judgement call was made to not use the WB form.

As a rule, anytime we are driving a deliverable like a product, feature, or program we will use a WB doc.

2. Is there an approval process for WB narratives?

There can and should be. To get started, use WB narratives simply as a way of ensuring everyone is on the same page, with total clarity, for product ideas. Have mechanisms for deciding what product ideas and projects are “approved” (e.g., product gates). For WB narratives where a leader requires a WB doc to be written, he or she will declare when the doc is “done.” This can change over time as more members of the team become experts in this mechanism.

3. Who should be involved in creating a WB Narrative?

This depends, and is a judgment call the doc owner must make. The doc must be complete, clear, and concise. For it to be complete, all key stakeholders likely need have provided input. The standard set of FAQs in Appendix A are designed to provide a forcing function that the owner has done his/her diligence in roping the right set of people in.

4. Who should be invited to WB narrative reviews?

Who gets invited to review meetings depends on how far along in the process the document is. If it is early stages, then the answer is whoever the doc owner thinks can help improve the document. In later stages, it is the set of people core to building the deliverable, typically Product Management, Engineering, Supply chain, Marketing, and Sales. If the goal of the review is to get guidance on the relative priority of the idea (e.g. if the team needs guidance on when put resources on the idea, and how many resources to apply), or if a leader requested it then the owner should invite that leader.

5. When should a WB document be reviewed with Sr. Executives?

As early as possible in the process. Sr. Executives, through the nature of their roles have broad context on the company’s customers, business, technology, and organization. Thus, then are in a unique position to provide structural and fundamental guidance or feedback on ideas. The earlier the owner involves these folks, the faster the doc will improve.

The key for doing this is to ensure the doc is clear (in its introduction) what stage the document is.

6. Do I have to use the standard template?

Yes.

7. Where should I store WB narratives?

They should be stored somewhere that supports collaborative editing in Word or equivalent word processor and where they can easily be searched over time.

Appendix A: Standard WB Narrative FAQs

These are REQUIRED FAQs that EVERY WB doc. This ensures we nail more of what is ‘knowable’ early in the process. Have a Word document template that includes these. Authors should use this list as a checklist for questions the WB doc must answer. If one of these is answered clearly in another part of the doc, or can be answered by asking a better question, then that is fine. The key is to ensure that the team is involving the right folks and doing the right critical thinking early in the process.

• Why is this important to [Company]?
• What are our Principles for this product/program/feature?
• What are the Priorities for the initiative?
• How will we describe this to sales?
• What is the plan for geographic roll out?
• How will this compare to the competition?
• What is the thing you think hardest about? (this is the most likely thing you have to do)
• Risk: What are the riskiest parts of this?
• Risk: What is the Impact, Likelihood, Exposure of those risks?
• Risk: What are five to seven mitigation strategies for those risks?
• What IP will we create as part of this?
• What tech do you envision we need to buy, license, use, invent, to make this true?
• What cloud services will be required to make this work?
• What device software will be required?
• How will we measure success (business & customer)?
• What metrics will you track?
• If this involves creating new hardware, what is the EOL plan for key components?
• HW: Have you had a kickoff meeting with change management?
• HW: What is the SKU plan (e.g. number of SKUs, bundles, etc…)?
• HW: What regulatory issues have you considered?
• HW: What is your naming plan?

---

I’ve put a Word doc version of this here so you can have access to the Word template I like using (that includes line numbers and consistent formatting): Working Backwards Narratives.docx

The post How To: Write a Working Backwards Doc first appeared on tig.log.

Prioritization means making decisions that focus energy and resources on a few things that are at the top of the list, and starving things that are lower in the list.

The most important aspect of prioritization is the concept of starvation. In the context of prioritization, starvation refers to the lack of attention or resources given to tasks lower down on the priority list. By definition, as we allocate more resources to higher-priority tasks, lower-priority tasks get starved of these resources.

I use the term “peanut buttering” to describe ineffective organizations led by people either afraid of starvation or lacking fundamental prioritization skills. The leaders in these organizations may talk about priorities, but when I dive deep, I discover dozens of “priorities” with resources and energy spread (like peanut butter) across all of them. Their teams regularly complain about being in fire-fighting mode and are unable to distinguish between urgent and important tasks.

World-class leaders and organizations have honed their prioritization skills and are ruthless in driving starvation. The behaviors I see in these orgs include quick decision making, fire-drills being exceptions to the norm, and out-sized results delivered on time. I also see the withering, dead, husks of projects and tasks that were correctly starved along the way being long forgotten.

Tenets for Effective Prioritization (Unless you Know Better Ones…)

1. Customer Value First: Efforts that deliver the most value to the customer should have the highest priority. This tenet ensures that the prioritization process is always focused on customer needs and expectations.
2. Embrace Starvation: Recognize that effective prioritization means some things will be starved of resources. This is not a failure of planning, but a necessary consequence of focusing on what’s most important.
3. Priorities Are Not Set in Stone. They should be regularly reviewed and adjusted based on changing circumstances, new information, or feedback.
4. Limit the List: Keep the list of priorities short. A long list of priorities can lead to a lack of focus and dilution of resources. More than three or four is a red flag.
5. Long-Term Vision: Priorities should align with long-term goals and objectives. Short-term tasks might be urgent, but they should not overshadow efforts that contribute to long-term success.
6. Actionable Now: Priorities should be actionable in the present. If a task is consistently deprioritized, it may be a sign that it’s not truly a priority.
7. Repeat, Repeat, Repeat. A hallmark of great leadership is repetition. Be like a broken record and say, write, and discuss the priorities over and over again, at every opportunity.

These tenets provide a framework for effective prioritization, guiding individuals and teams to focus their efforts on tasks that deliver the most value, adapt to changing circumstances, and maintain a long-term vision.

The goal of prioritization is not to complete every task, but to ensure that the most important tasks are given the resources they need to succeed. This inevitably means that some tasks will be starved of resources, but this is a necessary trade-off in the pursuit of the most important objectives.

I coach leaders and teams on the skills required to be effective at planning and prioritizing. I hold free and open office hours where you can get started.

See Also:

• The 5Ps: Achieving Focus in Any Endeavor
• Tenets

The post No Starving Children? The Shocking Truth About Prioritization. first appeared on tig.log.

The practice of selling ideas in meetings can lead to misalignment and superficial agreement. When the focus is on persuasion rather than understanding, team members may agree without fully grasping the implications or having their concerns addressed. This superficial agreement will lead to problems down the line when the complexities of the idea come to light during implementation.

If the presenter’s goal is to get buy-in for an idea, dissenting voices may be silenced or overlooked. This lack of diverse perspectives can lead to flawed decision-making that hinders innovation.

PowerPoint is a Symptom of Sloppy Thinking

A reliance on bullet points and graphics allows sloppy thinking to be masked by flashy designs. Bullet points, by their nature, reduce complex ideas into oversimplified snippets. This format obscures the underlying thought process, making it challenging for the audience to grasp the full depth of the idea. As a result, the crux doesn’t get debated.

The Power of Written Narratives

The practice of writing narratively structured memos requires the author to articulate their ideas in complete sentences and paragraphs, demanding a higher level of clarity and thoughtfulness. Writing forces the author to engage deeply with the idea, examining it from various angles and anticipating questions or objections.

The practice of team members reading narratively structured memos requires the reader to pay close attention. This leads to a deeper understanding and highlights points of disagreement.

Circulating a memo among a team is fine as it allows each member to process the information at their own pace, reflect on it, and come to the meeting prepared for a meaningful discussion. However, relying on just sending out a memo is never enough. The team members all want to read the memo, but most won’t… because they are too busy dealing with the urgent stuff.

Use the Narrative Review mechanism to ensure the idea is carefully articulated (written), fully understood (read), and diligently debated (bought into).

The Benefits of Debate Over Agreement

Encouraging debate over mere agreement has several benefits:

1. Deeper Understanding: When team members are encouraged to ask questions and challenge ideas, they develop a more profound understanding of the concept.
2. Improved Ideas. You may be brilliant, but the team is brilliant-er. With vibrant debate your idea will be even better.
3. Better Decision-Making: Debate brings different perspectives to the table, leading to decisions that stick.
4. Increased Engagement: Team members feel more engaged and valued when their opinions are sought and considered.
5. Innovation: A culture of debate fosters innovation as it encourages people to think outside the box and challenge the status quo.

PowerPoint presentations and bullet points offer convenience for sure. Convenience is great for things that don’t matter. But getting folks aligned on ideas MATTERS. So don’t be lazy.

Written memos and narratives demand thorough thinking and clarity. Writing them well is hard work. Organizing and running Narrative Reviews is hard work. Excellence in delivering out-sized results requires hard work. Duh.

Don’t try to sell your ideas. Instead, drive people to debate your ideas. The result will be a more engaged, innovative, and effective team.

I can help you learn how. Join me for my Free & Open Office Hours and we can get started.

The post Don’t Sell Ideas – Debate Them first appeared on tig.log.

I was a guest on the “Are We There Yet?” podcast.

We dove deep into several topics close to my heart: The future of life on Earth, artificial intelligence, human-computer interaction, leadership, and more.

Have a listen and let me know your reaction!

Legendary technologist, product visionary, and leadership coach Tigger (Charlie) Kindel winds through the challenges and choices his team made during the early development of Amazon’s Alexa; where AI fits in the continuum of norm-shattering technologies like the printing press and the automobile; and what one supertool can clarify our thoughts like no other technology (spoiler alert: it’s something we can all access right now).

Are We There Yet? | Tigger (Charlie) Kindel on how AI Will Keep Us Honest

The post How AI Will Keep Us Honest first appeared on tig.log.

In 35+ years of building companies and organizations in multiple industries, I’ve concluded most leadership books are great examples of survivorship bias. I’ve learned a lot from many of these books. But none of them really clued me into the secret of what distinguishes teams that consistently deliver outsized results from teams that are just mediocre.

So what’s the secret?

Principles.

Principled leaders have a set of strongly held beliefs in the how (vs the what, why, when, or who) and strive to live those principles.

Even better, organizations that have a written-down set of rules for the how, combined with mechanisms that reinforce the living of those principles, the org sings.

It doesn’t even matter what the principles are. What matters is the org is principled.

If you want your org the consistently deliver outsized results develop these skills:

• Skills for figuring out which principles are the right principles.
• Skills for writing down principles in ways that resonate and create clarity.
• Skills for creating mechanisms and plans that encourage everyone in the org to continuously work at living the principles.
• Skills for remembering that principle is spelled p-r-i-n-c-i-p-l-e and not p-r-i-n-c-i-p-a-l and the word principle is synonymous with tenet (and that is spelled t-e-n-e-t and not t-e-n-a-n-t).

I have mastered1 these skills and love teaching them to others. I’m available to help you and/or your entire organization; see www.kindel.com.

1 Sometimes I still spell tenet tenent. Oops.

The post The Secret to Delivering Outsized Results first appeared on tig.log.

In 2020 started hosting my Free and Open Office Hours as a way to give back and meet more people in the space industry.

As I became useful to those in the space industry and gained expertise in the space domain I discovered how fulfilling helping multiple companies with leadership and operational excellence was. To that end, I have pivoted and made Kindel Leadership Development my primary focus.

Hire me for

• Leadership Excellence – 1:1 and group coaching on skills for effective leadership.
• Operational Excellence – 1:1 and group training on how to deliver products and services customers love, with quality, on time, while having fun.
• High-Performing Team Building – How to foster trust, promote collaboration, and ensure effective communication.
• Organizational Design – Defining structure, roles, responsibilities, and reporting relationships.
• Talent Scaling – All processes from recruiting to succession planning.
• Thinking Big – Create compelling visions that stand the test of time.
• The Written Word – Become excellent at written communication and use narrative-style meetings to drive alignment.
• Virtuous Platforms – Build ecosystems and platforms to create virtuous cycles.
• Acquisition Due Diligence and Integration – How to do it right.
• Intrapreneurial Systems – Innovation and entrepreneurship within large organizations.
• Cybersecurity – Incorporate cybersecurity into products and organizations.
• The Amazon Way – Build and scale organizations like Amazon does.
• Career Guidance and Coaching – How to be a world-class builder of products, businesses, technologies, and organizations.

Learn more and get started here: Kindel Leadership Development

The post Announcing Kindel Leadership Development first appeared on tig.log.

When I was a baby my favorite eldest sister nicknamed me “Tigger” because I was bouncy and acting “Tiggerish”. Friends and family have called me “Tigger” or “Tig” ever since. When I started my professional career I figured the goofy nickname wasn’t appropriate, so decided on Charlie. After 30+ years of not loving being called “Charlie”, I’ve decided to reclaim Tigger as my name.

In the earliest days of email, I signed my emails “-tig”. When I started at Microsoft in 1990 and told people my name was Charlie, I changed my signature to “-cek” in honor of my dad who shared my full name (Charles Edward Kindel). I’m now back to signing using “-tig”.

Call me what you want, but know that when I hear Tig or Tigger it reminds me of who I really am.

Now you know the rest of the story.

The post cek.log -> tig.log (Charlie -> Tigger) first appeared on tig.log.

All human beings are prone to cognitive biases and fallacies that influence our thinking and decision-making processes. These biases and fallacies can be sneaky and hard to detect, but it’s important that we are aware of them and try to minimize their impact on our lives. By being mindful of our biases, we can expand our thinking and consider new perspectives and possibilities.

One way to do this is by looking beyond our own planet and considering the vastness of the universe. There is so much we have yet to discover and explore, and by embracing this sense of wonder and curiosity, we can open ourselves up to new possibilities and opportunities.

Think about it: there could be other intelligent life out there, just waiting to be discovered. Or there could be new technologies and resources that we have yet to tap into. The universe is a vast and mysterious place, and the more we learn about it, the more we realize how little we actually know.

In addition to expanding our thinking, it’s also important to be aware of the biases and fallacies that can hold us back. One common bias is confirmation bias, which is the tendency to seek out and pay attention to information that confirms our preexisting beliefs, while ignoring or discounting information that contradicts those beliefs. This bias can prevent us from considering new ideas and perspectives.

Another bias to be aware of is recency bias, which is the tendency to give more weight to recent events and experiences. This can lead us to focus on the here and now and overlook the bigger picture.

Do yourself a favor and read up on the cognitive biases and fallacies all humans (yes, even you) are prone to. Here’s some resources to get started:

• Cognitive Biases and Fallacies: Definition, Examples & Differences – Think, But How?
• Fallacies (Stanford Encyclopedia of Philosophy)
• Cognitive Bias List: Common Types of Bias

If I ruled Humanity, I’d make studying this topic the centerpiece of our education system.

Practice the skill of being aware of common human biases. Doing so is essential to thinking big (and thinking critically) about the universe we live in, and our role in it. It will make you a better person and a better leader.

The post Biases and Fallacies Lead to Smol Thinking first appeared on tig.log.

Errors. They’re everywhere, but they don’t have to spell disaster. In fact, they’re an opportunity for improvement, if you Engineer the Sh*it out of them. By everywhere, I mean in all functions of a company, not just product or operations.

A hallmark of a world-class organization is a mechanism that treats errors as they should be: imperfections in the systems or processes, not personal failings. One of the most famous is Amazon’s Correction of Errors (COE) mechanism. In a prior role, my team invented an analogous mechanism called EEC: “Engineering of Error Corrections”. The fun thing about EEC was it had a mascot because EEC is pronounced: “Eek!”

Engineering the Sh*t out of Errors is all about rooting out these imperfections and designing and implementing (aka engineering) solutions. It’s not about blame, but about improvement. It’s as much for the finance department as it is for HR or marketing. This is how we ensure our organization, as a whole, continually gets better.

This tried and tested practice should be applied to ALL aspects of a company, not just products and services: Finance, HR, Legal, Sales, Operations, Support, and even Facilities.

Case in point: A candidate was flown in for an interview. Six employees spent an hour each with the candidate. At the debrief it was quickly unanimous that the candidate wasn’t a fit. An error had occurred! We wasted time, and resources, and gave the candidate a less-than-stellar experience.

HR could have pointed fingers, but instead, the HR team turned to the EEC mechanism (Eek!). By asking the 5-whys, they discovered the error lay in conducting only one phone screen. The solution? HR engineered a new hiring process requiring two successful phone screens before an on-site interview.

Why does Engineering the Sh*t out of Errors work? It’s because it focuses on the cause, not the symptom. It helps us take a step back, look at the larger picture, and make changes that affect the system as a whole. It treats errors as what they are: opportunities to get better.

To make Engineering the Sh*t out of Errors more actionable for your organization, consider structuring your error corrections similarly to Amazon’s COE:

1. What happened? Detail the error.
2. What was the impact on customers, the business, and/or the organization? Discuss tangible and intangible effects.
3. What was the root cause? Unearth the underlying issue that led to the error. Ask the 5-whys.
4. What data do you have to support this? Use metrics and graphs to substantiate your findings.
5. What were the implications relative to the organization’s tenets? Evaluate the error’s impact on your organization’s tenets (principles). This can really help ensure the corrective actions you take are aligned.
6. What lessons did you learn? Articulate the insights gained from the error and the subsequent investigation.
7. What corrective actions are you taking? Outline the action items and related items (like trouble tickets) for the solution you’re engineering.

Remember: an error is not a personal failure. It’s a crack in the system that gives us the chance to fortify the whole structure. So, stop blaming and start engineering, even if you’re not in an engineering role.

The post Engineer the Sh*t out of Errors – Everywhere first appeared on tig.log.

According to anthropologist Robin Dunbar, there is a cognitive limit to the number of people with whom we can maintain stable social relationships, which he calls “Dunbar’s number” or “Dunbar’s limit.” This limit is around 150 people.

When organizations grow rapidly and reach about 150 people, it becomes increasingly difficult to maintain the informal communication and social cohesion that enabled success. As fast-growing organizations approach Dumbar’s number, they either become forever mediocre or they adapt and become excellent at scaling (in addition to being excellent at delivering customer value). The key differentiator is making the routine, routine by implementing cadence-based mechanisms, which I call Routines.

Routines are cadence-based Mechanisms that help organizations complete routine tasks and stay focused on their goals and objectives. By implementing Routines organizations improve communication and reduce confusion, creating a more productive and less stressful work environment. Are people in your organization complaining about everything always being urgent? Routines help by ensuring the important things are already on the calendar.

A symptom of an organization struggling with Dunbar’s number is constant whining about “I’m being randomized by such-and-such exec.” In Don’t Make Your Team Say No To You I shared how I was an exec-randomizer myself. I conquered this by implementing Routines that provided “relief-valves” for my crazy ideas; I knew, and the team knew, that there was a time and place for big-ideas and thinking. We should save them up until that time, ensuring everyone else could stay on plan.

For example, as the CTO of SnapOne, I helped the organization scale by driving the adoption of mechanisms that included regularly scheduled events such as meetings, reviews, and publications. One of these mechanisms was “Think Big Month,” which happened in May. This Routine served as a catalyst for the 3-year plan (3YP), which was developed in June/July. The operational plan (OP) for the following year was then worked on in November/December and codified in January. Each of these individual Routines, as well as how they were connected, helped ensure that the organization was always moving towards a clear set of goals and objectives. Because they always happened at the same time each year, they were never a surprise, and let people stay focused on the current plan, knowing future planning was going to happen real soon now.

Another Routine I implemented was the “Programs Review”. In my vernacular, a “Program” is a small organization (no more than about 42 peeps) that delivers something customers will always care about (e.g. Lighting or In-Space Propulsion). Every 2 weeks my staff and I hosted a “Program Review”. We had 9-12 programs, so each program cycled through every 6-8 weeks. This helped ensure that progress was being made on each program and that everyone was working towards the same goals.

Board meetings were another important Routine (that already existed); they were held quarterly and alternated between Salt Lake City and Charlotte. This was a good mechanism for getting leaders that didn’t normally work in person together in a routine way, which helped build cohesion and alignment across a distributed organization.

Implementing these mechanisms helped make the routine, routine, by creating a predictable and reliable framework for getting things done. This helped ensure that deadlines were met and that everyone was working towards the same goals. It also improved communication and reduced confusion, creating a more productive and less stressful work environment.

A business cadence built around Routines can be a powerful tool for organizations that are looking to scale beyond Dunbar’s number. By implementing regularly scheduled events and other mechanisms, organizations can create a structured plan for completing routine tasks, allocate resources more effectively, and move towards a clear set of goals and objectives.

The post Make the Routine, Routine – Blow up Dunbar’s Number first appeared on tig.log.

A friend recently asked me if I had a Lexicon & Taxonomy for Innovation and Invention. While I do, I realized I’ve never written it down. Here’s my first stab; using the Customer, Business, Organization, and Technology (CBTO) mental model. What do you think?

Lexicon:

• Innovation – The introduction of something new or novel that meets the needs and desires of the customer, and aligns with the goals and objectives of the business and organization, through the use of technology.
• Invention – The creation of a new product, service, device, or process that addresses a customer need and adds value to the business, using creative and innovative thinking and technology.
• Creativity – The ability to generate new and original ideas that can solve customer problems and create value for the business and organization.
• Novelty – The quality of being new and unusual, from the perspective of the customer and the business.
• Originality – The quality of being created or produced independently, rather than being copied or imitated, in order to meet customer needs and achieve business and organizational goals.

Taxonomy:

• Incremental Innovation – A small change or improvement to an existing product, service, process, or device that benefits the customer and helps the business and organization stay competitive.
• Radical Innovation – A significant change or a completely new invention that creates a new market or significantly disrupts an existing one, meeting a previously unmet customer need and offering new value to the business and organization.
• Disruptive Innovation – An innovation that disrupts an existing market or industry by introducing a product or service that is significantly cheaper or better than existing ones, meeting a customer need in a novel way, and offering new value to the business and organization.
• Sustaining Innovation – An innovation that helps a company maintain its competitive advantage by improving an existing product or service, meeting evolving customer needs, and maintaining value for the business and organization.
• Open Innovation – An approach to innovation that involves actively seeking out ideas and technology from external sources, such as customers, suppliers, or academic institutions, in order to meet customer needs and achieve business and organizational goals.
• Customer Innovation – Innovation that is driven by the needs and desires of the end-customer (user), rather than by the manufacturer or provider of a product or service, in order to meet customer needs and create value for the business and organization.

This lexicon and taxonomy of innovation and invention provide a mental model for understanding and categorizing different types of innovative ideas and approaches. However, simply having innovative ideas is not enough – it’s important to also have a plan (with tenets) and mechanisms for executing on those ideas to turn them into tangible products, services, or processes. Without proper execution, innovative ideas can remain just that – ideas – and be nothing more than mental masturbation.

The post Breaking Down Innovation & Invention first appeared on tig.log.

Mars has long captivated the human imagination as a potential destination for exploration and settlement. With its rugged terrain and extreme conditions, Mars presents a unique challenge and an exciting opportunity for humanity.

There are several reasons why we should colonize Mars. First and foremost, it would allow us to extend our reach beyond Earth and become a multi-planetary species. This would not only be an exciting and ambitious goal, but it would also provide us with a backup plan in case something were to happen to our own planet.

Colonizing Mars would also provide us with the opportunity to learn more about the Red Planet and its potential for supporting life. By sending humans and robots to Mars, we can conduct scientific research and gather data that could help us better understand the history and potential future of our solar system.

In addition, Mars could serve as a proving ground for new technologies and resources that could be used to help sustain human life in space. By developing ways to produce food, water, and energy on Mars, we could pave the way for longer-term exploration and settlement of the universe.

Humanity has the ability and the responsibility to protect ALL life on Earth, and this includes not only our own species but also the countless other forms of life that share our planet. By focusing on preserving the diversity and vitality of life on Earth, we can ensure the long-term survival and prosperity of our own species as well as countless others.

Recent data shows that the number of deaths caused by natural disasters has decreased significantly in recent decades, which is a testament to our ability to protect life on our own planet. Scientific research and technological innovations have allowed us to better understand the needs of different species and to develop more effective ways of protecting them. For example, advances in veterinary medicine have helped to improve the survival rates of many threatened species, including dogs, which are largely human-created species and an important part of our lives.

It is important to recognize that the quality of life for all humans (and dogs) has never been better, and it is continuing to improve despite all the negative news that we hear. This is highlighted in the book “Factfulness” by Hans Rosling, which points out that many of the problems that we face are actually declining over time.

Ultimately, the decision to colonize Mars will come down to whether we as a society believe that the benefits of such a mission outweigh the costs. While it would be a challenging and costly endeavor, the potential rewards of colonizing Mars make it a goal worth pursuing. Every dog I’ve discussed this with agrees.

The post Why Mars? For the Dogs! first appeared on tig.log.

The photo below illustrates how the torpedo fuses BMW, Mercedes, Audi, Datsun, Porsche, and others used in the 1960s, 70s, and 80s have not stood the test of time. This post dives deep into automobile fuse technology… because I find it fascinating.

Automotive Fuse Types

We take fuses for granted, especially in our cars. The car you drive is likely to have several fuse boxes containing dozens of fuses. It’s rare owners of modern cars ever have to replace a fuse. In the 1960s, Robert Bosch GmbH, a supplier of automotive technology started selling German car manufacturers their Torpedo-style (also known as continental, bullet, European, or GBC type fuses):

During the same time, in Japan, manufacturers such as Toyota used glass tube style fuses like these (my 1978 Toyota FJ40 Land Cruiser has these in it):

The automotive engineers of the time clearly felt these fuses were suitable. However, as the electrical systems in cars became more and more sophisticated, better technology was needed. Sadly, as it turns out, they waited too long to update their designs to something better: The now-ubiquitous blade-style (also called plug-style, type 1081-C, ATO, or Littlefuse) that came along in the 1970s:

Upgrading Classic BMWs from Torpedo Fuses to Blade Fuses

One of the cars I’m the most passionate about is the BMW E28 (learn about my favorite E28, Vlad, here). The E28 is the BMW “5-Series” built between 1982 and 1988. It has the highest Look Back Quotient (LBQ) of any car ever made. It also was the last BMW chassis to use Torpedo/Bosch-style fuses.

Those of us who own E28s really, really wish BMW would have switched to blade-style fuses earlier, as the resulting electrical issues give us no end of grief. Interestingly, the BMW E23 (7-Series from ’77 to ’86) and E24 (6-Series from ’76-89) switched to using blade-style fuses mid-way through their production (September ’86). Why the heck didn’t they do the same thing with the E28?

It didn’t take me long after buying Vlad in 2013 to discover how troublesome the fusebox in E28s was. There’s a great community for these cars, centered around the mye28 forum, and the old-timers were quick to coach me on tips for mitigating the issues. The issues include:

• Fuse holders not holding the fuses tightly, causing intermittent glitches.
• Excessive heat and melting fuse box plastic (we call it “melty”) due to poor conductivity of old and dirty fuses.
• Melting wires throughout the car (e.g. in the headlight switch assembly) caused by fuses that should have blown, but didn’t.

I set about trying to fix the problem at a fundamental level instead of just mitigating it. I wasn’t the first to try, but I’d not seen evidence anyone had succeeded. The leading idea was to retrofit a later model E23 or E24 blade-style fuse box into the E28. The wiring of the E23 & E24 is close to that of the E28 and this sort of upgrade can work. Even though I purchased a brand new E23 fuse box, I never got around to doing the work.

Then, a new guy on the forum posted a note about a prototype fuse box kit he had engineered. His concept was brilliant: Keep the original fuse box, rip out the torpedo-style holders, and slip in a new circuit board that holds blade-style fuses into place. As a bonus, he included LEDs that indicated whether a fuse was blown or not.

I pounced, begging to be a test subject. I soon learned his name was Galahad. We became friends and agreed to become partners, forming a company to build and sell his kits. I’m Chief “Do The Stuff that Lets Engineers Do Magic” Officer and he’s Chief “Do Magic” Officer.

Given his name is Galahad, you probably now see why we named the company Holy Grail Labs. HGL currently sells kits that work on the BMW E12 (’72-81 5-Series), E21 (’75-83 3-Series), E23, E24, and E28 and are working on kits for more BMWs and classic Porsches.

Anyway, back to the topic of automotive fuse technology…

Automotive Fuse Technology Deep Dive

Before the introduction of ECUs, a fuse in a car only had to prevent wiring fires. For wire sizes commonly found in a car, it can take seconds at even very high currents to start a fire, meaning early automotive fuses did not need to be very fast or accurate – they only needed to break the current before the wiring failed. The general specifications for the torpedo fuse reflect this: the rating is a guideline for a minimum current that will pass indefinitely, and they take half a second or more to blow even at dozens of amps higher than the rating.

In practice, torpedo fuses have additional problems. Since the fusing element is completely exposed, it tends to oxidize and increase in resistance. Additionally, the fuse holder design used by BMW loses spring tension over time and the contacts oxidize too, both of which also lead to increased resistance in the fuse system. Increased resistance leads to increased heat, melting the fuse box and degrading the fuse – you can see the thermal discoloration at the end of the blue fuse pictured above along with the melted plastic. It’s very common to find the paper assembly card inside the fuse box significantly discolored around those two fuses even if the box itself hasn’t melted.

The two fuses that commonly have melting problems in E28s are both rated for 25A. However, there’s enough wiggle room in the spec that a fuse could survive 40A indefinitely and still be rated as a “25A” fuse. A dirty torpedo fuse can easily reach 50mOhm, and at 25A the fuse itself is a >30W heater – which goes up extremely quickly with higher than rated currents the fuse will still allow, nearly tripling by the time you reach 40A. Having the equivalent of an incandescent desk lamp for a fuse is dangerous for both your car and you, running counter to the point of the fuse in the first place.

Modern blade fuses were designed to preserve not just wiring but onboard computers, which require much faster and more accurate fuses to avoid damage. The specified tolerances are much tighter and they are specified as a maximum survivable current, not minimum. At 12A a 7.5A rated blade fuse will last a fraction of a second, while an “8A” torpedo fuse could last up to an hour!

In real-world use, blade fuses and their holders are made out of materials that do not oxidize as quickly – if at all – taking care of the main source of unwanted resistance for torpedo fuse. The holders have also been redesigned for both much higher clamping force and to sustain it better, tackling the other major problem area.

Modern fuses aren’t perfect – they don’t instantly trip once you’ve exceeded the limits – but they properly address the major problems inherent to torpedo fuses, and do so in a way that significantly increases system safety.

The post Torpedo Fuses: The Bane of Classic German Automobiles first appeared on tig.log.

Once you get to the point in your career where you realize a) you’ll be just fine financially (because your resume kicks ass), b) your company doesn’t give a sh*t about you, and c) you know what the Right Thing to do is, act like a volunteer.

In 2009 I determined the best way to quickly validate and harden the Windows Phone 7 app platform was to enable Microsoft employees to write apps for it in their spare time. At the time, Microsoft’s policies were designed to scare employees away from working on businesses on the side (called “moonlighting”). This was a stupid policy borne out of a different era and Brandon Watson and I succeeded in changing it and enabling hundreds of employees to build some great phone apps (including BubbleGum by Aarti and Shriram).

Getting the WP7 moonlighting policy implemented is one of my favorite examples of “it’s the right thing to do, and I’m gonna ruthlessly push it through. If they fire me over it, f**k ‘em”. In other words, I acted like a volunteer.

At some point in your career, you’ll realize money isn’t THAT important and that your résumé and network mean you will always be able to find another fun job. This realization won’t come unless you work at realizing it. When it does, you’re partway to being a volunteer.

You’ll also wake up someday and realize no matter how much you bleed Microsoft Green, Amazon Orange, Google Black (?), etc., the company actually is an indifferent autonomous machine that doesn’t care about you at all. This realization will also help you become a volunteer.

You probably started your career with a bit of impostors syndrome and you emulated others as you progressed. At some point, you’ll start to realize YOU KNOW the Right Way. IOW, you’ll become a principled leader. This is the final piece enabling the volunteer in you.

A volunteer can quit at any time. A volunteer only does work because they know it’s Right. Right for the customer. Right for other employees. Right for the World.

Once you adopt the volunteer mindset, you’ll become bold. You’ll become a force for Good change. You’ll eagerly push through the corporate bullsh*t and kick bad politics in the balls. Your work will be more fulfilling.

So, “Be a volunteer.”

(Thanks to my mentor and friend, Chris Phillips, for introducing me to the Be A Volunteer concept back in the day).

The post Be A Volunteer first appeared on tig.log.

In November 2020, I declared I was going to break into the space industry for my next professional chapter.

My hypothesis was my experience rapidly scaling organizations that deliver results, coupled with my expertise in software would be helpful to space companies. The fact that I basically knew nothing about space wouldn’t matter. With the help of a lot of friends in my network, I was quickly connected with dozens of leaders in the booming space industry.

The conversations generally have gone like this:

Me: “Hi, I’m Charlie. I’m a space noob. But I think I have skills that can help you. I’ll give you as much time as you need and all I ask in return is you expose me to your space-specific problems so I can learn.”

Then they’d say either:

1. “Hi Charlie, I’m Sally. I’m a rocket scientist and I can barely spell software. Help!”
2. “Hi Charlie, I’m Fred. I’m a rocket scientist and my startup has grown from 10 people to 80 in the last year and will be over 200 next year. Help!”

I am now regularly talking with seven space-related companies. To varying degrees I’m doing executive coaching, product planning, helping with organizational challenges, debating strategy, and doing introductions to investors.

A few of these engagements have gone so well that I’ve actually been offered formal advisory roles, which is as humbling as it is awesome.

Today, I’m happy to announce STOKE Space Technologies is one of the companies that wants my involvement longer term. I’m now officially on their board of advisors.

STOKE Space Technologies has ambitious plans that will drive a step-change in the rate of launches humanity is capable of. They do this with fully- and rapidly-reusable rockets. The company was founded by several ex-Blue Origin engineering leaders and is located nearby in Kent, WA. I love the fact that I get to actually visit the place where freaking rockets are being designed and built.

The post I’ve Joined STOKE Space Technologies as an Advisor first appeared on tig.log.

Every decade I try my hand at being a videographer. My foot surgery led me to giving Premiere Pro a try (I still hate Adobe UIs).

A test project:

Should I do more garage/wrenching videos?

The post Posting Wrenching Videos first appeared on tig.log.

I’m honored to announce that Rebel Space Technologies has asked me to join them as a Strategic and Technical Advisor.

Satellites need to reliably and efficiently communicate with each other and ground stations in the face of severe spectrum congestion, celestial dynamics (these things and the Earth are always moving relative to each other), and changing mission profiles.

Rebel’s first product is the Rebel Space Radio, which leverages software-defined radio (SDR) technology to allow RF sensors to perform at peak performance in dynamic conditions through data fusion, shared context, and machine learning.

I fell in love with the team, based in Southern California, after being introduced by a mutual friend. The CEO, Carrie, saw the need for Rebel’s products as she drove launch and operations for both the USAF and SpaceX over 20 years. Gabe, the CTO, is insanely smart and has all the expertise required to lead Rebel’s product development.

If you are interested in the booming space industry, you should pay attention to Rebel Space!

The post Advising Rebel Space Technologies first appeared on tig.log.

I’m working on writing down my thoughts on space. I’ve learned a ton since deciding space would be my next mission. Some pretty clear thoughts are forming, and whenever that happens, I’ve trained myself to write, write, and write to really solidify things.

Space is big. In fact, it is, literally, the largest domain. Given the vastness of the domain, I need to formulate a Taxonomy and Lexicon that resonates to gain clarity. I’m a systems thinker, so I first went to the factors that appear to be driving growth in humanity’s investment in space-related endeavors.

I’m sure there’s some confirmation bias here but all the crazy talk and investments going on right now reminds me of what I witnessed in the mid-1990s and the Internet. We used to joke, “The Internet Is Going to Be Really Big Someday.” I’ve been joking recently “Space Is Going to Be Really Big Someday.”

This made me think of and re-read Bill Gate’s Internet Tidal Wave memo from 1994. I decided I’d title my “what’s driving space” memo “The Space Tidal Wave.”

Then I wrote it. As I did, I realized the model floating around in my head mimicked Jeff Bezos’ Amazon Flywheel. So I (badly) drew what was in my mind’s eye:

I then wrote what I meant by the arrows and stuff and was pretty happy. I shared the draft with a few friends and family members, and feedback included a consistent suggestion “You need to explain how a Flywheel is related to a Tidal Wave.”

So I started writing THIS blog post to see if I could.

I couldn’t.

I couldn’t explain the relationship for two reasons:

1. I was mixing metaphors.
2. I was confusing the concept of a singular company’s growth engine, with the dynamics of a broader industry.

I’ve long used the words below relatively interchangeably to refer to either the growth engine of a company or an industry:

• Platform
• Ecosystem
• Flywheel
• Snowball

I’ve always implicitly prefixed these with the word virtuous because, in my mind, they are all synonyms with virtuous cycle, which is defined as:

virtuous circle (noun) · a chain of events in which one desirable occurrence leads to another which further promotes the first occurrence and so on resulting in a continuous process of improvement. Also known as a Virtuous Cycle.

Merriam-Webster

Interestingly, dictionaries don’t include a definition for virtuous that supports its use in this way.

Likewise, I find it fascinating (and frustrating) that no modern dictionary defines platform in how most business people use it. The closest dictionaries come to define an operating system as a platform:

platform (noun) – the computer architecture and equipment using a particular operating system

Definition of Platform by Merriam-Webster

Bill Gates defines platform by saying

 “A platform is when the economic value of everybody that uses it, exceeds the value of the company that creates it. Then it’s a platform.” – Bill Gates

The Bill Gates Line – Stratechery by Ben Thompson

I absolutely love this. Since platform is such an over-used term, and because no dictionary actually provides a definition that fits, most people are just confused about what they mean when they use it (read the Stratechery link above).

In describing Amazon’s growth engine (singular, because initially Amazon only had one), Jeff Bezos used the term flywheel.

flywheel [ˈflīˌ(h)wēl] (noun) · a heavy revolving wheel in a machine that is used to increase the machine’s momentum and thereby provide greater stability or a reserve of available power during interruptions in the delivery of power to the machine.

 Oxford Dictionaries

He drew this, now very familiar, diagram with “growth” in the middle:

When I was at Amazon, leadership regularly talked about how blessed Amazon was to have THREE flywheels: Marketplace (the original), Amazon Prime, and Amazon Web Services. I say blessed because few other big companies have more than one. The advertising engine at Google is Google’s only flywheel today. Facebook only has one as well. I’d argue Microsoft has several (Windows, Office, and Xbox).

Leaders at Amazon are challenged to Think Big and figure how what they are working on might be a FOURTH flywheel. The massive investment in Amazon Alexa is partially motivated by a belief that it may become Amazon’s 4th Flywheel.

snowball [ˈsnōˌbôl] (noun) · a ball of packed snow, especially one made for throwing at other people for fun.

a thing that grows rapidly in intensity or importance. “the closures are expected to have a snowball effect, impacting jobs and tax revenues” · “a public-debt snowball”

Oxford Dictionaries

When I describe a virtuous cycle to folks, I often have to explain what a flywheel is using the flywheel metaphor. I get it; I’m a gearhead and have actually held the flywheels in my cars in my hand as I installed them. But it turns out, a lot of people don’t immediately grok them.

In addition, real world flywheels don’t gain mass over time. They don’t generally have more than one input causing them to turn. Thus the metaphor, when applied to businesses’ (and industries’) growth engines fall short.

Snowball works better, kinda. More people seem to get the idea that a snowball rolling downhill is literally a virtuous cycle (it naturally grows and accelerates as it rolls and attracts more snow). But the problem with the snowball metaphor is a) snowballs don’t keep rolling, and b) when they stop rolling, it’s often because they crash into something.

ecosystem [ˈēkōˌsistəm] (noun) · a biological community of interacting organisms and their physical environment.

(in general use) a complex network or interconnected system.

Oxford Dictionaries

Another oft-used term when discussing virtuous cycles is ecosystem. A vibrant, growing ecosystem is one where the entities in the ecosystem (animals, plants, companies, and/or customers) exchange value with each other to benefit not only themselves but also others.

Often, at the center of a startup’s ecosystem diagram is their product, or the part of their product they think of as their platform.

Back to Bill Gates’ and the memo he wrote in 1994 to give Microsoft a swift kick in the ass: He was not describing a virtuous cycle, but a phenomenon that was happening, happening fast and seemed unstoppable.

tidal wave [ˈtīdl ˌwāv] · (noun) an exceptionally large ocean wave, especially one caused by an underwater earthquake or volcanic eruption (used as a nontechnical term for tsunami).

a widespread or overwhelming manifestation of an emotion or phenomenon.” a tidal wave of crime”

 Oxford Dictionaries

Now that I’ve written all of this, I do believe there is a space Tidal Wave coming. It feels like it’s happening fast, and I am convinced it is manifest. But the memo I’ve written (which I will be publishing soon as a blog post) describes a virtuous cycle. So I won’t title it the Space Tidal Wave after all.

Thanks for letting me rant.

The post Virtuous Cycles, Platforms, Flywheels, Snowballs, and Tidal Waves first appeared on tig.log.

Last Christmas (2019) my daughter gifted me Carv. I fell so in love with the product that I stalked the CEO and begged him to talk to me to see if I could help. I’ve been working with the company since December and last week he asked me to join Carv as a Strategic Advisor.

Initially, I assumed Carv was a gimmick. The abbreviated 2019/20 ski season meant I only got 6 days using Carv, but in that time I was massively impressed. Literally, AS I SKIED, the coaching Carv provided improved my skiing and made me more confident on the slopes.

When the 2020/21 ski season started I discovered the Carv team had been busy improving the product further. Everything was even more refined and the AI-based coaching was clearly more advanced. My ski technique, and thus my confidence, has improved dramatically this season. Using Carv’s own metric, Ski:IQ, my Ski:IQ went from around 120 to a high of 147. And because of the Carv leaderboard I know there are skiers on the planet with scores as high as 167, I’m even more motivated to improve more!

The last time I fell so deeply in love with a gadget was when Amazon released the Amazon Kindle. Reading and sking are both activities deeply rooted in my psyche. Just as my parents loved to read, they loved to ski. Just as I grew up in a home full of books, I grew up in a ski area.

I was probably 3 years old when I last had ski instruction. I’ve read many ski books in an attempt to improve my ski technique and I’m always working on it (every turn!). While I’m a pretty good skier, my technique had plateaued and I was pretty self-conscious about it. I’ve actually been considering hiring an instructor!

Like the Kindle, Carv strikes a very personal nerve for me and I’m excited and honored to be able to help the company grow so more people can improve their skiing!

Check out the Carv website for more details on how it works and order a set today.

The post I’m Advising Carv Because It Improves My Skiing first appeared on tig.log.

Last week I joined my good friend  Den Delimarsky and his colleague Courtny Cotten hosted me on The Work Item podcast.

“In this episode, we dive a bit deeper into Charlie’s approach to product ideation and design, discuss the importance of having a principled organization, and ask questions about his most recent adventure around space.”

Czech it out here (I love that the transcript is available along with the audio): From Servers, Phones, and Voice Assistants to Space with Charlie Kindel

Direct link to the episode on YouTube:

Spotify, Google Podcasts, Apple Podcasts links.

The post From Servers, Phones, and Voice Assistants to Space… first appeared on tig.log.

No, don’t debate excellence; become excellent at debating.

“It is better to debate a decision without settling it than settling a decision without debating it.” – Joseph Joubert

Vigorous debate is critical to clear thinking in an organization. Debates garner the full intelligence of an organization. For decisions of great import, rigorous debate depersonalizes the decision.

People are predisposed to focus on symptoms or minutia. Arguing over extraneous details is inefficient and is often the root cause of the lack of buy-in, indecisiveness, and slowness of many organizations. Debate bar-raisers lead teams to identify the crux of the issue which leads to a deeper understanding by everyone; creating situations where people can successfully Have Backbone, Disagree and Commit.

The Process for Great Debate

1. Disarm. Ensure everyone involved knows it is debate time. Explicitly say “The next 15 minutes will are going into debate mode. Let’s debate this with ferocity!” or ensure it is clear the whole point of the meeting is to debate a topic.
2. Create or identify a starting point. Attempt to state the problem in the simplest way possible; as a skeleton. Plant seeds and then let the team expand.
3. Ask hard questions that would spark debate. Ask an unsettling question. Ask questions that cause the problem to be viewed in a different light (e.g. “What would it take?” or “How hard would it be?”).
4. Demand evidence. The debate will be richest if it is based on facts, not opinions, and it takes foresight to gather the right information (thus ensure people do homework before). “How do you know what you just said is true?” Make demanding rigor the norm.
5. Involve everyone. When leading a debate, explicitly target everyone in the room with a question. See “Disarm” above.
6. Switch positions. Push people to argue the opposing side or argue from a different function perspective.

Debate Gotchas

Here are some things to avoid when driving a debate.

• Avoid sharing your own views up-front. Being a great debater requires a fundamental shift in the understanding of your role. The one leading the debate should refrain from making assertions instead of focusing on just asking great questions (or enabling others to).
• Stop leading the witness! Don’t ask gotcha questions. Don’t ask questions to make a point.
• Don’t attack or criticize the speaker; focus on the idea. For example, don’t say, “Sally, that’s stupid.” Instead, say, “Sally, I don’t understand what you mean by XYZ.”
• Don’t force a decision. Don’t cut off debate. Debating is hard and exhausting. But it is precisely this hard work they are paying you big bucks for. If the topic is important, finding another hour to debate further is almost always the wise choice.

How to Identify What To Debate

Often a team isn’t quite sure what to debate. Or, there’s so much ambiguity that teams find the topic keeps shifting. For example, in the earliest stages of an endeavor (for example, when a startup is formed or a new project is funded), teams may find dozens of topics that need to be figured out.

A great way to break a bigger problem down to create structure and then get to each issue’s crux is to identify and debate a set of tenets. See my post on Crafting Tenets and Debating Tenets for how to do this.

Have you ever heard the phrase “we’re just debating semantics now; this is pointless!”? That’s almost always an indication there is a problem that needs to be debated more. Agreeing on semantics is paramount to gaining clarity of thought!

semantics [səˈman(t)iks] NOUN – the branch of linguistics and logic concerned with meaning.

Creating a clear Taxonomy and Lexicon with distinctive & pithy terms is one of the most powerful ways to drive effective execution. Ensuring folks are bought-in requires teams to debate the definitions. Literally, you want to have debates on the semantics!

Here are some more reads on the power of debate, and how to be more excellent at debating:

• Multipliers, Revised and Updated: How the Best Leaders Make Everyone Smarter by Liz Wiseman
• Debate Tenets by me.

Feel free to use the comments functionality to debate me on this post.

The post Find the Crux by Debating Excellence first appeared on tig.log.

Great leaders don’t let changes happen to them. Instead, they become skilled at driving change. Leaders effective in driving change are known as agents of change or change agents. This post explains a tool called D x V x F > R that will enable you to become a great agent of change.

What does this have to do with Secret Agents? Nothing. It’s just that I am an honorary junior member of the United States Secret Service, and this let me create a pithy title for this post.

The Conditions for Change Formula

D x V x F > R is tool for effectively driving change in organizations. Like most good tools, it is based on a clear mental model with a strong taxonomy and lexicon. The mental model is represented as a formula (D x V x F > R) that reads as:

“The combination of Dissatisfaction, Vision, and First steps must be greater than the Resistance to change in order for the change to occur. Anything multiplied by zero is zero, therefore if Dissatisfaction, Vision, or the First Steps are zero the change will not happen.”

• D (Dissatisfaction) – The level of dissatisfaction with the current situation or state.
• V (Vision) – A vision of the desired state or of a positive possibility; more than the absence of pain associated with the present situation.
• F (First Steps) – The first steps in the direction of the vision; the practicality of the change; or the plan for the change.
• R (Resistance) – Resistance to the change or the cost of changing.

Resistors to Change are Customers

Seek out the individuals in the organization who are likely to be resistant to change (those who increase the value of R). You know who these people are. Don’t treat them as adversaries or enemies. Treat them as customers.

What do we do with customers? We obsess over them. We find out what makes them tick. We understand their pain. Then we adjust our plan to address that pain. Resistance to change is not always bad; it can provide insight into the new Vision.

In other words, actively seek out resistors and focus-group the hell out of them. In my experience, doing so early helps crystalize the Vision and helps identify the First Steps. It also preps them for change.

Inventorying your customer base (your employees, bosses, or other stakeholders) will also enable segmentation which will enable better prioritization of efforts…

Bucketize Stakeholders and Prioritize

Whether the change impacts 10 people or 1,000, it is important to segment the people impacted by the change in order to determine where to focus energy. Using a soccer* analogy, here are the four buckets I’ve used:

• Supporter – These are your season ticket holders who eagerly join the March to the Match. A supporter is already bought into the Vision and is eager to take the First Steps.
• Reluctant – These folks enjoy soccer* and will go to a match if asked but would normally rather watch baseball. Reluctant employees may have mild concerns about the details of the change. But they will fold like a cheap lawn chair with just a little information.
• Non-Supportive – These folks say they dislike soccer. Non-Supportive stakeholders need more information and need to feel like they are being listened to. They account for the majority of Resistance.
• Opposed – These people sit in the visiting team’s supporters section. They see the change as something they cannot tolerate. To them, the change is perceived as a threat to a currently held mental model or they believe the consequences of the change will be intolerable. It’s possible to turn them, but they are usually the folks who continue to oppose the change over time.

Treat each of these buckets uniquely. Prioritize the time and energy you spend thusly:

1. Non-Supportive
2. Reluctant
3. Supporter
4. Opposed

Remember what prioritization means:

“The order in which things get done and the mass applied to each. Higher priority parts of a plan get done first with more people focused on them. Lower priority things get done later with fewer resources applied until higher priority things are done.” – From The 5 Ps: Achieving Focus in Any Endeavor

Build a Coalition

One leader, alone, will never a) expose enough Dissatisfaction, b) create a powerful enough Vision, or c) drive effective First Steps to overcome real Resistance. There must be at least four senior stakeholders in the organization who are in complete support of the change: the change agent and three others (I learned this rule from Qi Lu at Microsoft, and it’s proven true in my experience).

Just as a tech startup will never get its 10th customer without first getting its 1st, a change agent will never overcome Resistance without finding her first coalition member. If the Vision crafted between the first two members is strong enough, invariably a 3rd will be found. And so on…

As the coalition grows and engages, the amount (and flavor) of Dissatisfaction with the status quo will also increase. Likewise, the Vision will become refined. And First Steps will be identified. But the Coalition is not complete until members are added from all ranks. This includes folks way down the org chart in the org. You know who these people are… they are the managers, and individual contributors who you know are adaptable and always want to help (they index high on Ownership). Find them, explain the problem (the Dissatisfaction), and ask them to help. They will.

Do Not Waste Time or Energy on The Opposed. Do enough to discover if the deep differences are perceived or real. Absolutely listen to their concerns (perhaps they have data you don’t have), but don’t waste time arguing or attempting to change their minds.

Involve the people in the coalition in the solution design. If it is “their plan” instead of “your plan” the Vision will be stronger and the First Steps will be more effective. You’ll also have a larger army of communicators (see below).

I have found it enormously helpful to teach the D x V x F > R mental model to potential coalition members. By doing so, everyone has a common framework for communication and thinking.

Repeatedly and Consistently Share the Vision

If you can’t write the vision down clearly, you’re not thinking clearly and you don’t actually have a Vision. So write it down. The 5 Ps can work well for structuring not only the Vision (Purpose and Principles) but also First Steps (Priorities and Plan).

Once you and your coalition are bought into the Vision be ruthlessly consistent about sharing it. Overshare and over-communicate. Become a broken record.

Celebrate Early Victories

Even before First Steps are taken start celebrating even the smallest victories that lead towards the Vision. For example, if there are already people in the organization who are behaving “correctly” give them positive feedback in ways that others can see. Once the real First Steps are taken, make a big deal about any person or team that is in line with the Vision. Send public thank-you emails. Point out great behavior in meetings. Etc…

Celebrating early success in any endeavor is self re-enforcing.  

Just Do It – Take the First Steps

As soon as the Vision is clear and the First Steps are identified, start executing. I’ve found there’s no need to wait until you’ve sufficiently identified all the Dissatisfaction or Resistance to get started.

An Example

When I joined Control4 in 2018 I found that it took up to 4 months to ship new features in the Control4 Smart Home OS. The company’s legacy processes for product quality were mostly waterfall-based and manual testing was required for each launch. A full test pass took upwards of 8 weeks. There was very little automated testing and most engineers couldn’t even spell “unit test”. Clearly, change was needed.

I discovered significant Dissatisfaction within the company on this topic. I interviewed my engineering leaders and dozens of individual contributor developers. Nobody liked how long it took to address customer issues. All of my direct reports, but one, were hungry to change this. They were Supporters. One of my direct reports was Reluctant. It didn’t take long to get him the information he needed to become a Supporter. I also easily found a few IC engineers who were deeply frustrated because they knew the company could do better.

I gave each of these people a tutorial on D x V x F > R and asked them to be part of the coalition. Thus my coalition was formed.

As we dug into the rest of the organization, we filled our Supporter, Reluctant, Non-Supporter, and Opposed buckets up. There were far more Reluctants and Non-Supporters than any others. And there were clearly pockets of folks who thought the status quo was OK; after all, it was how it had always been done. There were a few who were clearly Opposed; I literally had engineers tell me, “I’m an engineer, I don’t write tests.” We ignored those folks; if they couldn’t deal with the change, we’d happily help them find new roles elsewhere (which we ended up doing).

I spent more time coaching team members on how quickly most modern companies can release software. I showed them how good it could be. As I expected, this had a dramatic effect on increasing Dissatisfaction.

Articulating a compelling Vision was simple: “ship new features in weeks instead of months by replacing manual testing with automated testing”. We involved stakeholders throughout the organization by asking each team to define their own version of the Vision (and their own First Steps) that fit their tech’s specifics.

Then I pushed each team to execute their localized First Steps. One team that was already fairly agile just mandated every pull request include unit tests. We very visibly celebrated early victories as teams made progress to further demonstrate to other teams how well it could work.

We didn’t leave it all to the teams. My core coalition of myself and my direct reports took the rather dramatic First Step of getting rid of all manual testers (by either converting them to software engineers or helping them find new roles elsewhere).

Within months, customers started to notice we were releasing faster with higher quality. The change was deep and lasting. The team that builds the Control4 UI components, for example, now has a weekly launch cadence and can launch hourly if needed. The team that built the firmware for Control4’s lighting devices was able to find bugs earlier and further upstream. The company’s engineering organization continues to operate using the mantra “Continuous deployment with automatic rollback.”

Conclusion

Change is hard. I’ve seen change implemented poorly more than I’ve seen it done well. I’ve blown it more times than I’ve gotten it right. But the times when I was effective, I used the D x V x F > R tool.

I am available to do 1:1 or group coaching on driving change and other leadership topics. See Advising, Coaching, and Consulting for details.

See also:

• Everyone’s a Leader
• The 5Ps: Achieving Focus in Any Endeavor

* Yes, it is also called football in some parts of the world, but remember, it was the British who coined the term soccer.

The post How to be a Secret Agent (of Change) first appeared on tig.log.

I exited my last role recently and have been drafting my next chapter.

I have decided to make my new mission Space; specifically getting humanity off Earth. Over the past months, I’ve focused on learning about the space industry’s state and meeting people working on cool stuff. I’m convinced there must be initiatives where someone with my experience and expertise is needed.

I now need to figure out how to ensure folks with such need know I’m available to help. Hence this post.

I have spent most of my life focused on building technology products end-consumers love. Three of my specialties are:

1. Leading large, high-performing organizations with purpose, passion, and extremely high standards.
2. Taking small yet audacious ideas from total ambiguity to reality quickly.
3. Delivering virtuous platform ecosystems.

While I’ve been diving deep into space recently, I’m a space-noob and I’m pretty sure I don’t even know what I don’t know. But, I’ve proven I can master any problem domain.

If you read this and you know of a need, please connect me.

Charlie Kindel | LinkedIn

The post I’m Breaking into Space first appeared on tig.log.

If you are a UX designer, Software Developer, or Product Manager, and you use placeholder text anywhere but where it’s impossible to know what the content will be (user supplied) then you are doing it wrong.

And you are not doing your job.

I learned this from @joebelfiore:

Using placeholder text defers decision making. It’s a cop-out by the person using it and gives reviewers an excuse to also not debate what’s right.

It’s far better to use your really great judgment (you ARE very smart, or you wouldn’t be doing the job) to put your best idea forth. Even if you’re not sure it’s the best idea.

Then, when someone else reviews the UX they will have something to debate (or agree with).

(This was originally a tweetstorm, motivated by @codinghorror tweeting about Ipsum Lorem generators. My favorite Ipsum Lorem generator is: Bacon Ipsum – A Meatier Lorem Ipsum Generator).

The post Do Your Job – Don’t Use Placeholder Text first appeared on tig.log.

Last month I offered “office hours” to anyone who wanted to chat with me. It was an experiment to see

a) if interesting people would reach out,

b) if I could be useful to these people, and

c) if I’d be exposed to domains where I could spend more of my time in the future.

All three hypotheses have turned out true. Thank you to all of you who utilized this so far!

I still have no idea what I’m going to be doing in my next chapter, and I don’t plan on deciding anything soon.

One thing I do know is I’m continuing office hours! *Anyone* can use my FreeBusy Office Hours link to schedule time with me on *any* topic (well, let’s leave religion and politics out of it).

Office hours are FREE (I got feedback that people thought I was charging for this; it surprised me I needed to make this clear).

My only requirement is that you’ve read a few of my blog posts on CBTO topics. I will be changing the timeslots to be in the afternoons because mornings conflict with prime weekday skiing sessions.

Go here to sign-up for Open Office Hours: www.kindel.com/officehours.

The post Open Office Hours with Tig first appeared on tig.log.

Jason Hartman recently interviewed me for Authority Magazine. Check it out.

Homes Of The Future: “The Future Of Smart Homes” With Charlie Kindel of SnapAV

Some quotes:

One of the things that really motivates and drives me professionally and personally, is the idea of how technology can improve people’s lives in their homes…

I realized then that I was doing it all wrong and that everybody around me was doing it wrong and that they were focusing on technology first and trying to build things with the hope people would use them. 

Rule #1 — Start with the customer and work backwards from there. Rule #2 — Everybody is your customer. Rule #3 — There are no more rules.

The post Interview with Authority Mag: Homes Of The Future first appeared on tig.log.

kindel.com has been hosted on my home network since 1996. Today, I finally moved it to a modern web platform. This includes migrating an OG Active Server Pages (pre .NET) & SQL Server app I wrote in 1997 for decoding Porsche option codes

By doing this I finally got to turn port 80/443 off on my home network. It’s been bugging me for a long time because it’s a really bad practice as it makes the home network a target for cyber attacks. But that Porsche Option Decoder app has been so popular for so long that I couldn’t just shut it down.

The new site is hosted as an Azure Static Web App using Hugo. The Porsche Option Decoder was re-implemented as an Azure Function using C# instead of ASP and vbscript. The database is simply a flat JSON queried with LINQ. SQL Server was massive overkill, but I did it that way because I actually built the thing in order to learn SQL.

After being alive with 99.9999% uptime for 24 years www.kindel.com has a lot of inbound links in Google/Bing search results. I’m still tracking them down and building redirects. And I have some theming/formatting yet to do, and some content I know people use is not in place, but it’s basically done. Yay.

Note, I’m talking about www.kindel.com here, not my blog at ceklog.kindel.com; that’s been hosted on www.wpengine.com for many years. They do a great job.

I’d love any feedback on the new site. Comment below or @ me on twitter.

The post kindel.com is no longer at home first appeared on tig.log.

Look Back Quotient (LBQ) is a measure of how attractive a car is to the car’s owner. A car with a high LBQ will increase the car owner’s propensity to look back at their car after parking it.

Examples of cars with high LBQ:

Examples of cars with low LBQ:

The post Look Back Quotient (LBQ) first appeared on tig.log.

It is well understood that no product is perfect and small issues will always exist. Without an ongoing mechanism to fix those issues, not only do they not get fixed, they pile up.

Having a clear Lexicon and Taxonomy is critical to getting large numbers of people moving forward towards a vision. Having the lexicon be composed of terms that make logical sense, disambiguate, and are memorable is important.

Over the years of building many hardware and software products I’ve developed a lexicon and taxonomy for categorizing the issues that exist in products and identifies the mechanisms required to ensure they get the appropriate amount of focus by teams:

• Bugs – These are behaviors in code or hardware that are discovered either through quality assurance mechanisms or by customers. Bugs may be discovered before a product is released (best) or after (always bad, but common). Synonymous with Defect. Typical mechanisms: Backlog reviews, Bug triage, Bug severity and priority, monitoring and alarms.
• Improvements – These are ideas to change product behavior by adding new functionality or changing existing behavior to improve it for customers or increase operational excellence. Typical mechanisms: Backlog reviews, usage telemetry, customer interviews, surveys.
• Technical Debt – Technical Debt describes the parts of technical implementation where shortcuts were taken to get a product to market in a timely matter. Tradeoffs always need to be made across these dimensions. I found this blog post to be a great primer on Technical Debt and the mechanisms teams can use to manage and pay down technical debt. Typical mechanisms: Technical Debt Backlog, Allocating % of every sprint to Tech Debt, Architecture reviews, Principal Engineering Community.
• Broken Windows – A bug, defect, or missing feature directly impacting the customer experience that won’t normally get fixed due to resource constraints. The best examples of Broken Windows are things “we’ve known about forever, but just kept pushing down the priority list.” Broken Windows exist in products, code, packaging, documentation, our bug database, our knowledge management system, etc. Typical mechanisms: Broken Window Goals & Reviews.

I’m writing this today because I’ve recently discovered that I have ignored my own biases when it comes to picking lexicon. When I joined Control4 in 2018 I knew the products I would be responsible for had tons of little, annoying issues. That was not a surprise given they were built by a quickly growing company over many years. What surprised me, however, was the lack focus on continually fixing those issues. Not only had our customers become numb to many of these issues, team members had pretty much given up lobbying to fix them. I made it a priority to change the culture to one where these issues got regular focus and teams were not only allowed to fix them but took pride in doing so.

I defined a mechanism, gave it a pithy name (Broken Windows Mechanism) evangelized it, and then drove adoption of it hard. Each quarter I run a review with our teams where I ask, “show me the broken windows you’ve fixed this quarter”. I started small, asking each team to try to fix just three a quarter; by the end of 2019 we fixed over 300 of these issues across all of our products. Some of these fixes are in code. Some are in documentation. Some are in packaging. But collectively, they add up higher quality products across the board, and a better experience for you. Regular audits of the mechanism and customer feedback show it is working and now, in 2020, we’re well on our way to doubling the number of broken windows we fixed last year. We have more work to do, but these issues no longer get ignored, and the team culture has clearly changed in a positive way.

I started using the term “Broken Windows” in this way while leading the Windows Home Server team in 2007. I believe I was influenced by this blog post by Jeff Atwood (Coding Horror): https://blog.codinghorror.com/the-broken-window-theory/, but I also remember reading about the Broken Window Theory in other places. The image in my mind, when thinking about the “real world” concept of broken windows was a lilly-white neighborhood with pretty little single-family homes, white picket fences, and green grass lawns. This is where I failed, and where I’m now embarrassed to admit how skewed my own worldview is, based on my upbringing. I’ve never lived in a big city. I’ve never lived in the type of neighborhood described in the original research that led to the Broken Window Theory. Until a SnapAV employee pointed it out earlier this week, it did not occur to me this term was contentious and that my use of as a metaphor for a product development mechanism was a bad idea.

I created a situation where I led my company with mechanism that is clearly working to raise the quality of our products by fixing tons of those small issues. But I did so with a “pithy phrase” that not only uses a bad analogy but is highly offensive to some.

From end customers and dealers, SnapAV knows there is significant work to do on meeting core expectations from our existing offerings. Customers often tell us our products are not reliable and have failure points. Partners complain about complex time-consuming installations and flaky solutions. Our products must be even simpler to use, simpler to install, performant, and reliable. This requires investment in identifying more bugs and potential improvements. We’ve been using the term “First Mile” for this effort broadly. For our organization, our First Mile goals compel us to build products that are excellent. Excellent products only come from continual improvements, paying attention to everything, even the little things, that contribute to the overall experience.

Thus, I’m going to ask the team to help change the Lexicon used to describe these product issues to something relatable to “First Mile”. For example, “how do you walk a mile?” You start by taking a first step. Or, “How do you ensure your fitness is good enough to run a mile?” You engage in fitness regularly. What ideas do you have for a new term for “Broken Window” that aligns with First Mile strategic imperative?

This sentence is that last I will write where I use the term “Broken Window” as an analogy for the little issues in products that need regular attention; I’ll let you know what the new term is once the team helps pick one.

The post Broken Windows – Right Idea, Bad Analogy first appeared on tig.log.

Kindel’s 3rd Law – Amazon will enter every existing business, channel, and market. If said business, channel, or market doesn’t already exist, Amazon will try to invent it.

Tig Kindel – 2019

Kindel's 3rd Law: Amazon will enter every existing business, channel, and market. If said business, channel, or market doesn't already exist, they will try to invent it. https://t.co/0rjgapmb17

— Tig (@ckindel) November 16, 2019

See also:

Kindel’s Law – Every payment system eventually becomes an anti-fraud system.

Kindel’s 2nd Law – Companies with a subscriptions-based business model eventually behave in ways hostile to that company’s customers.

The post Kindel’s 3rd Law first appeared on tig.log.

Since the dawn of time I’ve considered the PC (and related devices like Macs, printers, etc…) to be part of my smart home. For some reason, most traditional smart home offerings have treated PCs et.al. as somehow disconnected.

Sometime after the dawn of time (2004), I built MCE Controller (mcec) as a way of ensuring my home PCs could be as tightly integrated as my whole-home audio system or lights. MCE Controller is a little app you run on a Windows PC that enables that PC to be controlled from a smart home OS (via TCP/IP or RS-232). This made tons of sense when we were building Windows Media Center Edition (aka MCE) which basically turned a PC into a glorified DVR.

I’ve continued to refine MCE Controller. Last fall I added the ability to detect keyboard and mouse movement as a way of detecting that someone is in the room. The idea being, if the PC is being used, the room is occupied and the ‘smart’ lights in the room should stay on. Most motion detectors can’t detect fingers flying on a keyboard and thus without this my damn lights would turn off while I was working.

There are other ways of detecting occupancy, of course, but in my experience the best way is to combine multiple sensors that are as context aware as possible. An IR-based motion detector is pretty stupid, actually. So are under-floor pressure sensors. Someday we may have cameras using video analytics too. And microphones (can you imagine?!?). I bet we’ll see devices that can smell people.

But even with all those sensors, the most robust solution will use a variety of sensors fused together. A smart, smart home OS uses “sensor fusion” to actually really be smart.

It turns out combining one or more IR-based motion sensors with a PC “activity detector” works pretty damn well. I’ve been using this at my office at work, my office at my home in Bellevue, and my home office in my apartment in Sandy, UT since last fall and it’s pretty slick. But not perfect.

In the past few weeks of working almost exclusively from home I’ve found more cases where it was not smart, but pretty stupid. For example, when I’m on a video-teleconference (and actually paying attention) I’m not using my keyboard or mouse. I’m also sitting still. So neither the mouse/keyboard activity sensor, nor the motion sensor “sees me”. So the lights go out.

I found myself on conference calls, regularly having to reach out and move the mouse (or wave my arms) to have the lights come back on.

I realized that there’s another PC-based signal that could be added to the mix: Whether my desktop was locked or not. I religiously lock my PC (Win-L on Windows) whenever I get up from it. I was trained to do this at MS and Amazon where co-workers would punk you if you didn’t. So, at least for me “If PC is unlocked, the room is occupied…mostly.”.

Last weekend I updated MCE Controller to detect whether the PC is locked or not. So now, if the Activity Monitor is enabled, MCE Controller signals my smart home every 25 seconds whenever the desktop is unlocked.

It still senses keyboard & mouse activity, but in reality what I’ve really done is made it so the primary signal is whether the PC is locked or not.

You can download and install MCE Controller v2.2 from here: https://github.com/tig/mcec

It offers plenty of connectivity options that should make it easy to integrate with any home control system. I also have a Control4 OS 3 driver that I can provide to folks who ask (use Issues on GitHub please).

The post Smart Home + PC = Better Working from Home first appeared on tig.log.

Mechanisms are complete processes built around a tool, owned by a leader that gets adopted broadly and regularly inspected and improved to ensure things get done, not because everyone has good intentions, but because the mechanism’s elements structurally force the desired behavior.

“Good intentions never work, you need good mechanisms to make anything happen.” — Jeff Bezos

I’ve written previously about how Good Intentions are Never Enough and why mechanisms are needed, but I didn’t go deep into how to make mechanisms actually work. This post rectifies that.

Below are the elements of a mechanism.

Complete Processes

In a complete process, you build a tool, drive adoption of the tool, and inspect the results in order to make course corrections. A complete process has a “virtuous cycle” that reinforces and improves itself as it operates.

Tool

Within the complete process of a mechanism, the tool is the structure that a leader creates to implement large-scale change. The tool is what transforms the set of inputs into a set of desired outputs.

Owned

Each mechanism must have an owner. This is a leader (a human being) who defines, drives the adoption of, audits, and inspects the mechanism. The owner of a mechanism can change over time, but for a mechanism to work, there must be an owner. 

Adoption

Leaders create mechanisms to accomplish things that cannot be done by one person alone. The larger their goals, the more leaders will need to rely on others. Leaders cannot “do” anything without getting others to broadly adopt and implement mechanisms.

Inspection

Leaders need to be able to see if a mechanism is being adopted and to understand if the use of the mechanism is leading towards the desired outputs. Inspection requires leaders to audit the output or results of the mechanism and to course correct and improve the mechanism.

Improvement

(this is where Mechanisms get recursive)

A complete process has a “virtuous cycle” that reinforces and improves itself as it operates. The leader that owns the mechanism, based on inspection and auditing routinely improves the mechanism.

Examples of mechanisms

Here are a few examples of mechanisms.

• The Amazon Andon Cord is probably the most famous example: Andon Cord – How Amazon And Netflix Use Toyota Principles?
• A weekly staff meeting.
• A yearly operating plan process.
• Quarterly Talent Reviews.
• Broken Windows – Right Idea, Bad Analogy
• Operational Readiness Reviews (ORR)

Types of mechanisms

Over the years of designing and driving mechanisms, I’ve found there are multiple flavors. Here are a few common types:

• Make the Routine Routine Mechanisms. Every business has a cycle, and we need to engage on topics regularly. For example, every year, the company needs to go through a cycle of long-term planning, budgeting, and planning for the next year. We define and use mechanisms to ensure these regularly occurring activities are effective and efficient—for example, an annual Operating Plan or Three-Year Planning mechanism. 
• Ass-u-me Mechanisms. The word Assume stands for “make an ‘ass’ out of ‘you’ and ‘me’.” Ass-u-me Mechanisms ensure the right questions are asked at the right times, the right data is presented clearly, and the right people are aware that team members aren’t just assuming something, but they know. I also think of Ass-u-me Mechanisms as Details Matter mechanisms because they can ensure all the little details that might get forgotten surface early and often. Working Backwards Narrative Reviews are an example.
• Audit Mechanisms. An audit mechanism is a system or process that forces details to be surfaced regularly. For example, in a weekly operational excellence review, use a wheel-of-fortune style wheel to randomly select a project each week where the lead must explain their metrics dashboard. This forces every project to be prepared but scales because not every project has to be reviewed each week.
• Behavior Change Mechanisms. A behavior change mechanism can help get results where an organization has underlying behaviors that need to change. A recent example at SnapAV is our First Mile Mechanism. This mechanism enables individuals throughout the organization to take the time to fix little issues that wouldn’t otherwise get prioritized. 
• Anti-Silo Mechanisms. Organizational structure and geography naturally create silos (parts of organizations that become disconnected from the broader mission). A set of lightweight anti-silo mechanisms can mitigate the negative aspects of these natural silos. For example, a Weekly Release Readiness review where representatives from all parts of the org are required to attend makes everyone aware of what products are about to ship while also acting as an Ass-u-me Mechanism.

Employees want to do the right thing. With good leadership, they likely know what the right thing is and even how to do the right thing. However, just knowing what to do and how to do it’s NOT enough to deliver results or drive change. Instead of relying on good intentions, great leaders invent, deploy, and refine Mechanisms.

I have developed an entire curriculum on Mechanisms and am available to teach you or your organization how to be excellent at using them. Learn more: Kindel Leadership Development

Other resources on Mechanisms:

• Good Intentions are Never Enough
• Make the Routine, Routine – Blow up Dunbar’s Number
• Broken Windows – Right Idea, Bad Analogy
• Dive Deep != Micromanaging
• Building mechanisms – Operational Readiness Reviews (ORR)
• Strategy Is a Winding Road. Mechanisms Keep You on Track

The post Mechanisms first appeared on tig.log.

Ever since I started programming on an Apple ][+ in 1981, I’ve had a thing for printing. My earliest apps focused on printing and my first money-making endeavor was “Tapes”, which printed casette tape ‘J-cards’ for all the mix-tapes of great ’80s music we made for the girls. Whenever I learned a new programming language or OS, the first app I’d write was Spit, an app for printing my source code all pretty (it “spits” source code out of a printer). Over the years, I wrote Spit for AppleDOS (Apple BASIC), UCSD-Pascal, CP/M (Turbo Pascal), DOS (8086 assembly and C), VAX/VMS (Pascal and FORTRAN-77), and Mac (Pascal).

In 1988, as a college junior at the University of Arizona (Go Cats!), I decided Windows was going to win over OS/2 and I was going to work for Microsoft. I bought Charles Petzold’s Programming Windows and conned my dad into buying me a copy of the Windows 2.0 SDK (which was like $300 back then!). On my amazeballs ALR 386/33 PC I set about becoming a Windows programmer. The first useful) app I wrote was WinSpit. In a rare moment of adulting, I renamed the app WinPrint and listed it on CompuServe as shareware ($25). For over ten years I received $25 checks the mail from folks all over the world. Even better, WinPrint demonstrated to Microsoft I could actually, really write code. So they hired me.

Several times in the early 1990s I started writing WinPrint 2.0. Each time I had the basics working and realized three things: 1) Nobody cares about printing source code, 3) I’d over-engineered things, and 2) the technology I choose was already dated (e.g. MFC). Two of those abandoned efforts can be found in my GitHub archive here (1992) and here (1994).

Last year (2019) I got a wild-hair to write some code as a way of blowing off steam, and proving to myself I was still cool. It all started with Microsoft releasing the Cascadia Code font. I have a thing for fixed-pitch fonts. It’s weird. Anyway, I installed the font in Terminal and VScode but just looking at stuff didn’t satisfy me. I needed to use the font in anger! So I fixed some long-standing issues in MCE Controller (another app I wrote that nobody uses anymore).

This all led to me re-discovering my old WinPrint 2.0 source code. Reminiscing on how much time I wasted back then, and how effective it was as a procrastination tool, I just had to try again. So I did. And, just to be clear, here’s what I did:

1) I wrote a printing app in 2019-2020. Nobody prints these days. I don’t even print anymore.

2) I over-engineered it. It has a full GUI with print preview. Headers and Footers with Macros. A full command-line interface. It can syntax-highlight over 200 different programming languages. It’s cross-platform. It’s written in C# using the very latest .NET Core. It uses NodeJS and C++ under the covers. And more.

3) I used .NET and C#. Ok, this part I can defend (assuming you get past point #1 and #2): First, I know C# well and it is awesome. Second, no other modern language/app-framework can even SPELL “print”. I tried both Electron and Flutter and both suck when it comes to printing.

So, there you are: I present to you winprint 2.0 (alpha).

I hope you enjoy it.

The post winprint 2.0 first appeared on tig.log.

A Path To Green (PTG) is a clear, crisp, and complete statement describing a team’s plan for getting a project or task from red or yellow status to green.

Organizations that routinely deliver results on time hold individuals and teams accountable for delivering those results. Ensuring everyone is clear on the status of deliverables is key to this. More importantly, teams need to have discipline around how they move projects that are a bit off the rails (yellow), really off the rails (red), or back on rails (green). A Path to Green is a key element of this discipline.

I use the following taxonomy & lexicon for status:

• GREEN : The deliverable is on track with risks that are understood and mitigated. 
• YELLOW : The deliverable has encountered one or more serious unknowns or blockers, and for each, there is a clear Path to Green that should enable the project to hit the current date. 
• RED : The deliverable has unknowns or blockers that either make it certain the date will be missed and/or there is not yet an agreed-on Path to Green. 

A Path To Green Must Include

1. Clear identification of who (as in the name of a human being) is responsible for each action.
2. Dates. Dates. Dates. For every action that will get the project back on track, there should be a date. It’s OK for a date to be a “date for a date”, but it’s NOT OK to not have dates. See Have a Plan (With Dates).
3. Clarity on what the criteria are for determining the project is back to green.
4. If the project is Yellow and trending Red, a clear statement on what criteria (with dates) will cause it to turn red. And a statement of what will then happen (e.g. “If we go Red we will have no choice but to change the due date”).

Examples

Path to Green:

• Work with vendor to resolve issue.
• Verify the problem in the field is fixed.

This is a poor example because

1. There is no identification of WHO is responsible for each action.
2. There are no dates that hold the WHO accountable.
3. There is no clarity on the criteria that will result in the project being back on track.

Path to Green:

1. Sally to get the fix from the vendor to Doug by noon, 04-Feb.
2. Doug to deploy the fix to 10 beta sites by 05-Feb and report results no later than 12-Feb.
3. If results are positive, Sally will update the project to Status to Green on 12-Feb.
4. If negative results come back before or on 12-Feb, we will not have enough time for manufacturing and will have to slip the project launch date by at least two weeks to 01-Apr.

This is a good example because

1. There is no ambiguity around WHO is doing the work and WHEN they will do it by.
2. Clear criteria are provided for what getting back to Green means.
3. Clear criteria are provided for what will happen if s*** continues to hit the fan.

Being diligent about the status of deliverables and getting engineering leaders to think in terms of great “Paths To Green” is key to better execution.

I’m available to work with your team to teach better project management tools and techniques like Path To Green. Learn more at http://www.kindel.com.

The post Path To Green first appeared on tig.log.

Tenets are a few carefully articulated guiding principles for any endeavor. They act as a guide to align on a vision and simplify decision-making. Tenets are the written-down rules that distinguish good behavior from behavior that is not welcome. Tenets simplify and help with being right more often; they can be used as tiebreakers when making tough judgment calls. There is no better way to expose misalignment, and then get aligned, than going through the process of crafting, debating, and codifying tenets.

Tenets are ultimately aligned with an organization’s mission and core values. At the same time, tenets are specific to an endeavor (company, program, project, product, or business area).

Tenets appear at the beginning of narratives, to help ensure that the plan put forth by a team is consistent with its beliefs. Tenets are the “Principle” part of a 5P’s Plan.

There are two kinds of Tenets: Foundational and Aspirational. Foundational tenets describe why your team or product exists and describe its intended value for customers. Aspirational tenets describe how a team or product intends to operate, even if it doesn’t do so today.

Tenets are not written in stone. At Amazon, where Tenets are widely used, they usually include the catchphrase “unless you know better ones.” This reinforces that tenets are evolving. Teams are encouraged to improve their tenets, perfecting them over time, by welcoming input from others, or by learning from writing a narrative or from past decisions that have revealed opportunities for refinement.

I wrote another post on the importance of debating Tenets here.

“You can never spend enough time debating the tenets for a program.” – Jeff Bezos

Tenets for Tenets (Unless you know better ones)

1. Obsess over Customers. Use tenets to focus the endeavor on delivering value to the customer. In a set of tenets, at least one should describe an endeavor-specific principle for delivering value to the customer. In addition, there is value in considering what each tenet (or the tenets as a whole) would look like when framed as explicitly stating a benefit to customers. Customer obsession in tenets helps concentrate effort on what matters.
2. Be Memorable. Being memorable is correlated with effective teaching. Experience shows that the best tenets are memorable. Two attributes of memorable tenets are challenging the reader, and being concise.
3. Be Endeavor-Specific, or more specific than that. Good tenets get people excited about what the team does. People outside the team find that the tenets surprise them and give them insight into the team. The most common tenet-writing mistake is creating a tenet that applies to many teams and communicates virtually no information, such as, “Our team builds scalable systems.” Each tenet should be as specific as possible while not suppressing innovation or excessively violating other tenets such as being durable.
4. Counsel. Tenets help individuals make hard choices and trade-offs. A tenet takes a stand by declaring that a team cares more about one thing than another. Tenets guide rather than prescribe detailed actions; absolutes in tenets are a warning sign in this regard.
5. Each Tenet has Only One Main Idea. Chisel each tenet down to a single essential idea making the tenet memorable and clear.
6. Find a Minimal Cover. Each endeavor operates in a space of ideas – its semantic space. A team’s tenets cover most of its semantic space, using the minimum number of single-idea tenets needed to do so.
7. Orient for the Long Term. A tenet is durable and strategic. It may challenge or affirm traditional mindsets, and cause individuals to work in strategic directions they might not otherwise pursue. Tenets survive multiple rounds of goal-setting, achievement, and failure.
8. A Tenet is not Something to be Done Later. A tenet captures an idea that team members could conceivably apply every day. Tenets are present tense; using the word “will” or “should” in a tenet is common and is almost always a mistake. 
9. Distinguish Rather than Elevate. Tenets capture what makes a team different, not what makes it superior.

Why Write Tenets?

Tenets define culture. Tenets are literally the rules for behavior and as a result, when reinforced with appropriate mechanisms, drive the behaviors of individuals. Without tenets, culture comes randomly. With tenets, culture is intentional and directed.

Tenets get everyone in agreement about critical questions that can’t be verified factually. For example, is it better to be customer-obsessed or competitor-obsessed? It’s hard to gather data and prove that one is better than the other. But specifically choosing that the whole company should be ‘customer obsessed’ helps us work together without re-hashing a nuanced debate for every product. Having tenets at many levels (company, org, team, project) can be used to gain clarity on the critical, unprovable decisions specific to that org, team, or project.

Tenets expose intellectual dishonesty. – It’s easy to get caught up in groupthink or distracted by the nuances of a specific project and lose sight of the overall goals. Stepping back, setting tenets, and then considering those tenets along the way and only changing them when you step back again will help teams keep track of the wider strategy.

Examples of Tenets

The Tenets on Tenets listed above are pretty great examples! The Amazon Leadership Principles are also fantastic (remember Principle == Tenet). Below are more examples.

• Our Products Make Other Products Fantastic. We strive to create fantastic products.  While our products are designed to be competitive and work well standalone, their true value is delivering fantastic experiences when integrated into solutions. 

The above example illustrates a memorable tenet that reminds a team working on a platform they are in the business of bringing other companies’ products together on behalf of the customer.

A similar tenet to the above is the following. In this case, the tenet is more about technical innovation vs. integration:

• We Stand on the Shoulders of Giants. Customer value comes from innovating in how existing technologies are integrated together. We look for opportunities to borrow (and even plagiarize) existing technologies to adapt and avoid the temptation to re-invent (or even invent) the wheel. For example, we would rather white-label a quality device from another company than engineer one ourselves. 

This example was used in the merger of two companies:

• Our Org Structure is Invisible to Customers. We are one company. We have one name. One product group. One sales force. One platform. 

Here, the tenet counsels the team on making trade-offs between customer segments. It’s a tenet that reinforces business-critical prioritization:

• We Prioritize Both End Customers and Partner Customers, but when forced to make trade-offs between one or the other, we are biased toward end customers.

Sometimes an endeavor needs to be reminded of a fundamental aspect of a team’s strategy. For example, this tenet comes from a smart home lighting program where latency and privacy concerns meant a cloud-centric solution was non-viable:

• On-Premise Compute Comes First. Lighting is a mission-critical capability for our end customers and as a result, we choose to invest in on-premise, vs. cloud-based infrastructure for our Lighting products. 

Another program may have a strategic bias towards a cloud-first model. The equivalent tenet would read:

• The Truth is in The Cloud. We simplify our architecture by ensuring there is always a single source of truth for customer data. Because our solutions span the globe, we ensure the single source of truth is in the cloud vs. on-premise.

Below is a whole set of tenets from one company’s plan for creating a patent portfolio:

• Defense is the Best Offense. We use our patent portfolio as a defense against patent trolls and weaker competitors who choose to use patents to stymie innovation or bolster their own revenue. Only in highly considered situations will we use patents as a “sword” asserted against others or to drive revenue directly. 
• Novel, not Numbers. We value a patent portfolio made up of a broad set of real innovations over having a large patent portfolio. Patents are expensive; we judiciously budget and spend on only the highest-quality patents. We are biased towards utility over design and will only apply for design patents in highly considered situations. 
• The Company’s Patent Strategy is our Employees’ Patent Strategy. We have hundreds of highly intelligent, innovative-thinking employees. These employees deserve to have their great work highlighted in the company’s patent portfolio. Identifying and documenting new inventions is an integral part of an engineer’s job description and we provide only modest financial incentives for filing patents. 
• Our Patent Portfolio Models our Global Footprint. The US provides the biggest bang for the buck but we work to ensure our portfolio provides appropriate defense in other important geographies.  

More examples that might not be endeavor-specific enough (because they are so broad), but may also be useful if the purpose of the tenets is to drive cultural change:

• Get Data and Use Data. We make decisions based on data. If we don’t have the data, we invest in measuring. If we can’t get the data, we value anecdotes and our observations.  
• Say, Do, Show. We build plans and we transparently communicate to internal stakeholders. Then we execute against those plans, showing clear progress and results along the way.

I frequently craft and debate tenets for aspects of my personal life. These help me know myself better and reinforce relationships with others (because I share and debate them with the people I’m close to):

• Find Magic and Get Lucky. I put myself in situations where I can say yes to things I previously would say no to. This is how magic experiences happen. Luck is when preparation meets opportunity. For example, I seek travel and adventures that will create opportunities to make new friends. Likewise, whenever in a new city, I seek opportunities to mentor and coach young entrepreneurs.
• Serve at Civilization Scale. I strive to give more than I take. I’ve already taken a lot. I invest my professional energy on problems (and people) that positively impact the future of humanity. For example, I choose to apply my skills and expertise towards space, because it’s the most leveraged way for me to help preserve the precious life on this planet.

Pro tip: Don’t confuse “tenet” with “tenant.” A tenant is someone who occupies land or property rented from a landlord. There is a pronounced second N in tenant, but not in tenet. Likewise, “principle” is spelled p-r-i-n-c-i-p-l-e, not p-r-i-n-c-i-p-a-l.

See also:

• Debate Tenets
• The Secret to Delivering Outsized Results
• Amazon Leadership Principles

The post Tenets first appeared on tig.log.