For forty‑five minutes, we dreamed. We imagined the product our customers would rave about a year from now, and the kind of company we wanted to become. When the buzzer sounded, we shifted gears. The next forty‑five minutes answered a single question: “Great. What do we ship in the next two weeks?”

The format was simple. But the mindset stuck with me.

It invited people to care about both the long arc and the next move. To think like owners. To turn vision into momentum.

That mindset is rare. Even when you try to model it.

The Bias Toward Action (and the Cost of Skipping the Thinking)

We all know what our industry values: action. Move fast. Get feedback. Avoid analysis paralysis.

There’s real wisdom in that. Feedback loops matter. If you're stuck, try something. Learn by doing.

But here’s the question I keep asking. How often does your team step back to ask, “Is this the right next move?” Or do they just run the play that’s in front of them?

Even when you think you’ve built a culture that makes space for thinking, urgency has a way of squeezing it out.

Just this week, one of our most senior engineers told me we needed to take more time to think. I pointed to recent decisions—complex ones—where we had taken the time. I reminded him how our deliberate approach had made key projects possible.

He nodded. “You’re right,” he said. “But that’s not how it feels on the ground.”

What he meant was that his teammates were still pushing for action above all else. They cared deeply about the business and wanted to move. That’s good. But the value of pausing to think and plan wasn’t always sinking in.

That moment reminded me: building a thinking culture is not a one-time act. It’s an ongoing practice. Even when your message is clear from the top, it can get lost in the rhythm of shipping. The pressure to move is constant. The habit of pausing is fragile.

Planning Isn’t the Enemy of Speed

I've spent most of my career working on developer platforms, at startups, at Canonical, at Heroku, at Snyk, and now at Kard, where we’re API-first by design. I’ve lost count of how many times I’ve heard “We shouldn’t overthink this. Things will change anyway.”

And sometimes, they do.

But I’ve found thoughtful design upfront is what buys you flexibility later.

A few months ago, we ran into friction around a particular API design. A new use case didn’t quite fit the structure we had. But because we’d anticipated similar scenarios during early planning, we didn’t have to rip everything up. We had seams. We had context. And we moved forward.

Planning didn’t make us right. It made us ready.

“Plans Are Useless. Planning Is Essential.”

That line’s often attributed to Eisenhower, and it holds up. The moment reality hits, your plans will likely fall apart.

But if you’ve done the thinking—really wrestled with the tradeoffs—you’ll adapt faster and better. Not because you’re clinging to the plan, but because your thinking is already in motion.

Good planning is like packing for a hike. You won’t know every turn in the trail. But you’ll be ready when the weather shifts.

Five Ways to Build a Thinking Culture

Here’s what I’ve found most helpful for bringing deliberate, business-aligned thinking into product-engineering teams:

1. Share the business story. Strategic thinking starts with context. I want every engineer on my team to be able to explain the “why” behind what we’re doing—in plain language. That means regular storytelling, clarity from leadership, and transparency about what’s changing.

2. Make time to think. If you don’t carve out space, urgent work will fill every corner. In my org, we schedule time twice per quarter—individually, in small groups, and with leadership—to step back and reflect on direction.

3. Anchor ideas in business value. Strategic thinking isn’t about sounding smart. It’s about moving the business forward. Whatever your specialty, be a businessperson first.

4. Plan with change in mind. Don’t try to control the future. Instead, plan for it to change. Use scenarios. Design with seams. Agility comes from preparation—not just improvisation.

5. Tie strategy to immediate steps. Big ideas aren’t enough. You’re not done until you’ve answered, “So what do we do right now?” Thinking must lead to action, or it’s just noise.

Closing Thoughts

Think Big, Think Small stuck with me because it does both: it invites vision and demands action. It respects the power of thinking, but doesn’t stop there.

We work in a fast-moving field. But speed, untethered from direction, invites waste. If we want to build products that matter, to customers and to the business, we have to carve out time to think.

See the map. Sketch the vision. Then take the next step.

Subscribe now

Why Startups Resist Career Ladders

At early-stage startups, I've consistently resisted formalizing career ladders. When a company is racing toward product-market fit, survival demands collective alignment. Introducing ladders prematurely can inadvertently shift focus from solving existential business problems to personal advancement. As soon as we codify levels, I’ve seen people sometimes optimize for promotion criteria rather than company needs.

The irony isn't lost on me: career ladders are central to how we communicate our market value. I've personally benefited from clear progression and recognition. Still, deferring structured ladders has often felt right. Ideally, everyone's first responsibility is ensuring the business succeeds, growing a foundation stable enough to support clear career advancement.

The Hidden Costs of Putting People in Boxes

When it's time to introduce structure, I've grappled deeply with the rigidity inherent in traditional leveling frameworks. Career ladders, by design, sort people into neat categories. But humans—especially talented, innovative ones—rarely fit cleanly into predefined boxes.

I often recall an engineer whose impact fundamentally reshaped our company's foundations. His contributions weren't easily captured by traditional "staff-level" criteria emphasizing broad communication. Instead, his influence spread subtly through architecture, code, and mentorship. Recognizing his true impact required difficult conversations and a willingness to challenge our definitions. Eventually, we elevated his role, but the experience revealed how limiting narrow, rigid frameworks can be.

Navigating the Subjectivity of Career Growth

Over years of leadership, I've adopted three key ideas that help balance necessary structure with human complexity.

1. Subjective, Explicitly Imperfect Guidelines

Career paths should openly acknowledge their inherent subjectivity. In R&D, there's often pressure to engineer airtight criteria, eliminating ambiguity. Yet pretending objectivity only masks complexity and creates false expectations. Advocating explicitly imperfect guidelines is uncomfortable but necessary. By openly acknowledging that criteria reflect evolving cultural and organizational needs, we set realistic expectations.

2. Demonstration Before Celebration

Another principle, which I first encountered at Heroku and have adopted widely since, is that promotions should follow sustained demonstration of the new level. "Consistently" is key: one successful project isn't enough. True promotion readiness is evident through sustained performance over meaningful periods.

Waiting can frustrate eager individuals, yet premature promotions rarely serve them or the organization. Promoting too soon risks damaging careers, morale, and trust.

Moreover, what's considered "senior" inevitably shifts as the organization scales. Clear communication about evolving expectations ensures employees understand why standards rise with company growth.

3. Intent-Based, Defensible Decisions

At Kard, my current company, we've adopted intent-based decision-making for promotions, inspired by David Marquet’s leadership model. Instead of conventional promotion committees, our managers explicitly state their intent to promote someone, and are prepared to rigorously explore their reasoning to their management chain and peers. Everyone involved can challenge this intent based on our subjective guidelines and their own direct experiences. HR and peers provide valuable input, but ultimately only the direct management chain has veto power.

Compared to traditional promotion committees, this method significantly reduces political maneuvering, gaming the system, and superficial box-checking behaviors. It has made our promotion decisions more rigorous and fair, even in the face of subjectivity. As a manager, knowing both that my reasoning will face thoughtful scrutiny and that I have agency sharpens my decisions. I prefer the approach and the outcomes of the intent-based model.

Closing Thoughts: Embracing Ambiguity

No system perfectly resolves the ambiguity inherent in human growth. Though clarity is comforting, humans remain inherently complex, and leadership inherently nuanced. Embracing ambiguity doesn't simplify promotions, but it makes leadership more authentic, compassionate, and honest.

How do you navigate the tension between structured growth and human complexity? I'd love to hear your experiences and insights.

Subscribe now

It marked the first time a long-anticipated feature stitched itself together end-to-end. What appeared simple on the surface was actually the culmination of intricate, coordinated effort spanning multiple components, iterations, and disciplines. And when the moment arrived, it landed as joy. We laughed, we celebrated, we showered each other in emojis. There was pride, but more importantly, there was genuine delight.

It reminded me how vital this feeling is: not just for team morale, but as a foundational principle for how I want us to build.

Hidden Joy in Serious Places

Early in my career, I worked extensively in open source, a space known at the time for its rigor, blunt feedback, and uncompromising standards. From the outside, our interactions probably seemed devoid of joy. The mailing lists and issue trackers were full of careful reasoning, precise criticism, and occasional dismissals.

Yet beneath this stern exterior, we were there because we loved it. We were dreamers sharing our work openly, collaborating to build something meaningful for the world. Behind every careful argument, hidden deep in the heart of our code, was an unspoken spark of joy. We rarely acknowledged it explicitly, but it was the secret fuel that sustained our work.

I've learned that joy often hides behind seriousness, not just in open source, but throughout business. Even today, many leaders hesitate to talk openly about joy. You won’t see graphs measuring joy at our board meetings. The business world tends toward skepticism about such seemingly soft ideas, and I understand that caution.

But over time, I’ve grown more comfortable talking openly about joy, because I’ve seen that it doesn’t just serve the people on our teams. It aligns incentives powerfully. Joy is not only good for people; it's good for the products we build and the companies we grow.

Joy as a Strategy

I’ve tried various ways to build teams and organizations, some more successful than others. The one that's proven most powerful—for the team, the work, and ultimately, the business—is building explicitly around joy.

Joy doesn’t mean ease. It isn’t about constant fun or superficial happiness. It’s deeper, more sustainable: the spark of discovery, the satisfaction of shared craftsmanship, and the feeling of improvement in something that genuinely matters. This joy isn’t about obligatory productivity. It's about a genuine desire to return, to build, and to build well.

Pain can teach us, but it leaves scars. I've seen teams drained by repeated stress, suspicion, or blame. Joy, on the other hand, fuels momentum. It creates safety, encourages experimentation, and compounds into resilience.

This is the loop I strive for: not one powered by fear or avoidance, but by joy and the desire to keep building.

What “Hire for Joy” Means

So, practically, what does hiring for joy look like?

It doesn’t mean finding people obsessed with work or who never log off. Instead, it's about seeking individuals who find genuine delight in their craft: curious minds, meticulous artisans, and generous teachers.

I see these signals every day:

• A teammate exploring new AI tools eagerly, playing, experimenting, and enthusiastically teaching others along the way.

• Someone stepping into a new product domain, genuinely owning their work, sweating the details, and raising standards for everyone around them.

• A developer whose deep love for a programming language elevates our standards for clarity and maintainability.

• A designer who injects thoughtful polish into every user interaction, inspiring the rest of us to meet their standards.

These aren't exceptions—they're signals. They shape our culture, our interactions, and our collective growth.

The Cost of Cynicism

If joy isn’t cultivated deliberately, cynicism often takes its place.

I've witnessed talented teams slip into suspicion and blame, where learning only comes from painful breakdowns. These cultures exhaust people, erode trust, and limit growth, no matter the underlying talent.

We can’t eliminate tough moments entirely, but we can choose how we respond. Two simple practices have profoundly changed my approach: stillness and laughter.

Stillness helps me see challenges clearly. Laughter helps me overcome them—not sarcasm or cynicism, but shared, genuine laughter. It opens doors to optimism, which I’ve consistently found to be a more effective teacher than fear.

Closing Thoughts

We spend a third of our lives at work. I choose to spend it with people who love what they do: people who share their curiosity, celebrate their learning, and treat something as small as a well-earned terminal screenshot like a work of art.

Reflecting on my own journey, I've found my most impactful decisions and proudest accomplishments weren’t driven by fear or pressure. They were guided by joy. From those early days in open source to the teams I build today, joy remains the secret strength that quietly propels us forward.

Hire for joy. Cultivate it. Protect it. Celebrate it. Not just because it feels good. But because it works.

Subscribe now

I’ve wondered whether that’s a weakness or a strength. The answer, as with most traits, is both. But the real shift came when I stopped trying to fix it and started learning how to work with it.

When Wanting to Be Liked Gets in the Way

Let’s start with the obvious: being a pleaser can get you in trouble.

You want people to like you. And the truth is, particularly as a leader, that’s never going to happen—not always, and certainly not with everyone. If you base your sense of success or safety on universal approval, you risk trading long-term outcomes for short-term relief.

Worse, people can exploit that instinct, often without even meaning to. Your desire to win someone over can lead you to say yes too quickly, soften necessary feedback, or preserve harmony at the expense of alignment. You can end up undermining your own authority and steering the team off-course.

So yes, it can be a weakness. But it’s also something else.

Why It’s a Superpower Too

Wanting people to like you means… you care. You tune in. You notice what others are feeling. You think about how your words will land, not just what you’re trying to say.

That’s not fluff. That’s leadership.

Empathy builds healthy team culture. Emotional intelligence sustains trust in hard debates. Connection sells vision, internally and externally. When I give coaching to folks on my team, they understand I’m offering feedback because I care deeply about their growth.

In all these situations, being a pleaser has helped me. Not because I was playing politics, but because people can tell when you care about their experience. When you show up with more than arguments and goals—when you show up as a person.

That’s influence. That’s soft power. And it’s real.

What to Do With It

If you’re wired like me—if pleasing is part of your makeup—what does it look like to lead well with that trait?

Here’s what I’ve learned.

1. See It

The first step is noticing. Observe your reactions. Catch the moments when your need to please is driving your decisions. Ask yourself: Am I doing this because I think it’s right, or because I’m afraid of letting someone down?

This kind of self-awareness takes practice. You’re not trying to shut the instinct down. You’re trying to see it clearly enough that it doesn’t run the show.

2. Stretch It

This is the hard part: practice getting comfortable with not pleasing people.

If it’s the right thing to do, let someone be disappointed in you. Let them be upset. Say no, even if it means losing goodwill in the moment.

I still hate it. Every time. But I’ve learned that most people recover, and I do too. And each time, I get better at making the decisions I know I need to make.

More importantly, if pleasing others is your only approach, you’ll find yourself unprepared for moments when that approach doesn’t work. You need other tools. And the only way to develop them is by using them.

3. Own It

Still, don’t disown your strength.

Your ability to connect, to build relationships, to earn trust? That’s valuable. Don’t throw it away just because it’s inconvenient sometimes. Don’t tell yourself it’s immature or unserious.

In past positions, working with finance to align on hiring plans often felt disconnected at best, and constricting at worst. But at Kard, the head of finance and I have both leaned into relationship-building. As a result, creating hiring plans and making other spending decisions feels collaborative, open, and creative. We work together to find the best outcomes for the business, even in tricky situations.

Your instinct to please others is part of what makes you effective. It probably helped get you where you are.

So use it. Hone it. Let it be one of the ways you lead.

Just not the only way.

Closing Thoughts

I’ve come to think of this as one of the core tensions of leadership: working with who you are, even when it’s inconvenient.

Every strength casts a shadow. Every weakness holds the seed of growth. The real work is learning to tell the difference, and then learning to lead anyway.

So if you’re a pleaser like me? That’s okay. Start by noticing. Stretch by doing the opposite. Then come back to your strength with more range, more clarity, and more choice.

You don’t have to be someone else to be a good leader.

But you do have to know yourself.

Subscribe now

Then came the morning I spent staring at yet another thoughtful but firm response to a proposal I had labored over. The feedback was precise and generous. But it landed like a door quietly closing. Something was not working.

That was when I realized the problem was not just technical. It was narrative.

My ideas were not connecting because I could not clearly explain why they mattered. Worse, the way I communicated them—overlong, tangled, buried in implementation detail—often masked weak or incomplete thinking.

This was my first encounter with a surprising truth that would follow me into leadership: precise thinking and compelling storytelling are not opposites. They are interdependent.

From Hacker to Narrator

At the time, I believed good work spoke for itself. Especially in open source, the ethos seemed clear: “If you build it, they will merge it.”

But the reality was more nuanced. Even excellent contributions needed narrative clarity to gain traction. The leaders I admired did not just write better code. They communicated with context, purpose, and vision.

They made their thinking legible. In doing so, they built alignment, trust, and momentum.

Storytelling as Structured Thinking

Eventually, I began to treat storytelling like another form of structured reasoning. Just as I debug code by looking for missing logic or hidden dependencies, I began debugging my communication.

Here is the structure I came to rely on:

• Context: What is happening right now?

• Catalyst: Why is change needed? Why now?

• Exploration: What have we tried? What have we learned?

• Call to Action: What should we do next?

• Desired Outcomes: What will success look like?

If I could not fill in these pieces, I probably was not ready to persuade anyone, or even to make the decision myself.

Make Me Care

Pixar chief creative officer Pete Docter recalls a narrative commandment he learned from fellow filmmaker Andrew Stanton: “Make me care.” The audience, not the author, decides whether the story matters. Their goals, fears, and context are the soil in which any idea must take root.

I learned this the hard way. More than once, I submitted a carefully crafted open-source patch, only to discover the maintainer didn’t even want the feature. Progress came when I framed changes in language that matched the project’s ethos and immediate priorities. When I showed I understood the community’s context and aspirations, my proposals landed. And even when they weren’t accepted, my voice earned credibility for the next time.

“Make me care” is also Sales 101. My dad spent some of his career in marketing and sales, and he taught me that the conversation always starts with what the customer already values.

In business, the customer is often the business itself. When I coach teams to practice business‑aligned autonomy, I’m really asking them to tell stories that reflect the company’s goals. What’s the catalyst? What problem are we solving? What beliefs guide our choices? Where do we want to end up?

Structure helps. But story and audience are inseparable. If you haven’t earned the audience’s care, structure alone won’t save you.

Strategy Is a Story

As I moved into broader leadership roles, storytelling became essential far beyond the pull request: customer roadmap reviews, board decks, investor conversations, team realignments, crucial one‑on‑ones.

Tools like Wardley Mapping or Crucial Conversations aren’t just frameworks. They’re narrative scaffolding. They help you sequence context, catalyst, options, and outcomes.

The goal isn’t polish. It’s clarity. And clarity creates motion.

Coaching with Narrative

Today, I coach my teams of engineers, PMs, designers, scientists, and operators to think narratively. When they propose a feature, advocate for a change, or navigate conflict, I ask:

What is the situation?

Why does it matter now?

What have you tried or discovered?

What exactly are you proposing?

What will be different if we do it?

This discipline sharpens communication. More importantly, it sharpens thinking.

Closing Thoughts

Strong leadership is not just about making good decisions. It’s about making your thinking accessible and meaningful so others can follow, align, challenge, or build on it.

If your proposals are falling flat, don’t just rework the message. Debug the story underneath. And make your audience care.

What story are you telling today—and who needs to care enough to build it with you?

Subscribe now

They start listing off all the ways that kind of thinking has led to shoddy decisions in the past: rushed features, broken systems, half-baked ideas that never had time to mature. To them, "business value" smells like short-termism. It feels like a disdain for strategy, for product health, for long-term bets that matter.

I get it. I’ve seen the same messes.

But I also think we need to have a deeper conversation. Because when I ask for business value, I’m not asking teams to ship low-quality work fast. I’m asking them to hold themselves to a higher bar: to understand and articulate why the work matters, and to ensure that we’re delivering that value continuously, even when the value isn’t a shiny new feature.

For me, business value means anything that moves us forward in a meaningful, demonstrable way. That includes features. But it also includes de-risking work, internal efficiency improvements, and visibility that helps others operate more effectively. The trick is seeing it, and prioritizing well.

Three Cases That Challenge the Frame

Here are three scenarios where business value feels ambiguous:

1. Internal inefficiencies.

These include developer friction, brittle data models, unreliable environments. But they also show up across the business: finance teams struggling with inaccurate revenue attribution, GTM teams stuck with outdated dashboards, or support teams lacking tools to resolve issues quickly. These inefficiencies don’t ship features, but they cost us time, morale, and momentum.

2. Big long-term projects.

Some work is clearly valuable but takes months or years to deliver. The team might have a vision, but nothing to show for a while. That disconnect can create anxiety, misalignment, and missed opportunities.

3. Experimental or uncertain work.

Research, data science, and first-time explorations often have ambiguous timelines and outcomes. It’s hard to promise deliverables—and harder to tie them to value.

Two Reframes That Help

When teams struggle to show value, I lean on two principles:

Efficiency is business value.

Internal teams are customers too. When leaders can’t see progress, when support has to build manual workarounds, when GTM can’t iterate quickly—that’s a business cost.

Developer friction, data issues, inefficient workflows—all of these create invisible drag. If fixing the platform saves hundreds of hours or improves quality in a measurable way, that’s business value. It just doesn’t always look like a launch.

De-risking is business value.

Uncertainty is expensive. If no one knows whether a project will take three weeks or three years, product can’t plan, sales can’t commit, and leadership can’t align.

But if you say, “In four weeks, we can validate the direction or eliminate the biggest unknown,” you’re delivering something powerful: clarity.

There are levels to this:

1. Best de-risking: Deliver real value that creates feedback on the riskiest part of the work—direction, feasibility, or viability.

2. Second-best: Deliver adjacent value that increases confidence, even if not central.

3. Third: Deliver a working vertical slice that proves integration and flow.

At Kard, we recently did some ML analysis on our transaction data. The long-term vision is customer-facing, but uncertainty was high. So we delivered early results to our GTM team. They used it for sales and reporting, and gave us expert feedback that sharpened our direction. It moved the business directly forward—GTM had a powerful new tool—and indirectly, by shaping our path to the future. That’s business value.

And not all de-risking delivers equally. If de-risking is your framing, then you need to prioritize accordingly: Is the end goal worth the effort? Is this the best way to reduce uncertainty? Will it generate reliable feedback on the most critical path? If not, the value might not justify the investment.

(I talk about how I approach this in a previous post: Face the Risks First.)

Closing Thoughts: Still a Pain (With Purpose)

This is why I push for business value at least every few weeks. And in many cases—especially in customer-facing work—I expect to see it much faster. Some teams deliver value in days. Sometimes even hours. That’s not always possible, but it’s a worthy target.

If you’re doing customer-facing work, deliver something useful sooner. If it’s internal work, show how it removes friction. If it’s experimental, prove it helps us see more clearly.

The worst case is work that delivers neither value nor learning. That’s churn, not progress.

But when every team can say, “Here’s what we delivered, here’s who it helped, and here’s what it unlocked next”—that’s when R&D hums.

I’ll always be a pain about incremental customer value. That’s where the deepest leverage is. But I’m also ready to back off—if the team shows that it’s delivering real efficiency or clarity.

Business value is bigger than features. But it still has to be real. If we can see it clearly and deliver it intentionally, then even in uncertainty, we’re building momentum, confidence, and trust.

That’s value worth shipping every time.

Subscribe now

But very quickly, I also saw something else: we were already operating at real scale. Hundreds of requests a second. Billions of purchase transactions analyzed over time. Real infrastructure costs. Real performance and reliability needs. High customer expectations, measured against competitors who had a different product but served the same need. We weren’t just building something new. We were already running a commodity platform.

That realization sent me back into FinOps spreadsheets, tracking cloud costs by hand until we adopted an automated tool. It also reminded me of my work at Heroku, Snyk, and Canonical, where platform leadership meant sitting squarely between two poles: the need to standardize, scale, and commoditize infrastructure, and the parallel need to enable and drive rapid innovation.

That tension has never really gone away. And I’ve come to believe that for R&D leaders—especially in fast-moving fields like software—the most important skill isn’t picking one side of the spectrum. It’s learning how to move between them.

Three Modes of Progress: Explorer, Villager, Town Planner

Simon Wardley offers a model that captures this movement well. In a 2023 post, he describes three archetypes that align with different stages of product evolution: the explorer, the villager, and the town planner.

• Explorers thrive in the earliest phases of discovery. They map unknown territory, test ideas, and take risks. Think research labs, prototypes, greenfield projects.

• Villagers stabilize those discoveries. They bring them to market, build customer-facing products, and refine the experience.

• Town planners industrialize. They turn products into reliable, low-cost utilities. They optimize, standardize, and scale.

These roles map well to product maturity: from invention, to differentiation, to commoditization. And they map well to organizational behavior too: from loose, agile experimentation to systematized, high-efficiency operations.

What resonated most for me wasn’t just the stages—it was the people. Wardley suggests that different people are energized by different modes. Some folks love ambiguity and chaos. Others prefer clarity and control. Some thrive on invention; others on execution.

I’ve often found myself most at home between explorer and villager. I love the early sense of possibility, and I love the moment when an idea becomes real and begins to delight customers. But I get itchy in environments focused solely on squeezing out cost.

Six Types of Genius: Energy, Burnout, and the Project Lifecycle

Patrick Lencioni’s 6 Types of Working Genius adds a valuable layer here. He offers a different framing of work energy, mapped to project lifecycles rather than product lifecycles:

• Wonder: sensing potential or pondering possibility

• Invention: creating solutions

• Discernment: evaluating ideas

• Galvanizing: rallying people to act

• Enablement: supporting others to move forward

• Tenacity: pushing to completion

Lencioni’s insight is that each of us gets energized by some of these stages and drained by others. You might be great at galvanizing, but if it wears you out, you won’t want to live there forever. You might be good at tenacity but find it boring. Or you might get your spark from invention and lose energy when you have to manage execution.

This model gave me language for something I’d long intuited: leadership often means living outside your zone of genius. As we grow more senior, we become responsible for the whole project lifecycle—not just the parts that energize us. That means building teams that complement us, yes. But it also means developing a broader range of fluency.

Leaders Need to Live in All Three Phases

So how do these models connect?

To me, Wardley and Lencioni are describing two lenses on the same truth: innovation requires movement. Not just the movement of ideas from fuzzy to obvious, or projects from start to finish—but the movement of people. The best leaders are shape-shifters. They move between roles.

You can’t just be an explorer. If you never learn to scale and optimize, your wild ideas won’t survive long enough to matter. You can’t just be a town planner either. If you never cultivate curiosity or reinvention, your beautifully efficient system will get disrupted by someone else’s crazy new idea.

And you can’t just outsource the parts you don’t like. That’s a recipe for blind spots, or brittle teams. Instead, leaders need to stretch.

At Kard, we build a rewards infrastructure and demand platform. It connects issuers (like card companies or budgeting apps, who supply access to purchasers), merchants (who fund rewards to drive lift and loyalty), and consumers (who benefit from the rewards). It’s a triple-sided marketplace, and it lives in all three stages at once:

• Explorer: New models of loyalty. New redemption formats.

• Villager: Great developer experience. Clean operational handoffs.

• Town planner: Infrastructure efficiency. Enterprise scale.

I can’t pick one and ignore the others. I can notice which ones bring me energy, and where I need help. But I have to show up for all of them.

Closing Thoughts

If you work in software, you probably live in all three phases too. Even when your product is mature, your go-to-market may be in flux. Even when your infra is optimized, your data model might be evolving. And even if you love one part of the work, the rest still matters.

So ask yourself:

• What kinds of work energize you?

• What kinds of work drain you?

• Where are you being asked to stretch?

• Who on your team thrives where you struggle?

Then step back and look at the full map. Not just where you are now, but where your product—and your people—need to go next.

Innovation isn’t a destination. It’s a terrain—one you navigate again and again. And leadership means learning how to move across it, with curiosity, rigor, and energy.

Subscribe now

Wardley maps are a strategic framework for visualizing how components of a system evolve over time and how they serve specific user needs. I first encountered them at Canonical in the late 2000s, where they framed the company’s very successful move into the cloud. Since then, Wardley maps have become one of my go-to tools for making sense of complex systems and driving innovation.

If you’re new to Wardley maps, start with this 6-minute video. It’s the best quick introduction I’ve found. For a much deeper dive, Simon Wardley’s open-source book, Wardley Maps: Topographical Intelligence in Business, is a foundational resource—though I’ll admit I’m still working through it myself!

At their core, Wardley maps place components of a system on two axes.

• Visibility (Y-axis): How visible a capability is to a given user.

• Evolution (X-axis): Where the capability is in its evolution, from genesis to custom-built, productized, or commoditized.

A classic example maps a tea shop’s components: kettle, tea leaves, electricity, and more. Each component is placed based on its visibility and maturity, with dependencies drawn between them. This simple structure helps reveal where to innovate, invest, or optimize.

Applying Wardley Maps to R&D Leadership

Over the years, I’ve used Wardley maps in the way I see them most often advertised: to frame and iterate on strategic product decisions. Mapping user needs against available capabilities often highlights gaps where innovation can thrive. These maps also serve as a collaborative tool, making strategic context accessible to stakeholders and encouraging alignment.

But their applicability is much wider. Here are four other ways I’ve found them valuable.

1. Build vs. Buy Decisions

Mapping components helps clarify where innovation matters most. For highly visible or early-evolution components, building in-house often makes sense. For mature, commoditized needs, leveraging off-the-shelf solutions can free resources for higher-value work.

In one case, mapping a product revealed that a custom-built capability was invisible to users and well-covered by existing solutions. Adopting an off-the-shelf product let us refocus on more strategic, user-facing innovation.

In another instance, we mapped a key component that was highly visible to users and early in its evolution for our company but well-established in the marketplace. Investigating further, we found our custom solution better fit our use case and became a valuable differentiator, worthy of deeper investment.

2. Team Organization and System Architecture

Wardley maps are a powerful tool for structuring teams and services. Drawing on Team Topologies, I’ve used maps to align team boundaries with user needs and system components for fast flow of work.

One reorganization effort relied on lightweight mapping to iterate on personas, jobs to be done, and component groupings. The maps served as a visual tool for team conversations and helped frame the final strategy. The clarity they provided contributed to one of the smoothest and most effective reorganizations I’ve led.

3. Delivery Expectations

Wardley maps remind us that different phases of capability evolution require different goals. Early-stage innovations demand flexibility and speed; mature systems prioritize efficiency and reliability. This mindset has helped align internal and external expectations for polish, cost efficiency, and delivery speed across diverse contexts.

4. Career Guidance

Similarly, reflecting on the patterns associated with different Wardley evolutionary phases has helped me identify that I particularly enjoy the early and growth stages. As a leader, we have to be conversant with all of them—more on that next week!—but I have found it to be a useful model in shaping my own career.

Closing Thoughts

Wardley maps don’t prescribe answers. They reveal the landscape, helping leaders make informed decisions.

As R&D leaders, our work spans interconnected domains: product, engineering, data, operations, security, infrastructure, and more. Wardley maps remind us that even in mature or commodity areas like infrastructure, opportunities for innovation exist. Scale, reliability, and security aren’t just operational concerns—they’re customer experiences.

This is what excites me about innovation leadership: managing the entire space while focusing on the areas that create the most value. Wardley maps are one of the tools that help me do just that.

If you haven’t explored them yet, give them a try. Start small. Map a decision you’re grappling with and see where it leads you. And if it resonates, I’d love to hear how you use them.

Subscribe now

A big customer opportunity comes in, but they need a feature we don’t have yet. It’s close—just a tweak to the roadmap, a small adjustment, nothing our team can’t handle.

The customer agrees to buy, if we can deliver by a set date. It’s a great deal.

So we commit.

And then we do it again.

And again.

Each deal might feel reasonable in isolation, but over time, this cycle can radically reshape how the business operates. You stop selling the product you have and start selling what you hope to build under pressure. Product strategy shifts from intentional to reactive. Engineering is locked into fixed-time, fixed-scope commitments that create risk and friction. And the product roadmap becomes less about vision and more about meeting the next deadline.

Why Sales-Driven Deadlines Feel Like a Good Idea

The instinct behind these commitments isn’t wrong. Sales teams want to close deals. R&D teams want to build valuable things for customers. Leadership wants growth.

In small doses, deadline-driven feature commitments can be strategic. If the timing aligns and the feature is directionally correct, it can accelerate the business. When you're still seeking product-market fit, it might even be an ideal way forward.

The problem is when it becomes the default.

When sales can only sell future features, it creates a cycle of dependency.

1. Sales commits to features that don’t exist yet.

2. R&D scrambles to deliver.

3. The next deal requires another urgent build.

4. R&D never catches up, and product strategy gets shaped by near-term demands instead of long-term vision.

This is not product-led growth. This is reactive execution, where customer urgency—not product direction—defines what gets built.

The Hidden Costs of Always Selling the Future

At first, this approach feels productive. The team is moving fast, customers are happy, and revenue is growing.

But behind the scenes, tradeoffs pile up.

1. You’re always in fixed-time, fixed-scope mode.

   • Iteration, exploration, and adjustment get harder.

   • Quality and innovation suffer.

2. You can’t invest in foundational improvements.

   • Refactoring, technical debt management, and long-term architectural shifts decrease.

   • Delivery becomes slower and more expensive.

3. You create strategic debt.

   • The roadmap stops being intentional and becomes a rolling list of sales commitments.

   • The product becomes a collection of rushed, deal-driven features rather than a cohesive system.

And then there's the worst outcome of all.

4. Your team burns out.

Operating at 100% capacity, all the time, with constant deadlines is unsustainable. Without strategic slack, there’s no space to recover, think deeply, or plan ahead.

A Better Balance: Selling What You Have, Exciting Customers for What’s Next

The alternative isn’t “build in a vacuum.” It’s balancing near-term customer needs with long-term product strategy.

1. Sell what you have.

   • Instead of leading with what’s missing, anchor on what’s already great about the product.

   • This builds confidence and reduces dependency on future promises.

2. Excite customers about what’s coming next.

   • Product roadmaps should be a reason to buy, not a reason to wait.

   • Show them the direction, but don’t commit to urgent delivery unless it’s truly strategic.

3. Reserve deadline-driven work for the right moments.

   • Use it sparingly, for high-leverage opportunities that truly accelerate the business.

   • Default to flexible, product-led execution instead of sales-contingent delivery.

4. Maintain slack to sustain momentum.

   • Slack isn’t wasted time—it’s what allows teams to absorb shocks, solve hard problems, and invest in scalable improvements.

   • A team running at full capacity with constant deadlines can’t think ahead, and reactivity kills long-term strategy.

Closing Thoughts

Fast-growing companies face real pressure to deliver. We’ll always need to balance sales, product, and execution. That's especially true at the start of a product's journey. But if every major deal depends on a feature that doesn’t exist yet, the business is running on borrowed time.

Selling the product you have, while making customers excited about what’s coming, creates momentum without constant fire drills. It lets R&D operate at peak effectiveness instead of just scrambling to hit the next date.

And it builds a company that grows strategically—not just reactively.

Have you experienced this sales-driven deadline cycle in your business? How have you managed the balance? I’d love to hear your thoughts.

Subscribe now

It’s not just an org chart question. It’s an architecture, product, and strategy question. Conway’s Law has proven true in my experience: the systems we build mirror the communication structure of the teams that build them. The way we structure our teams directly shapes our architecture. That architecture, in turn, shapes our product over time — either enabling or constraining our long-term strategies.

Because team design is so important, I’ve written before about principles for making cross-team collaboration work. This post builds on those principles, sharing the tactical approaches I use when designing the team structures themselves.

Here are six tactics I rely on.

1. Take your time

I’ve yet to see a situation — either as a leader or an IC — where an urgent reorg was the best way to solve an immediate crisis. There are almost always faster, less disruptive ways to address the issue at hand. Reorgs are long-term moves that deserve deliberate, strategic thinking.

That’s why I recommend taking your time. Understand your business, your people, your opportunities, and your customers before you start rearranging teams. Thoughtful changes are more likely to stick — and more likely to deliver the results you actually need.

2. Start with your customers (and their customers)

When you are ready to rethink your org, start with your customers. Deeply understanding who they are, what they need, and how they experience your product should drive how you shape your teams.

At Kard, we’re a B2B company, so our direct customers are businesses — merchants and rewards issuers. But our thinking doesn’t stop there. Those businesses have customers too: cardholders shopping at those merchants or earning rewards from those issuers. The needs of our customers’ customers directly shape how we organize our teams.

This perspective — treating end consumers as key participants in our own value stream — helps us design better team boundaries and responsibilities. It’s easy to accidentally optimize your org for your internal systems. It’s much better to optimize for the customers you’re trying to serve.

3. Map the value stream starting with customer needs

This customer-first mindset naturally leads to the next tactic: map your value stream starting from the customer’s need, not your product’s current structure.

This is where product thinking comes in. Customers don’t care about your internal teams or architecture. They have a problem, and your product hopefully solves that problem better than the alternatives they can find.

If you map your value stream starting with that need — and follow it through to the product and systems that deliver it — you’ll get a much clearer sense of where value is created and where it’s at risk. This focus on customer needs is at the heart of the “jobs to be done” mindset, and it’s a powerful lens for organizational design.

At Kard, for example, card issuers aren’t buying a rewards platform because they want rewards. They’re buying a way to keep their cardholders happy and loyal. Rewards are just the tool. Keeping that end goal front and center helps us design teams that directly contribute to the outcomes our customers actually care about.

4. Bring in your architects early

Once you understand the customer needs and have mapped the value stream, it’s time to bring in your architects.

This is where Conway’s Law becomes intentional instead of accidental. Your org design is also a design for your future architecture. The teams you create and the boundaries you draw will influence how your systems evolve for years to come.

At Kard, I rely heavily on our staff engineers to help with this. They have the technical depth to see the tradeoffs between flexibility and cohesion, between independence and reuse. I like to work with a small group of trusted technical leaders to shape the initial design, then get broader input once we have something solid to react to.

The goal isn’t just a map of how things work today. It’s a vision for how they could work tomorrow.

5. Empower your product platform teams

This next point is critical, and it’s one I’ve seen too many teams skip. Your platform teams — specifically, your product platform teams — are the connective tissue between your customer-facing teams. They deserve intentional design and real empowerment.

At Kard, I distinguish between two types of platform teams:

• Product platform teams own the custom-built infrastructure that connects our product teams. They build the pipelines and shared systems that let product teams work independently while contributing to a coherent whole.

• Developer experience (DX) teams own the guardrails and automation that make day-to-day engineering easier, like infrastructure as code, CI/CD pipelines, and developer tooling.

Here, I’m talking about the product platform teams. These teams need to be empowered to own and evolve the cross-team architecture. They need to understand the customer needs and product goals driving that architecture, and they need the authority to make changes when necessary. At the same time, their goal should be to push as much ownership as possible to the customer-facing teams, keeping only the parts that require cross-team coordination.

The best product platform teams balance these two forces: centralizing only what’s necessary, and decentralizing everything else.

6. Design for cross-team contribution

This last tactic is one I’m particularly excited about right now. It’s easy to design team boundaries that look clean on paper, where each team owns a product surface, a customer journey, or a technical service. But real-world value delivery is rarely that tidy. Teams inevitably need to influence parts of the product they don’t directly own.

Rather than fighting that reality, design for it.

At Kard, we’re leaning into this with explicit plug points between teams. One example: our merchant team defines how offers should match transactions, but that offer-matching logic runs in a system owned by the loyalty experience team. Rather than requiring code contributions across teams, we use Open Policy Agent (OPA) and Rego rules to let the merchant team define their offer logic directly — no pull request required.

This kind of architecture, where teams build for cross-team contribution, speeds up delivery, reduces coordination overhead, and preserves team autonomy. Whether you use OPA, plug-in systems, configuration files, or something else, the goal is the same: make it easy for teams to contribute to each other’s work without bottlenecks.

Every org design is a bet

None of these tactics guarantee success. Every org design is a bet on your customers, your product, your team, and your future. But these approaches — taking your time, starting with customer needs, mapping the value stream, involving architects, empowering platform teams, and designing for cross-team contribution — have served me well across multiple companies and stages.

I’d love to hear how you approach team design in your own organizations. What’s worked for you? What’s surprised you? What’s still an open question? Let’s compare notes.

Subscribe now

At three different companies, I’ve watched GTM teams move fast by standing up automation in Salesforce. Sales and finance define how the business runs, but their models only tell part of the story. R&D often gets left out—we slow things down, or they want to move independently. But in any growing company, the edges eventually meet. Product connects to billing. Data powers marketing. Systems cross. Boundaries blur. And when those boundaries don’t align, everything gets harder.

At one company, Salesforce billing boxed in product design. At another, a brittle sync caused platform changes to trigger billing incidents. At Kard, when Salesforce work kicked off again, I paused. Not because I didn’t trust the team—I did. But I’d seen what happens when disconnected models start to compound.

That’s when it hit me: R&D couldn’t just build the product. We had to help build the shared understanding that surrounded it.

I didn’t always think that way. At Heroku, finance reached out to me and showed how platform changes could block billing—and how small misalignments could ripple across the company. At Snyk, I saw how misaligned platform and billing models slowed everything down, and I started getting involved earlier. At Kard, it’s been a priority for me from day one: connecting R&D to GTM, finance, and Salesforce. Right now, we’re working across four departments to align how we categorize merchants—by vertical, purchase cadence, and price positioning—so that onboarding, reporting, and analytics all speak the same language.

That shift reframed how I think about R&D’s role. We’re not just product builders. We’re the bicycle for the business: the tool that brings balance and acceleration. Balance, by aligning how teams understand the product and the customer. Acceleration, by helping the whole company move faster and with less friction.

Balance: R&D as the Keeper of Shared Understanding

One of the core ideas in domain-driven design is that software should reflect a clear, shared understanding of the business domain. That’s a great starting point. R&D should work with domain experts to develop models that reflect how customers see and interact with the product.

But inside the business, there isn’t just one model. There are many.

• Sales has a model for how they sell.

• Finance has one for billing and forecasting.

• Marketing has one for segmentation and positioning.

• Operations and support model delivery and troubleshooting.

Even a single stakeholder may switch models depending on context. This is where R&D can lead—not by owning every model, but by fostering alignment between them.

• We listen across functions. R&D works with every part of the business, giving us a unique vantage point to spot misalignment.

• We understand tradeoffs. We know which models fit the product’s architecture, which can be represented in data, and which might confuse customers.

• We normalize and translate. We help build a shared core vocabulary that teams can map their specific needs onto.

When R&D plays this role well, we avoid years-long debates over pricing models, positioning, or product fit. When we don’t, those debates often drag on and slow the company down.

Acceleration: R&D as a Partner in Efficiency

The second way R&D multiplies its impact is by improving how the business works—not just what it builds.

R&D teams aren’t just product builders. Ideally, we’re the company’s best builders overall: experts at understanding complex systems, diagnosing bottlenecks, and designing solutions. We do this for customers every day. We can apply the same thinking to internal work.

That makes R&D a natural partner to operations teams, helping to design more efficient, scalable processes. We bring three key capabilities:

• Tools and methods. Flowcharts, value stream maps, process diagrams, and design thinking are just as powerful for diagnosing inefficiencies in sales, onboarding, and support as they are in product.

• Systems thinking. Engineers, designers, and product leaders naturally think in systems, not silos. This helps R&D rethink cross-functional processes, designing out inefficiencies rather than just automating them.

• Automation capabilities. R&D can often build lightweight internal tools, integrations, or automations faster and more effectively than any other team.

As a business scales, these capabilities matter more. Fragmented systems and inconsistent processes become growth bottlenecks. They also make it harder for R&D to build products that fit cleanly into the wider business ecosystem.

R&D doesn’t need to own every internal process, just like we don’t own every business model. But we should partner with operations to design better ways of working—using the same skills we bring to product development.

Closing Thoughts

R&D’s role evolves as a company matures. Especially once product-market fit is within reach, our value extends far beyond the delivery pipeline.

• By driving alignment around the models that describe the product, customers, and business, we help every team—from sales to finance to marketing—work from the same shared understanding.

• By partnering with operations to design scalable processes, we help the entire business move faster, with fewer handoffs, less confusion, and greater confidence.

This is what it looks like when R&D becomes a bicycle for the business: balanced, efficient, and built for long-term momentum.

If your R&D team has taken on this kind of role, I’d love to hear about it. What helped you create shared understanding? Where have you improved how the business itself works—not just the product?

Subscribe now

Safe. Harmonious. Comfortable.

I was wrong.

What makes us effective in one context can become a liability in another. For me, that’s been true with empathy and conflict resolution. I have a strong ability to pick up on subtle social cues and anticipate friction. And when I sense conflict, I feel an instinctive need to resolve it.

That instinct helped me build collaborative teams. It also got in my way.

When Harmony Backfires

Early on, I gravitated toward leadership principles that promised harmony:

• Psychological safety

• Blameless retrospectives

• Protect your team

• The No Asshole Rule

They reinforced what I felt deep down: good leadership should keep things safe, smooth, and free of unnecessary tension. So I leaned in. I created safe spaces. I shielded my teams. I built warm, supportive environments.

And I made some critical mistakes.

We avoided necessary conflict. We operated in silos. We created a bubble of comfort that kept us from engaging fully with the hard realities around us. My teams weren’t growing as fast as they could have—not because they lacked capability, but because they weren’t being stretched.

Safety Isn't Comfort

Growth requires stress.

It’s a fundamental leadership lesson—one I learned the hard way.

Muscles, bones, minds, and organizations all grow through tolerable, managed stress. And it’s our job as leaders not just to create safety, but to foster the right kind of stress—the kind that leads to growth.

That’s when I realized I had misunderstood what those principles were for.

They weren’t the destination.

They were the gear.

Used well, they don’t help us avoid danger—they help us face it.

• Psychological safety → Make it safe to say dangerous things.

• Blameless retrospectives → Analyze the system objectively so we can face emotionally tricky problems with clear eyes.

• Protect your team → Shield them from distractions so they can focus on the real challenges that move the business.

• The No Asshole Rule → Don’t tolerate people who create pointless discomfort, because real discomfort takes energy to handle.

These tools don’t exist to make things easy. They exist to make it possible to do hard things well: to grow, to adapt, to innovate.

The Discomfort Toolkit

The hardest conversations in an organization aren’t about product direction or technical choices. They’re about flawed strategies, broken processes, hiring mistakes, and personal missteps. They’re about surfacing buried tension, reconciling opposing viewpoints, and rethinking long-held assumptions.

What makes these moments so difficult is that they challenge our competence, our judgment—and sometimes, our sense of identity.

So how do we build the muscle to step into that kind of danger?

Here’s what I’ve learned about creating productive discomfort:

• Start with facts. In both public and private discussions, begin with shared, observable truths. Get grounded before interpreting.

• Critique the system first. When something goes wrong, talk first about how the system, process, or environment contributed to the outcome. This reduces defensiveness and increases learning.

• Critique people privately, with empathy. When individual feedback is necessary, deliver it directly—but do it with care, clarity, and in the right setting.

• Know your own defaults, and model better. If you tend to avoid conflict, lean into it. If you’re blunt, practice softness. Seek out hard feedback yourself. Your team is always watching.

Closing Thoughts

In climbing, you don’t rely on gear to make the mountain easier. You rely on it to make hard routes survivable.

The same is true in leadership. Our tools—psychological safety, feedback norms, personal reflection—don’t make the work less demanding. They make it safer to do the hard, growth-producing stuff.

Self-awareness—of ourselves and each other—is another form of safety equipment. It gives us the footing to have real conversations, the harness to take a fall and recover, and the confidence to keep ascending together.

I’ve worked on teams that surged ahead by tackling hard problems—and on teams that stagnated because they avoided them. No system is perfect, and no leader is either. But the strongest teams aren’t the ones that sidestep difficulty.

They’re the ones that step into it—together.

Where do you see unnecessary comfort holding your teams back? What safety practices allow you to take meaningful risks?

I’d love to hear what you’ve learned.

Subscribe now

“Simplicity is prerequisite for reliability.” — Edsger W. Dijkstra

Several years back, I worked on a team full of extraordinary people—some of the best I’ve ever worked with. The company was making money, customers were happy, and yet… the best folks were quitting.

Why? It wasn’t that anyone was malicious or incompetent. It was that no one could tell what to do. Smart, principled leaders were pulling in different directions. Their ideas were all reasonable—but they didn’t cohere. There was no shared goal, just a complex tangle of overlapping needs, plans, and incentives. As an advisor told me at the time, a team of leaders works toward a common goal. We just had a collection of them.

The problem wasn’t people. It was complexity.

As leaders, we make decisions that impact our teams, customers, and businesses. We like to think we’re right. But the reality is, we’re only right a lot—not always. That’s Amazon’s leadership principle: leaders “are right, a lot.” Not always. A lot.

Mistakes happen, not just because we lack information, but because many decisions are harder than they need to be. The world is full of unnecessary complexity, and complexity breeds confusion, errors, and slow execution.

This is where Dijkstra’s insight applies: simplicity is a prerequisite for reliability. When we work hard to make simple easy, we reduce the likelihood of making bad decisions.

Why Simplicity Matters for Leaders

We tend to blame bad decisions on poor insight or intelligence. But often, the real culprit is complexity itself—too many interdependencies, unclear priorities, tangled incentives, opaque systems.

Consider Hanlon’s Razor: “Never attribute to malice that which is adequately explained by stupidity.” In an organizational setting, we can take this further: never attribute to individual failure that which is adequately explained by a complex, brittle system.

If we want better decisions across the board, we need to stop expecting people to navigate unnecessary complexity flawlessly. Instead, we should simplify the work itself.

Simple vs. Easy

In software engineering, Rich Hickey’s 2011 talk Simple Made Easy defines three useful distinctions:

• Complex: Intertwined, braided together.

• Simple: Unmixed, clear separations of responsibility.

• Easy: Convenient, nearby, familiar.

We see this in engineering all the time. A well-designed API is simple: it defines responsibilities cleanly and avoids entanglement. A tangled monolith might be “easy” to change at first, but over time, changes become harder, risks grow, and reliability suffers.

The same is true in leadership. If we don’t work to make simple easy, then what’s easy will often be complex. Decisions will be burdened by silos, unclear ownership, and ever-growing dependencies.

How to Make Simple Easy

Here are a few ways I actively simplify.

• Clear alignment between customer needs and company goals reduces decision friction.

• Product plans that align internal and external incentives simplify trade-offs.

• Transparent priorities reduce ambiguity about what matters most.

• Financial transparency makes business decisions easier to reason about.

• Work-in-progress (WIP) limits prevent tangled, competing efforts.

• Vertical slices of work help teams ship focused value instead of sprawling, cross-cutting projects.

• APIs (both internal and external) enforce clean separations of responsibility.

• Autonomous teams with self-service deployment tools minimize reliance on others to make progress.

• Organizing teams around value streams clarifies ownership and accountability.

• Using Team Topologies patterns (and related principles) prevents teams from getting stuck in unnecessary dependencies.

Each of these reduces unnecessary complexity. None of them make hard problems disappear, but they help teams focus on the right complexity: the real innovation, the valuable risk, the work that moves the business forward.

Closing Thoughts

I’ve worked in environments with and without these simplifications. No system is perfect, and I’ve never implemented them all at once. But each one has helped make my job simpler—and my team’s decisions more reliable.

When we simplify, we don’t just make life easier. We make organizations smarter. The goal isn’t to remove all complexity, but to eliminate the unnecessary complexity so we can focus on the valuable complexity.

We’ll still trip and fall. But we’ll be “right, a lot” more. And that makes all the difference.

Where do you see complexity creeping in—either in code or collaboration? What’s one place where you’ve made simple easy? I’d love to learn from your examples.

Subscribe now

The company was called Zope Corporation. We were a Python shop, back when Python wasn’t mainstream. It was still the language of the curious. You didn’t learn Python because a bootcamp told you to. You learned it because you were exploring what was next in computing. And that’s exactly why we used it.

Our 30- or 40-person startup included much of the original PythonLabs team: Guido van Rossum, Tim Peters, Barry Warsaw, Fred Drake, and more. These were the folks shaping the language. I was a junior developer—but I was surrounded by people inventing the future of programming. And our CTO, Jim Fulton, was clear about what kind of engineer we wanted.

We didn’t hire Python developers just because we used Python.

We hired them because they were curious.

They thought critically about tools. They wanted to know what else was possible. They were already exploring the future before it arrived. That mindset was our competitive advantage.

Lately, I’ve been thinking a lot about that mindset—especially as the industry rushes to adopt LLMs.

AI Can Write, But It Can’t Wonder

I’ve spent a lot of time lately working with tools like GPT, Copilot, Cursor, and Aider. The productivity gains are real. But what bothers me isn’t what the tools do. It’s what they don’t.

These models are incredibly good at democratizing knowledge. If you want to spin up a GraphQL API or scaffold a frontend, they’ll give you something that works. Sometimes, it’s even good.

But ask them to design a nuanced security architecture with cascading roles? Or to create a novel pagination strategy in Go? Or to decide whether GraphQL is even the right choice?

They flail.

Not because they’re unintelligent. Because they don’t reason. They remix. They don’t understand. They autocomplete. And they certainly don’t learn—not like we do, through experience, evolution, and integration over time.

LLMs are powerful. But they’re static. Even with retrieval-augmented generation (RAG), we’re just cramming more facts into the context window. We’re not enabling growth. We’re stacking more knowledge into a frozen frame.

So yes—LLMs are excellent at accelerating the known.

But they’re poor companions for exploring the unknown.

What Happens to New Languages?

Here’s the part that really worries me.

If I were inventing a new language or paradigm today, I’d be concerned. Unless I have the resources to fine-tune an LLM, my innovation is invisible to the dominant tools developers now rely on.

I’ve seen this firsthand.

In TypeScript, the LLM and I move fluently. In Go, I can ship, but it’s not second nature. When I ask an LLM for help in Go, the depth thins. The model avoids generics. It leans into older patterns. It misses the modern idioms.

And if I’m trying to build something truly new? It’s barely any help at all.

The model can’t guide me because nobody has guided it. It only knows what it’s been taught.

And that’s a problem.

We risk ossifying the status quo—not because it’s better, but because it’s overrepresented in the data. LLMs privilege popularity. That’s not a technical failing. It’s a community risk—unless we stay intentional.

The Return of the Curious Engineer

That brings me back to Zope.

We didn’t know it at the time, but we were preparing for a future where curiosity would matter more than credentials. That future is here.

Yes, we’ll still hire engineers who can glue standard components together. That work matters. AI tools will help them go faster.

But every business that scales eventually hits problems that aren’t in the training data.

Problems that demand invention.

Problems that require people who wonder.

When we hit those walls, we need engineers who do more than prompt.

We need engineers who ask better questions than an LLM ever could.

The Software Boom Isn’t Slowing Down

Some say LLMs will reduce the need for developers. I think they’ll increase it.

This is Jevons paradox in action: when something becomes cheaper or easier to use, demand for it increases. As AI makes software faster to write, we’ll build more of it—more systems, more tools, more ideas turned into code.

So yes, we’ll need more people. But not just any people.

We’ll need developers who understand the business deeply, who can wield AI tools with confidence and care.

And we’ll need developers who are curious. Who aren’t satisfied with remixing what exists. Who are already thinking about what’s next.

Closing Thoughts

We’re not done inventing.

If we want to keep pushing the boundaries of what’s possible in software, we can’t just optimize for productivity. We have to keep hiring for curiosity.

So if you’re leading an R&D team right now, ask yourself:

Are you hiring people who can follow the path?

Or people who can build the next one?

Because LLMs can follow. But only the curious still build the future.

Subscribe now

My first career in music seemed to embrace that freedom: creativity! No boundaries! But it turned out music is filled with systems and models, both intuitive and explicit, that help us create and interpret. My second career, first in programming and then in leadership, showed me that models can also support efficiency and fairness.

I learned to appreciate models not as prisons but as tools: simplifying complexity to help us act faster and better. George Box said it best: “All models are wrong, but some are useful.”

But I’ve learned—hat tip to —that some are also attractively wrong: misleading in ways you might not notice at first. Here’s how I categorize models today.

1. Entirely wrong. Just bad. Avoid these. My examples include fixed mindsets and managing innovation from fear.

2. Attractively wrong. Maybe fun at first, but dangerous over time, like a playground in a construction zone. These models demand vigilance. My examples include “10x engineers,” and ORMs.

3. Usefully wrong. Models that simplify reality in ways that let you work faster, think smarter, or deliver better outcomes. These are the keepers. My examples include Wardley maps and Lean.

I hope this model is usefully wrong for you. Let’s explore how to make it work.

Three Lessons for Evaluating Models

Here are three principles I use to navigate the world of wrong models.

1. Understand the Trade-offs. No model is perfect. Ask: “What risks does this introduce? What doesn’t this account for?” For example, Wardley maps excel at strategic context, but they don’t tell you when the next change will happen, or what you should do next. If someone’s selling you a model without caveats, they’re probably selling something else, too.

2. Focus on Outcomes. Models are tools. Their job is to help you achieve better outcomes. If a model isn’t working—like when an ORM slows down your system as complexity grows—revise it or let it go.

3. Evolve and Adapt. No model lasts forever. Stay curious, keep learning, and be ready to tweak or toss even your favorite frameworks as the world changes.

Closing Thoughts

The more I’ve worked with models, the more I’ve learned to appreciate their imperfections. Models simplify complexity, but the world is always bigger than the boxes we draw. The trick is to use them thoughtfully, stay aware of their limits, and know when to step outside the lines.

What’s the most usefully wrong model you’ve encountered? How did it help you succeed despite its flaws? And have you ever been burned by an attractively wrong model that seemed perfect at first?

Subscribe now

But alignment is in tension with continuous improvement. Organizations must evolve their processes, tactics, and even foundational elements like strategies and principles. When we push for adherence to guidelines, are we leaving space for the organization to adapt and grow?

And there’s another tension at play: rules can clash with expertise. Senior team members often see when “breaking the rules” achieves better outcomes. Overemphasizing rigidity may stifle your most valuable contributors.

Navigating these tensions is challenging but essential. Here are four approaches I’ve used to balance alignment with flexibility and make space for something better.

1. Sell Stories, Broadcast Rules, Coach Principles

I’ve seen organizations struggle when they underemphasize any of these tools.

• Stories and rules without principles: Clear rules and vivid success stories provided guidance, but without principles, senior contributors didn’t know when or how to bend the rules. Localized rulebooks emerged, leading to inefficiency and frustration.

• Principles and rules without stories: Broad principles and reasonable rules were clear, but the missing stories left the “why” behind the organization’s vision untold. Execution became fragmented without a cohesive narrative.

• Principles and stories without rules: At times, I’ve underinvested in rules, leaving teams to work harder to find direction. Paradoxically, this lack of structure also made growth harder: clear rules provide fast feedback and a foundation to build on.

Now, I treat all three—stories, rules, and principles—as essential leadership tools. Stories inspire and align. Rules provide clarity and efficiency. Principles connect the two, offering guidance on when to adapt.

2. Demonstrate Safety to Disagree

A few years ago, I observed master mediator Diane Musho Hamilton lead a divisive conversation. She began by taking a controversial position, surprising and even offending participants. This move created space for others to express their perspectives, showing that disagreement was not only welcome but essential.

As leaders, we can create similar safety by modeling openness to dissent. One technique I’ve used is the “rule of two”: when presenting a proposal or inviting feedback, I include two meaningfully different, valid options. By framing multiple possibilities, I encourage discussion and signal flexibility.

This practice has been invaluable in contexts where teams felt boxed in by leadership opinions. It opens the door to innovation and ensures diverse perspectives are heard.

3. Foster Experiments

Some questions can’t be resolved through discussion alone. When disagreement persists or uncertainty remains, I encourage experiments. Experiments show openness to change while driving action.

I’ve found it especially valuable to let a small team or group of experts lead these efforts. These individuals are often curious, empathetic to the current situation, and trusted to evaluate outcomes. If the experiment succeeds, they can advocate for broader adoption.

Design experiments thoughtfully to ensure success.

• Define clear questions.

• Manage risks appropriately.

• Set reasonable budgets and timelines.

• Provide measurable results.

Poorly designed experiments can waste time, money, and trust, but simple, well-structured tests often build alignment and confidence.

4. Bring Important Questions to Conclusions

When I watched Diane Musho Hamilton facilitate that divisive conversation, she didn’t just open space for disagreement. She guided the group toward resolution. With perspectives laid out, she rebuilt trust and helped participants align on a path forward.

As leaders, we must do the same. Whether through experiments, discussions, or feedback loops, it’s critical to bring important questions to a conclusion. Set explicit timelines for experiments or debates, clarify decision ownership, and ensure the team commits to the outcome.

I’ve also found that emotional attachment to specific outcomes can stall progress. Before concluding, listen carefully to those who feel strongly, helping them empathize with alternative views. Use one-on-one conversations if needed to address concerns and build understanding.

Closing Thoughts

One of my strengths as a leader is caring deeply about what we do and how we do it. I love to dream and create together, aligning teams around shared goals. But in the past, I’ve held on too tightly to visions, strategies, or tactics, limiting opportunities for growth.

A mentor once advised me not to “grasp.” They encouraged me to hold ideas lightly, with both conviction and curiosity, ready to adjust or let go entirely in the face of new insights. This advice resonates deeply with me. It reminds me that while alignment and guidance are critical, so is fostering the wisdom and adaptability of the team.

Continuous improvement requires more than just words. It demands actions that demonstrate openness to change and diverse perspectives. By balancing stories, principles, and rules; fostering safety to disagree; encouraging experiments; and driving resolution, we can lead teams that are both aligned and adaptable.

How do you navigate the tension between alignment and flexibility? I’d love to hear your thoughts.

Subscribe now

No. If your team holds retrospectives, writes READMEs, creates operational playbooks, or uses Loom to share workflows, you’re already generating and managing knowledge. Even automating away the need for knowledge counts as knowledge management. It’s foundational for scaling efficiently and staying lean.

I’ve often seen leaders underinvest and under-think in this space. Why? Because the business value of knowledge management isn’t always clear, and poorly defined business drivers lead to low-impact initiatives. I’ve experienced this firsthand, like when a well-intentioned push for Backstage delivered less than we’d hoped, largely because we hadn’t put the business story first.

To address this challenge, I’ve found it helpful to break knowledge into three types—explicit, implicit, and tacit—and align management strategies with the business goals for each.

Three Types of Knowledge

1. Explicit Knowledge

Straightforward, factual information.

• Examples: Glossary definitions, system architecture guides, deployment pipeline instructions, or customer journey maps.

• Strategy: Write it down in shared, searchable locations like Notion, code repos, or Salesforce. Retrieval-augmented generation tools like Notion AI excel at leveraging this type of content efficiently.

2. Implicit Knowledge

Processes, frameworks, and practices learned by observing and doing.

• Examples: Diagnosing issues in an operational dashboard, using a design system effectively, or knowing how to use a detailed tool.

• Strategy: Use Loom videos or detailed guides to capture and share this knowledge. For high-value areas, consider workshops or interactive classes.

3. Tacit Knowledge

Intuitive understanding and wisdom gained through experience.

• Examples: Fostering a healthy innovation culture, facilitating complex discussions, or knowing when and how to take product and technical shortcuts for future flexibility.

• Strategy: Invest in people through mentorship, coaching, and peer communities. These are costly but invaluable for high-impact areas.

A Practical Flow for Knowledge Management

To prioritize knowledge management investments, I use this flow.

1. Start with Business Value

• Identify Urgency: Is the knowledge critical but rarely used, like runbooks or acquisition details? Invest accordingly.

• Define Outcomes: What’s the desired result? Can success be measured with fast feedback loops?

• Consider Change: Will the information change quickly? Weigh the value of documentation against its upkeep costs.

• Simplify or Automate: Can this knowledge be eliminated by simplifying a process or automating a task? Prioritize that when possible.

2. Leverage Slack for Rarely Used Knowledge

• On-demand Help: Create a central channel where pertinent experts provide just-in-time answers.

• Automated Expertise: Use tools like Notion AI to surface and organize these transient interactions.

3. Proactively Push Frequently Used Knowledge

• Explicit Knowledge: Write it down in an authoritative, searchable, discoverable location.

• Implicit Knowledge: Pair Loom videos with supporting documents to create accessible resources. For greater investment, build or buy interactive training or tooling, and give time for fluency.

• Tacit Knowledge: Invest in safe sandboxes to practice real-world skills, like game days, simulations, or low-stakes, supervised exemplar projects. Schedule time for them.

• Reinforce Self-Service: Promote a culture where team members look for documentation before asking questions. Make it easy for them to succeed.

4. Invest in People for Tacit Knowledge

• Coaching and Mentorship: Pair learners with internal or external experts to build wisdom and deep skills.

• Peer Communities: Establish groups that foster shared learning and collaboration (e.g. “guilds”) while maintaining explicit and implicit knowledge.

5. Keep Documentation Current

• Automate Updates: Deriving documentation from the source that defines the behavior—OpenAPI, dbt, and so on—is a great place to start.

• Assign Ownership: Each document should have a clear owner and an “expires on” or “last updated” date.

• Encourage Escalation: Make it everyone’s responsibility to flag outdated or incorrect information.

• Audit for Value: Periodically reassess documentation to determine whether it should be updated or deleted.

Closing Thoughts

Thoughtful knowledge management enables your team to act faster, smarter, and more effectively. It’s foundational to scaling efficiently and building a culture of learning.

I’m especially drawn to tacit knowledge. It’s expensive to develop but offers long-lasting differentiation. It thrives on diversity: different perspectives enrich wisdom and build stronger, more adaptable teams. And it’s the domain of our deepest experts—including us, as people leaders.

The most meaningful training in my own career has been experiential, growing tacit knowledge. Programs like Problem Solving Leadership, facilitation courses from Ten Directions, the Search Inside Yourself program, and coaching from my friend Francis Lacoste have deeply influenced my growth. Sharing challenges with peers and learning from different perspectives has built my richest sources of wisdom.

In fact, the flow I’ve shared here is inspired by my teams’ experiences and feedback, as well as lessons from Nancy Dixon’s book Common Knowledge, introduced to me by Wes Beary. This process has helped me refine how I think about and prioritize knowledge management across a wide range of contexts.

What’s your approach to managing knowledge in your organization? And what training has most shaped your tacit knowledge—or that of your team? I’d love to hear your insights.

Subscribe now

When priorities misalign or go unaddressed, the consequences are inevitable: strained relationships and underwhelming outcomes. This post shares two frameworks that have helped me catch prioritization problems before they escalate: a proactive process for alignment and leading indicators of failure.

A Process for Prioritization Alignment

At its core, prioritization is about aligning your actions with your company’s objectives and communicating those choices effectively. Here’s the simple three-step process I use.

1. Align priorities with company objectives. If critical personal priorities don’t reflect your company’s strategic goals, escalate your perspective to your manager and peer leaders (your “first team,” per Lencioni’s The Five Dysfunctions of a Team). Be prepared to adapt if the broader team’s objectives can’t flex.

2. Communicate your plan. Once you’ve aligned your priorities, make them known, particularly to your managers, peer leaders, and reports. Use clear, decisive language like “I intend to” or “UIHO” (Unless I Hear Otherwise). This unblocks progress while inviting feedback. Highlight key risks, like limited capacity or expertise, to keep leadership informed and involved.

3. Act with discipline. Execute your plan while staying adaptable. Address urgent issues without losing focus on your top priorities. If something critical and truly disruptive arises, revisit steps 1 and 2 to realign.

These may sound basic, but I often see missteps. In particular, the communications in steps 1 and 2 are essential. Once, I failed to escalate misaligned priorities. The broader organization was conflicted about direction, I wanted my teams to ship, and I thought alignment would be too costly and unnecessary. I was wrong. While alignment might have delayed progress by days, wasted work cost weeks and left the team even more frustrated.

Another time, I neglected to fully communicate my plan to my peers. When someone in GTM raised a concern, a peer unknowingly threw me under the bus because I hadn’t shared my prioritization. This small omission escalated into a complaint about me to my boss and a trust deficit with the sales and AM teams. It was a tough lesson that underscored the importance of visibility.

Leading Indicators of Prioritization Problems

While lagging indicators—like missed deadlines or frustrated stakeholders—are obvious, they’re also costly. The real challenge is spotting problems before they become critical.

Here are three early warning signs that I’ve learned to watch for in myself.

1. “I didn’t have time.” Time isn’t the issue. Prioritization is. If I can’t say “I didn’t prioritize that” with intentionality, it’s a red flag that I’m losing control of my focus.

2. Delayed feedback or verification. When I delegate tasks but fail to provide timely feedback, it signals I’m overcommitted or mismanaging my priorities. Delegation requires follow-through.

3. Defensiveness. Feeling defensive about what I did or didn’t get done often reveals underlying misalignment. Physical tells in my body (e.g., tight shoulders, stiff facial posture) are subtle but powerful indicators that something needs attention.

When I notice these signals, I take a step back and look for action.

• Revisit objectives: Are my actions aligned with the company’s priorities?

• Evaluate options: Can something be dropped, postponed, delegated, purchased, or automated?

• Reassess the process: Do I need to realign with my manager, peers, or team?

Leadership is about navigating complexity and uncertainty. By staying vigilant for these early indicators, I’ve been able to adjust course before small misalignments turn into big problems.

Closing Thoughts

Prioritization isn’t just a tactical challenge—it’s a reflection of leadership at its core. Aligning with company goals, communicating plans effectively, and staying alert to early warning signs are critical skills. I continue to hone them.

What are your leading indicators of prioritization problems? How do you maintain focus when time is tight? I’d love to learn from your experiences.

Subscribe now

These challenges aren’t inevitable. By following a few principles, you can design team interactions that encourage fast, reliable delivery. The book Team Topologies offers one such framework. Its focus on team types and interaction modes is insightful and practical, and I’ve drawn on it repeatedly over the years. I also agree with the authors’ observation that good team organization is tied closely with good system architecture, via Conway’s Law.

That said, not every part of the framework fits every organization or stage of growth. Labels like “stream-aligned teams” and “complicated subsystem teams” can feel abstract or premature in early projects. What matters most, I believe, are how teams interact and the principles guiding those interactions.

To that end, I’ve distilled Team Topologies’ concepts and my own experience into five rules that simplify and accelerate cross-team collaboration. Here’s what I’ve learned.

1. Integrate Teams Through Services, Not Directly

All systematic, long-term interactions between development teams should happen through well-defined services, APIs, or automated contracts. Relying on ad hoc communication, shared databases, or one-off handovers creates bottlenecks and slows teams down over time.

This principle aligns with Team Topologies’ “X-as-a-Service” interaction pattern. Building services requires foresight and discipline, but the payoff is worth it: teams can work independently while remaining aligned. This independence is critical for enabling ownership, which leads to the next principle.

2. Teams Own the Experience for Specific Users

Each team should take full responsibility for delivering value to a clearly defined group of users or customers, internal or external. When that scope becomes too large, group teams by shared users and divide responsibilities further, ideally by specific user needs.

This principle builds on Team Topologies’ concept of “stream-aligned teams” but applies broadly. Even platform teams benefit from defining their internal users and focusing on their needs. When teams are fully responsible for their users, they can prioritize effectively and deliver value quickly. But to achieve this autonomy, we need to reduce reliance on internal dependencies, which brings us to the next rule.

3. Customer-Facing Teams Maximize Their Independence

External-facing teams should own as much of their work as possible, starting from direct customer interfaces and working inward. However, this ownership must be tempered with other organizational needs, such as using platform-provided tools and services for key efficiencies and consistencies.

This autonomy reduces delays and accelerates delivery. For example, a customer-facing team building a new feature should be able to make necessary changes to their API, web interface, or data pipeline without waiting on another team. Platform teams enable this independence by providing foundational tools and guardrails—like design systems or infrastructure pipelines—that empower external-facing teams to deliver quality and consistency, faster.

4. Platform Teams Enable Cross-Team Independence

Platform teams provide shared services and infrastructure that allow other teams to work independently. Customer-facing teams should only interact with each other through platform-provided services.

This approach reduces cognitive load and friction. If Team A needs to integrate with Team B, they should request an API or tool from a platform team rather than building a direct integration. Platform teams are better positioned to design reusable solutions, handle the heaviest scaling challenges, and enforce cross-cutting standards. They become the enablers of cross-team collaboration and long-term scalability.

5. Collaborate Intensely, Briefly

Cross-team collaboration should happen within defined timeframes, ideally measured in weeks, and should be a focus for all involved. When building or consuming an API, both teams should work together in real time until the full integration is complete. Walking away halfway creates delays and misalignment.

For example, if one team needs an API from another, both teams should commit to the project simultaneously. Together, they can build the API and verify its fit within the feature. If necessary, the requesting team might even contribute API code for review, unblocking progress while keeping ownership clear. For larger projects, appointing a leader to break work into smaller, manageable pieces ensures collaboration remains focused and efficient.

Closing Thoughts

In the early stages of a project or startup, prioritizing product-market fit often takes precedence over optimizing team structures and architectures. But as the business grows, cross-team collaboration becomes a limiting factor. Left unchecked, it can create bottlenecks that are painful—and expensive—to fix.

Start small: introduce services, clarify team responsibilities, and define collaboration timeframes. Over time, incremental changes can eliminate bottlenecks and enable faster delivery, fewer dependencies, and more empowered teams.

Where do you see friction in your team interactions? Are there opportunities to streamline collaboration? I’d love to hear your thoughts.

Subscribe now

In many cases, I’ve found integration to be a more powerful framing than balance. Balance implies weighing competing forces against each other. Integration, on the other hand, invites us to weave them together into something more whole.

Integration in Innovation Teams

Take innovation teams, for example: the “product triad” of design, product, and engineering. I’ve pushed back against the common practice of separating technical roadmaps from product roadmaps. To me, all priorities must align with the business.

This demands integration. Developers must understand the business well enough to prioritize and shape product and design needs. PMs and designers, in turn, need enough technical fluency to evaluate, prioritize, and commit to technical needs. After all, scale and reliability are product features—they impact the user experience and business outcomes. Even investments in developer efficiency are business decisions, justified by how they improve delivery.

When a team integrates their perspectives and priorities, collective decisions become stronger and easier. PMs and designers who grasp technical constraints make better trade-offs. Developers who understand the business create more valuable solutions. Integration makes innovation collaborative.

Integration in Leadership

Integration is also a call I feel personally as a leader. I’m driven by a desire for connection and compassionate growth with others. But leadership also means making painful decisions—layoffs in tough times, firing good people who can’t keep up with the business, and confronting the fear of change.

There’s no balancing these tensions. My mistakes have taught me that true leadership isn’t about keeping business and humanity separate but about finding ways to act with integrity, caring for people and the business.

For me, this integration has come through recognizing that many challenges are bigger than any one person. I’ve learned to see leadership as an evolutionary process: a constant effort to adapt, grow, and align with things larger than ourselves. It’s a deeply personal journey, and it’s one we each navigate in our own way.

Finding Balance Along the Way

Integration takes time and effort. Asking developers to think more like PMs and designers—and vice versa—is a tough ask, especially early in careers or for those who’ve never worked that way before. Authentically navigating change and tough decisions requires emotional resilience and lived experience.

That’s often where balance comes in—not as the destination, but as a tool to help us along the way. Do you need to explicitly invite technical prioritization into the product roadmap? Do you need to ask tech leads to frame proposals in terms of product impact? Or do you need to carve out time for joy and connection to counterbalance difficult conversations?

Integration—whether of pain and joy, product and engineering, or business and humanity—is a long journey. Along the way, balance can be a tool to help us move forward.

Subscribe now