Every person has more potential than they realize, and unlocking that potential is the highest calling of leadership. Think about the people on your team right now. Think about what they’re capable of on their best day, in their best moment, when the conditions are right. Now think about how often those conditions actually exist.

The gap between where people are and where they could be represents the single largest opportunity most leaders will ever have. It’s also one of the most uncomfortable to reckon with, because it means accepting that you have more influence over your team’s trajectory than any process, any tool, or any strategy. That realization can feel overwhelming. It’s also the moment where real leadership begins.

The Line Between Managing and Leading

Many people in leadership roles spend most of their time managing. Good management produces acceptable results within known constraints. A strong manager keeps the system running, meets the targets, maintains quality, and holds people accountable to established standards. Organizations can’t function well without management.

Leading is different. Leading changes the conditions themselves. A manager works within the current reality. A leader looks at that reality and decides it isn’t good enough, then builds something better. Management asks: how do we execute well given what we know? Leadership asks: what would have to change for this team to achieve something it hasn’t achieved before?

The distinction matters because most organizations over-invest in management and under-invest in leadership. They build systems to track performance, enforce process, and maintain control. Those systems are useful. They are also insufficient. If the team’s potential is untapped, more management won’t unlock it; more tracking won’t unlock it; more deadlines won’t unlock it; and more process won’t unlock it.

I’ve watched this play out repeatedly across different companies and stages. A team is underperforming, and the instinct is to add a new reporting cadence, a tighter review cycle, or another layer of accountability. Sometimes those interventions help. More often, they address the symptom while ignoring the cause. The team didn’t need more oversight. It needed a clearer objective, better alignment, a stronger culture, or the freedom to operate with real ownership. Those are leadership problems, and they require leadership solutions.

We often assume the person with the title, the office, or the compensation is the leader. Many of them aren’t leading at all. They’re managing competently, which is valuable, but they’re not changing the conditions around them. And plenty of people without titles or teams are leading every day through the standards they set, the clarity they provide, and the way they influence the people around them. Title does not make a leader; changing the conditions does.

The Real Job

If leading is about changing conditions, and human potential is the one limitless resource, then the leader’s primary job becomes clear: unlock the potential of others.

This sounds simple. It is profoundly difficult.

Look honestly at any team you’ve led. There is a distribution that shows up with remarkable consistency. Roughly ten to twenty percent of your people are already reaching for more. They’re your change agents. They don’t need convincing; they need direction and room. Your job with this group is straightforward: identify them, point them at the right problems, and get out of the way.

On the other end, another ten to twenty percent are genuinely stuck. They may be in the wrong role, the wrong environment, or the wrong phase of their career. The responsible thing, and honestly the kind thing, is to help them find a situation where they’re better positioned to succeed. Spending disproportionate energy trying to move this group forward comes at the direct expense of the people who are ready to move.

The remaining sixty to eighty percent are the ones who will define your success or failure as a leader. They want to do meaningful work. They’re capable of it. They haven’t been shown the path, or they haven’t been given a reason to believe the path is real. Whether these people fulfill their potential or fall short falls largely on us as leaders.

That’s a sobering number. The majority of any team’s untapped capacity sits with people who are waiting for leadership to create the conditions where they can engage. If we get it right, the results compound. If we get it wrong, or if we never try, we leave most of our capacity on the table.

What Crushes Potential

Before we talk about how to unlock potential, it’s worth naming the forces that crush it, because most organizations are running at least some of these patterns without recognizing them.

Fear is the most universal constraint. Fear of failure, fear of looking foolish, fear of taking a bold step when the safe path is clearly marked. This isn’t limited to junior people. I’ve watched experienced leaders hold themselves back because the perceived risk of being wrong felt larger than the cost of staying still. Progress is almost always uncomfortable. The organizations that achieve the most are the ones that make that discomfort survivable.

Bad management crushes potential. Managers who control instead of develop, who constrain instead of enable, who treat obedience as a proxy for commitment. When the message people receive is “follow the rules, don’t exercise judgment, don’t take risks,” potential doesn’t just go unrealized. It gets actively suppressed. People internalize the boundaries and stop trying to exceed them.

Bureaucracy crushes potential. Process is essential when it serves the goal. It becomes destructive when it replaces the goal. Rules-based, hierarchical systems eventually stop serving the people they were designed to support and start serving their own continuation. Turf battles replace collaboration. People forget who they’re there for. The organization turns inward.

I’ve written before about the danger of proxies, how process, metrics, busyness, and responsiveness can all become substitutes for the value they were meant to enable. The same dynamic applies here. When the system becomes the focus, and following the steps matters more than achieving the outcome, you’ve created an environment where potential has nowhere to go.

Building Basecamp

If unlocking potential is the job, the practical question becomes: how?

I think about this the way I would think about an expedition. Before any team makes a summit attempt, someone has to build the basecamp. The basecamp is where the leader establishes everything the team needs to climb: the objective, the systems, the waypoints that define progress, and the shared mindset that holds the group together under pressure. The leader doesn’t carry anyone to the summit. The leader builds the conditions that make the summit possible.

Here’s what makes this hard: you don’t get to pause the climb while you build. The team is already on the mountain. The weather is already moving. In real leadership, there is no clean preparation phase followed by a neat execution phase. You build the basecamp while the expedition is underway, and you keep improving it as conditions change. The basecamp is never finished. It’s a living structure that evolves as the team evolves, as the terrain shifts, and as you learn what’s actually required. That’s what makes this leadership work rather than planning work.

A well-built basecamp has four elements. Each one is a dimension of what leaders must do. Each one reinforces the others. And when all four are in place, they create something that no single element can produce on its own: the space for empowerment.

The Objective

Every expedition starts with a deliberate choice about where to go and why it matters. Without a clear objective, effort scatters. People work hard, sometimes heroically hard, but in different directions.

The objective is strategy, vision, and purpose. Where are we going, and why is that destination worth the climb? This requires more than a goal statement on a slide. It requires defining where we are today, where we want to be, and why the gap between those two states matters enough to justify the effort and discomfort of closing it.

When leaders lack clarity about what success looks like, every request feels equally important. Responsiveness becomes a proxy for effectiveness. Busyness becomes a stand-in for progress. A clear objective is the antidote. It tells people what to pursue and, just as importantly, what to ignore.

The more clearly the objective is defined, the more effectively everything else aligns. This is what the basecamp exists to serve, the reason the team is here at all. Without it, the other three elements have nothing to point towards.

The Route

On any climb, you don’t wait until the summit to find out if you went the right way. You check against the map and GPS regularly. You watch for landmarks, track your elevation, assess conditions at established waypoints, and make adjustments when the terrain doesn’t match the plan.

The route is how you’re expecting to reach the objective. It’s the plan, the sequence, the set of decisions about how the team will get from here to there. What makes a route useful is that it gives you something to measure against. The landmarks and waypoints you establish along the way are your measures of success, the signals that tell the team whether they’re gaining altitude or drifting off course.

A common trap is measuring activity over outcomes. Completing projects sounds productive. Shipping features sounds like progress. But if those projects and features don’t produce meaningful results for customers, the work didn’t matter. I would rather a team did nothing than stay perpetually busy on things that don’t make a difference. If people are always occupied with the unimportant, they will never find the important.

I deliberately think about this as “measures of success” rather than just metrics, because metrics can measure anything. The question is whether they measure the right things. What gets measured defines what people believe matters. It is our job as leaders to define the measures that connect back to the objective and tell us honestly whether we’re gaining altitude or just counting steps.

The Systems

On an expedition, systems are ruthlessly practical. You don’t bring gear because it’s in the catalog. You bring what the climb requires. Roles are defined by the terrain, not by org charts. Decision-making authority sits with whoever has the best visibility, which shifts as conditions change. When the plan meets reality, the systems adapt.

Systems are your structure, process, team composition, and the operational decisions about how work gets organized and how decisions get made. I don’t believe there is one right structure or one right process for any team. The product, the people, the technology, the life cycle of the business; all of these shape what works. What matters is that the systems are intentional, that they align to the objective, and that they evolve when conditions change.

Misalignment between the objective and the systems is one of the most common failures I’ve seen. I lived this at a previous company where we had a team with a clear mandate to drive the business, but every member reported into functional leaders with different goals. The functional goals worked against the strategic objective, and no amount of individual effort could close the gap; we missed our numbers. Systems have to follow the objective. When they don’t, the team is climbing with gear built for a different objective.

The other risk is treating process as a proxy for good decision-making. Good process serves you so you can serve your customers. When process becomes the point, when people stop looking at outcomes and start making sure they’re following the steps, you’ve crossed a line. That’s when organizations stop unlocking potential and start suppressing it.

The Mindset

Mindset is what separates a team that communicates honestly about deteriorating conditions from one where ego or fear produces silence until it’s too late. On any climb, that distinction is the difference between summiting and disaster. In an organization, it’s the difference between a culture that unlocks potential and one that quietly suffocates it.

Mindset is culture, defined by what’s actually practiced and rewarded when the pressure is real, not by what’s written on the wall. People will listen to what leaders say for a while, and then they start watching what leaders do. They watch what gets recognized, what gets tolerated, and what gets punished. The behavior that leadership models and rewards is the culture, regardless of what any values statement claims.

I care about specific things in the teams I lead: creativity, collaboration, a relentless pursuit of improvement. I want work to be the kind of experience where people feel challenged and supported at the same time, where they treat each other well and they’re always thinking about how to make their customers’ lives better. I want people to take risks, try new things, fail honestly, learn, and try again. I tell my teams to ask for forgiveness, not permission. I don’t mean cross the line. I mean be empowered to act, and trust that acting for the right reasons will be recognized, even when the outcome isn’t perfect.

Reward people for doing new things for the right reasons. Never punish the honest mistake. Punish bad reasoning. Punish stagnation. People who are comfortable with “good enough” or “we’ve always done it that way” create drag on everyone around them. That mindset is contagious, and it’s the leader’s job to make sure it doesn’t spread.

The Climb

When the objective is clear, the route is defined, the systems are aligned, and the mindset is right, the leader has done something rare: built the conditions for empowerment. The team can climb. They know where they’re going, how to measure progress, how they’re organized, and how they operate together. What’s left is the space to move, to make decisions, to take ownership, to achieve things they hadn’t fully believed were possible.

This is where many leaders struggle, because empowerment requires letting go. It requires trusting that the basecamp you’ve built will hold, that the conditions you’ve created will produce results you couldn’t have prescribed in advance. The leaders who fail here are the ones who start worrying about their own relevance: what will I do if my team doesn’t need me? Why do I matter if they’re performing beyond what I could do myself?

That instinct, the need to stay in front of your team’s work, to remain indispensable, to keep your hands on every decision, is the line between managing and leading. It’s the moment where fear wins over purpose. And it’s where potential gets crushed by the very person responsible for unlocking it.

The reality is the opposite of what fear suggests. If you can demonstrate that your team is thriving, that you’ve developed leadership within it, that the system works without your constant intervention, you haven’t made yourself irrelevant. You’ve proven you’re ready for a bigger climb.

I measure my success by the potential I unlock in others. Their success, in turn, is measured by the potential they unlock in their teams. That’s how leadership compounds. An organization cannot summit if the people inside it are not reaching their potential. And they won’t reach their potential without a leader who builds the conditions that make it possible.

Build your basecamp. Then let the team climb.

This is the first post in the Building Your Basecamp series. In future posts, I’ll go deeper into each of the four elements: the objective, the route, the systems, and the mindset. Each one deserves more than an introduction, and each one is where the difference between managing and leading becomes most visible.

The next phase of AI in software engineering is not about writing more code faster. It is about reducing friction across every stage of how software is built, validated, shipped, and measured so that developers and their agents can do their best work together.

DevEx^AI ™ is a framework for measuring and improving agent-readiness across the entire product development lifecycle. Most engineering organizations have achieved the first milestone: AI literacy. Engineers use assistants and AI is part of daily work. The opportunity now is to move beyond AI-assisted code generation and enable AI agents to operate effectively across every stage of how software is built.

The thesis is simple: the same things that block AI agents block developers. Code production has never been the primary bottleneck in mature software organizations. The friction is in everything else—specifications, test infrastructure, review processes, documentation, feedback loops. When you reduce that friction for agents, you reduce it for everyone.

The framework organizes 10 stages of the product development lifecycle into 5 domains, each scored on a 0–4 agent-readiness scale. This produces a scorecard and spider chart that gives engineering leadership immediate visibility into where automation is advancing, where it is stalled, and where investment will have the greatest impact. The unit of progress is not AI usage, it is agent enablement, through the removal of friction.

Critically, DevEx^AI keeps the developer at the center. The “raised to the power of AI” formulation is intentional: the base is developer experience, AI is the exponent. The Agent-Ready Maturity Model measures infrastructure readiness; traditional developer experience surveys and operational metrics like DORA remain essential companions that ensure infrastructure progress translates into real human outcomes.

The Core Thesis: DevEx^AI

Developer Experience raised to the power of AI.

AI has opened something remarkable for software engineering. The volume of implementation work a single engineer can produce has increased dramatically. Agents draft implementations, generate tests, and write documentation. The capability is real, it is improving rapidly, and it changes the calculus of how software gets built.

The opportunity, and it is an enormous one, extends far beyond code generation. Every stage of the product development lifecycle can benefit from AI and agent involvement. The teams that capture the full value of this moment will be the ones that enable agents across the entire lifecycle, not just in the editor.

There is a growing conversation about whether the traditional software development lifecycle is being redefined. As agents compress the boundaries between stages—requirements flowing into implementation, testing happening alongside code generation, deployment becoming continuous and automatic—the discrete, sequential model many teams operate on is evolving. In time, the lifecycle may look fundamentally different from the one we know today.

But for established software companies with customers, compliance obligations, institutional knowledge, and teams that coordinate at scale, the SDLC still represents how work gets done. The stages may become more fluid, the boundaries less rigid, but the underlying work—understanding what to build, building it correctly, proving it works, shipping it safely, and learning whether it delivered value—does not disappear. It is the work of building reliable, maintainable software that drives the current software industry.

This framework is designed to meet those teams where they are. Not by measuring AI adoption, but by providing a structured approach to moving each stage of the lifecycle from manual to AI-assisted to agent-enabled. The goal is not to dismantle the lifecycle but to systematically reduce the friction within it so that both humans and agents can operate at maximum effectiveness.

Outputting code has never guaranteed successful software. The DevOps and Developer Experience movements were built on this understanding: the hardest challenges in scaling a successful product are rarely in code generation itself. They are in the coordination, security, quality, feedback, and delivery systems that surround it. The industry’s most impactful investments—CI/CD, testing infrastructure, observability, developer tooling—have always targeted friction across the full lifecycle, not code output. That is why improving these systems has been recognized as one of the most critical levers of success for great software companies.

That principle does not change with AI. It becomes more urgent. As implementation speed increases, the quality of every other stage—discovery, specification, testing, review, documentation, observability, feedback—becomes the primary differentiator between teams that deliver value and teams that simply deliver code faster.

That is what DevEx^AI is about. It is not about AI writing code. It is about enabling developers WITH their agents, end to end.

From Adoption to Enablement

Successful AI adoption started with getting people to use AI at all; building literacy and making it part of daily work. That was step one and many companies have achieved this level. The next phase is harder and much more consequential.

The teams that thrive with AI will not be the ones where individuals use AI coding assistants most frequently. They will be the ones that enable agents throughout the software lifecycle. The way to drive that is by measuring what level of agent-readiness is attained within each stage, within each domain; not measuring how much people are using AI, but how much the organization is reducing the friction that allows agents to deliver maximum value.

DevEx^AI provides the measurement framework. It enables teams to see where they are today, establish time-bound goals, and track progress stage by stage. The unit of progress is not “AI usage”, it is “friction removed.”

The Win-Win: What’s Good for Agents Is Good for Developers

There is an elegant symmetry at the heart of this framework: an experience that is great for agents is also an experience that is great for developers.

One of the historical challenges with DevEx improvements is that humans are remarkably adaptable. Teams institutionalize friction. They build workarounds, develop tribal knowledge, and normalize manual processes to the point where the value of improving feels like it isn’t worth the cost of change. The pain is real but diffuse, so it persists.

Agents are not as creative about finding ways past friction or rationalizing why it’s acceptable. An agent can’t rely on tribal knowledge. It can’t “just ask Sarah” how the deploy process works. It can’t compensate for a missing test suite by being extra careful. When an agent hits a wall, the wall is visible; a concrete, measurable, blocker.

This is what makes agents such powerful catalysts for improvement. Because they cannot work around friction the way humans have learned to, they make the friction visible. And visible friction is friction that can be addressed. Optimizing for agents forces the kind of infrastructure investment that benefits everyone. Better specifications, better test coverage, better documentation, clearer architectural patterns – improvements compound for agents and developers alike.

DevEx^AI is a win-win by construction: every investment in agent-readiness pays dividends in developer experience.

Maturity Levels

Each stage of the product development lifecycle is scored on a five-level scale reflecting the degree to which an AI agent can participate in that work:

The goal is not to reach Level 4 everywhere. The goal is to know where you are at each stage, identify what’s blocking the next level, and make deliberate progress. Some stages may remain human-led by design. Others should be as automated as possible.

The Five Domains

The 10 stages of the product development lifecycle group into five composite domains. Each domain represents a distinct phase of value creation, from understanding what to build through learning whether it worked. Each stage includes an agent-ready vision: a concrete picture of what that stage looks like when the infrastructure, processes, and tooling are in place for agents to operate effectively alongside developers.

Domain: DEFINE

Understand the problem and plan the work

The Define domain covers everything from identifying what to build through breaking it into actionable units of work. This is where human judgment has the highest leverage—and where the quality of AI output across all downstream stages is determined. Spec-driven development, context engineering, and disciplined work decomposition are the foundation of effective agent collaboration.

Stage 1: Problem Discovery & Prioritization

Customer needs are identified, validated, and prioritized. Includes feedback intake, market analysis, support ticket patterns, and roadmap decisions.

Output: a prioritized problem worth solving.

Agent-Ready vision: An agent surfaces relevant support tickets, usage patterns, and customer feedback when a team is planning work—reducing the time from “customers are struggling” to “we know what to build.”

Stage 2: Requirements & Specification

The problem is translated into what we’re building. Includes product specs, acceptance criteria, design mockups, architectural constraints, and machine-readable context.

Output: a spec that both humans and agents can act on.

Agent-Ready vision: Given a problem statement and context, an agent drafts a spec with acceptance criteria that a product manager refines rather than writes from scratch. Context is structured so that downstream agents can consume it directly.

Stage 3: Work Decomposition & Planning

The specification is broken into small, implementable units of work. Includes task breakdown, dependency mapping, sprint planning, and assignment.

Output: tickets that are clear, scoped, and ready for agent or human execution.

Agent-Ready vision: An agent decomposes a spec into well-scoped tickets with clear descriptions, dependencies mapped, and estimated complexity—ready for a lead to review and adjust.

Domain: BUILD

Write the code

The Build domain is where most AI adoption efforts have focused to date. Code generation via copilots and agents is the most visible application of AI in software engineering. While essential, it represents only one of ten stages—and its effectiveness is largely determined by the quality of the Define stage that precedes it.

Stage 4: Implementation

Code is written. Includes feature development, bug fixes, refactoring, and integration with existing systems. Ranges from copilot-assisted coding to fully agent-driven implementation from spec.

Output: a working branch with code changes.

Agent-Ready vision: Given a well-defined ticket and codebase context, an agent produces a working implementation that follows existing patterns, handles edge cases, and is ready for review. The agent operates within repo-aware guardrails that enforce style, security, and architectural standards.

Domain: VALIDATE

Prove the work is correct and safe

The Validate domain ensures that what was built actually works, meets quality and security standards, and aligns with architectural direction. Testing and code review serve different purposes and have different automation profiles. Industry consensus is clear: agents plus guardrails, not agents alone.

Stage 5: Testing & Quality Gates

Code is verified for correctness, security, and compliance. Includes automated unit tests, integration tests, end-to-end tests, regression suites, static application security testing (SAST), dependency vulnerability scanning, compliance policy checks, linting, static analysis, type checking, coverage thresholds, and architectural conformance checks. This stage encompasses both the creative work of writing good tests and the deterministic work of running automated quality gates.

Output: confidence that the change does what it should, doesn’t break what it shouldn’t, meets security and compliance standards, and passes all automated quality gates.

Agent-Ready vision: An agent generates comprehensive tests—unit, integration, and edge cases—aligned with existing patterns. Automated security scanning, compliance checks, linting, and static analysis run as deterministic gates. An agent interprets gate failures and proposes fixes without human triage.

Stage 6: Code Review & Knowledge Transfer

Changes are reviewed for code quality, business logic correctness, security posture, maintainability, and architectural alignment. Includes peer review of pull requests, verification that the change fulfills the intended business functionality, assessment of code readability and long-term maintainability, identification of security anti-patterns, feedback loops, and documentation of design decisions. This stage serves a dual purpose: catching issues that automated gates miss and transferring knowledge across the team.

Output: approved, merge-ready code with shared understanding of the design intent and trade-offs.

Agent-Ready vision: An agent performs a structured first-pass review covering pattern consistency, security anti-patterns, maintainability concerns, and business logic alignment with the ticket spec. Human reviewers focus on architectural judgment, design trade-offs, and knowledge sharing—the parts that require institutional context and engineering wisdom.

Domain: SHIP

Get the work to customers

The Ship domain covers the last mile from merge-ready code to live product. For many teams, deployment infrastructure is already the most automated part of the lifecycle via existing CI/CD. The opportunity is extending that automation upstream into documentation, compliance tracking, and release coordination—which are often manual bottlenecks even when deployment itself is smooth.

Stage 7: Documentation & Release Readiness

Changes are documented and all release artifacts are prepared. Includes technical documentation, release notes, API documentation, internal knowledge base updates, compliance tracking of changes (audit trails, change control records), security impact documentation, and regulatory or customer-facing disclosures where applicable. For B2B SaaS companies serving regulated industries, traceability from ticket to deployed change is not optional.

Output: stakeholders know what changed and why, and all compliance and audit requirements are satisfied.

Agent-Ready vision: An agent generates documentation, release notes, changelog entries, and compliance records from the PR, commit history, and ticket context—ready for human review rather than human drafting. Audit trail generation is fully automated.

Stage 8: Deployment & Release

Code is shipped to production. Includes CI/CD pipeline execution, feature flagging, staged rollouts, and release coordination.

Output: the change is live and customers can use it.

Agent-Ready vision: Largely achieved through existing CI/CD. Future improvements include agent-triggered rollbacks based on anomaly detection, smarter feature flag management, and automated canary analysis.

Domain: LEARN

Measure impact and close the loop

The Learn domain closes the feedback loop from production back to problem discovery. This is the least automated domain at most organizations and represents the largest untapped opportunity. An agent that can synthesize production telemetry, customer adoption data, and support signals into actionable insights would fundamentally accelerate the entire cycle.

Stage 9: Observability & Production Intelligence

Production systems are observed and patterns are surfaced proactively. Includes distributed tracing, structured logging, metrics collection (via OpenTelemetry and similar standards), alerting, error correlation, performance monitoring, incident management, and trend analysis. The shift from reactive monitoring (“alert me when something breaks”) to proactive observability (“show me what’s happening and what’s changing”) is central to this stage.

Output: fast detection of problems, emerging patterns, and production insights that inform the next cycle.

Agent-Ready vision: An agent triages alerts, correlates errors with recent deployments, drafts incident summaries, performs initial root cause analysis, and creates investigation tickets—reducing mean time to detection and response. Proactive trend analysis surfaces degradation before customers notice.

Stage 10: Customer Value & Feedback Loop

Impact is measured and learning flows back into the cycle. Includes feature adoption tracking, usage analytics, customer value metrics (time saved, revenue impact, workflow efficiency), customer health scoring, support ticket analysis, NPS and satisfaction signals, and direct customer conversations. The emphasis is on measuring value delivery quantitatively—adoption and outcome data is the most automatable and highest-signal input for the next cycle, while human feedback remains critical for context and nuance.

Output: evidence of whether value was delivered and how customers are adopting changes, feeding directly back into Stage 1 prioritization.

Agent-Ready vision: An agent analyzes adoption metrics, support ticket patterns, and usage data to surface what’s working, what’s underperforming, and what customers are struggling with—closing the loop from delivery back to discovery with data, not anecdote.

How to Use This Model

The value of any framework is in its application. The Agent-Ready Maturity Model is designed to be practical—something a team can pick up, apply, and begin generating insight from in a single session. It works in three phases: assess, set goals, and measure progress.

Phase 1: Self-Assessment

The team scores their current state across all 10 stages using the 0–4 maturity scale. The assessment surfaces where teams feel friction, where automation has already taken hold, and where the biggest gaps exist between current state and potential.

Assessments should be honest, not aspirational. If a stage is manual, score it 0. If assistants are in use but humans still drive every decision, that’s a 1. The spider chart that results from an honest assessment is far more useful than an inflated one.

Phase 2: Goal Setting

Leadership establishes targets in collaboration with the team across three horizons: 6 months, 12 months, and 18 months. These targets should be set per stage, and goals should reflect where investment will have the highest impact—not a uniform push across all axes.

Good goal setting is harder than it looks. The temptation is to target the highest maturity level across every stage immediately. This leads to diffuse effort, slow progress on everything, and a sense that nothing is actually improving. The better approach is to focus. Pick 2–3 stages where a level transition would unlock the most downstream value, invest there deliberately, and achieve wins that are visible and real.

Visible progress builds momentum. A team that moves Testing from Level 1 to Level 2 and can demonstrate measurably faster validation cycles will be more motivated—and more credible—than a team that made marginal progress across eight stages simultaneously. Celebrate the wins. Let success fuel further ambition.

Goal setting should also consider dependencies between stages. For example, moving Implementation (Stage 4) from AI-Accelerated to Agent-Ready is difficult without first improving Work Decomposition (Stage 3), because agents need well-defined inputs to produce good outputs. The model reveals these dependencies; leadership should sequence goals accordingly.

Phase 3: Progress Measurement

Reassess at regular intervals, with cadence determined by the team’s rate of change. Teams in active improvement cycles should check in monthly. Teams in a steady state may assess quarterly. A reasonable starting cadence is quarterly full assessment with monthly check-ins on active focus areas.

Progress measurement should track two things: the maturity score itself (are we advancing levels?) and the friction indicators that the score reflects (are builds faster? are reviews less bottlenecked? are incidents resolved sooner?). The maturity score is the leading indicator; the operational improvement is the lagging confirmation that the score reflects real change.

Over time, the model becomes a shared language for discussing infrastructure investment. Instead of abstract debates about “should we invest in better testing?” the conversation becomes “we’re at Level 1 on Testing and our 6-month target is Level 2—what specifically is blocking that transition?”

Illustrative Assessment

The following spider chart and scorecard represent an illustrative baseline assessment with proposed targets. Current-state scores should be validated by teams as a kickoff exercise. Targets are intentionally conservative, focused on achievable progress in the highest-impact stages. The scores below are illustrative – your organization’s profile may look different.

Figure 1: Sample Agent-Ready Maturity Assessment (illustrative scores)

Table 1: Sample Agent-Ready Maturity Scorecard (illustrative scores)

Developer Experience as the Foundation

DevEx^AI is a framework about developers—not about agents. The “raised to the power of AI” formulation is intentional: the base is developer experience. AI is the exponent. Remove the base and the exponent is meaningless.

This distinction matters because it determines what success looks like. Success is not a dashboard full of Level 4 maturity scores. Success is engineers who spend more of their time on work that requires judgment, creativity, and institutional knowledge—and less time on mechanical toil that an agent could handle. The maturity model measures the infrastructure. The developer’s experience is the outcome that infrastructure serves.

The Value of Developer Experience

The Developer Experience (DevEx) discipline emerged from a simple but powerful insight: developer productivity is not determined primarily by individual talent or effort. It is determined by the friction and feedback loops in the environment around them. How long does it take to get a build? How clear are the requirements? How painful is the review process? How fast can you get feedback on whether your change works? These environmental factors compound across every engineer on a team, every day. Small reductions in friction produce outsized improvements in throughput, quality, and job satisfaction.

DevEx^AI does not replace this discipline. It builds on top of it. The agent-readiness lens adds a new dimension—asking not only “is this experience good for humans?” but “is this experience good for agents too?”—and in doing so often reveals friction that teams have normalized but never resolved. But the foundation remains: if you are not investing in developer experience, agent-readiness improvements will underperform because the environment they operate in is degraded for everyone.

Complementary Instruments

The Agent-Ready Maturity Model and traditional DevEx measurement are complementary instruments that reveal different things.

The maturity model asks: can an agent operate effectively at this stage? It measures infrastructure readiness—the presence of clear specs, automated tests, CI pipelines, observability tooling, and feedback mechanisms that agents need to function.

A DevEx survey asks: how does it actually feel to work here? It measures the human experience—perceived friction, satisfaction, confidence in tools, and the sense that the environment supports rather than hinders good work.

You need both signals. A stage can score well on agent-readiness while the human experience remains painful—the tooling is there but the workflow hasn’t adapted, or the agent output quality isn’t trusted enough to save time. Conversely, a team can report reasonable satisfaction with a stage they’ve normalized as manual, while the maturity model reveals enormous untapped potential. The most valuable insights emerge at the intersection: where maturity and satisfaction converge or diverge, that’s where leadership attention should focus.

Operational Metrics Still Matter

The Agent-Ready Maturity Model measures capability—what level of agent involvement is possible at each stage. It does not directly measure performance—how fast and how well the team is actually delivering. For that, you need operational metrics.

Cycle time, PR review time, deployment frequency, change failure rate, mean time to recovery—these well-established metrics remain essential. They are the lagging indicators that confirm whether agent-readiness improvements are translating into real delivery performance. Frameworks like DORA (developed by Nicole Forsgren, Jez Humble, and Gene Kim) and SPACE (developed by researchers at Microsoft Research and GitHub) provide structured approaches to measuring software delivery performance and developer productivity across multiple dimensions.

DevEx^AI intentionally does not replicate that ground. The DevEx and engineering metrics landscape is well-established and well-documented. What has been missing is a framework that maps agent-readiness specifically across each stage of the software lifecycle—and that is what the Agent-Ready Maturity Model provides. The three work together:

DevEx surveys tell you where developers feel friction and where the environment is supporting or hindering their work. Run these regularly—quarterly at minimum—and track trends over time.

Operational metrics tell you how the system is performing. Cycle time, PR throughput, deployment cadence, incident recovery—these confirm whether improvements are showing up in your delivery pipeline.

The Agent-Ready Maturity Model tells you where agent automation is possible, where it’s blocked, and where investment will have the greatest leverage. It is the leading indicator; DevEx surveys and operational metrics are the confirming evidence that maturity improvements are producing real outcomes.

The Role Evolves, the Principle Endures

Behind every maturity score is a team of people trying to do meaningful work. The purpose of this framework is not optimization for its own sake. It is to create an environment where engineers can focus on the problems that require their judgment, creativity, and experience, and where agents handle the rest. That is a better path for everyone involved.

As stages mature toward Agent-Ready and Agent-Native, the nature of the developer’s role will shift. from performing the work to directing and evaluating it. The DevEx questions evolve accordingly: from “how painful is this task?” to “how confident are you in the agent’s output?” and “how effective are the guardrails?” But the principle remains constant. The developer’s experience is the measure of success at every level, from Manual through Agent-Native.

The agents serve the humans. Not the other way around.

Foundations

No framework exists in isolation. DevEx^AI is built on the work of practitioners and researchers who have shaped how the industry thinks about software delivery, developer productivity, and the relationship between tools and the people who use them.

The DevOps movement established that software delivery is a whole-system problem. Nicole Forsgren, Jez Humble, and Gene Kim formalized this understanding through the DORA research program and their book Accelerate, demonstrating that software delivery performance — measured through deployment frequency, lead time, change failure rate, and mean time to recovery — directly predicts organizational performance. Gene Kim’s earlier work, including The Phoenix Project and The Unicorn Project, made the case that developer friction is an organizational problem, not an individual one.

Forsgren and colleagues extended this thinking through the SPACE framework in 2021, establishing that developer productivity cannot be captured by any single dimension. Abi Noda and the DevEx community built further, shifting the conversation from measuring productivity to improving the lived experience of developers — the friction, feedback loops, and environmental factors that determine whether engineers can do their best work.

Gergely Orosz at The Pragmatic Engineer has been the most consistent voice documenting the pragmatic reality of how AI is changing software engineering at established companies — separating what is genuinely working from what is hype, and showing how engineering roles are transforming rather than disappearing. Matt Biilmann at Netlify introduced the discipline of Agent Experience, recognizing that tools designed for humans often fail for agents and that designing for agent usability improves the experience for everyone.

To my knowledge, no existing framework maps agent-readiness specifically across each stage of the product development lifecycle. DORA and SPACE measure delivery performance and developer productivity. Existing AI adoption models measure organizational usage broadly. DevEx^AI is differentiated by its per-stage, SDLC-specific lens, asking not “how is our organization adopting AI” but “how agent-ready is each step of how we build software?”

Closing

DevEx^AI is built for practitioners. It is not a vendor framework or a product pitch. It is a practical tool for engineering teams navigating the next phase of how software is built; the phase where developers and agents work together across the full lifecycle, and where the friction removed drives the value created. The opportunity is real, the tools are here, and the teams that move with clarity and conviction will build better software for the people who depend on it.

References

Forsgren, N., Humble, J., Kim, G. Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations. IT Revolution Press, 2018.

Kim, G. The Unicorn Project: A Novel About Developers, Digital Disruption, and Thriving in the Age of Data. IT Revolution Press, 2019.

Forsgren, N., Storey, M-A., Maddila, C., Zimmermann, T., Houck, B., Butler, J. “The SPACE of Developer Productivity: There’s More to It Than You Think.” ACM Queue, Vol. 19, No. 1, pp. 20–48. February 2021.

Noda, A., Storey, M-A., Forsgren, N., Greiler, M. “DevEx: What Actually Drives Productivity.” ACM Queue, Vol. 21, No. 2, pp. 35–69. April 2023.

Orosz, G. The Pragmatic Engineer (newsletter). pragmaticengineer.com. Ongoing.

Biilmann, M. “Introducing AX: Why Agent Experience Matters.” Biilmann Blog, January 2025. biilmann.blog/articles/introducing-ax/

Over time, though, I came to see that time itself wasn’t the real constraint. The deeper issue was ownership of my time. That ownership is harder than ever to protect. We live in an environment that is deliberately engineered to capture attention. The modern economy profits from keeping us engaged, reactive, and just distracted enough to never quite stop and reflect. In a world of ubiquitous information, control comes through overload. Yuval Noah Harari has described this shift clearly: when information is everywhere, power belongs to those who can maintain clarity about what matters and direct their attention accordingly. With attention overloaded, depth of thinking hasn’t disappeared, but it does require an active choice.

Work culture often reinforces this pattern. Many people come to believe that professionalism means letting others control their calendar; your job is to accept meetings, respond immediately, and show up whenever you’re asked. That posture is rarely questioned, and it’s often rewarded in subtle ways. But over time, it erodes judgment, focus, and satisfaction. Days fill themselves, attention is fragmented, and important work is crowded out by urgent noise.

What finally became clear to me was both simple and uncomfortable: my time is going to be controlled no matter what. The only question is whether I’m the one doing it. That realization changed how I thought about leadership. Once I stopped treating attention as something I reacted to, and started treating it as something I deliberately directed, my relationship with time shifted.

Owning your time isn’t selfish. It’s a form of stewardship. As leaders, what we protect matters as much as what we produce. Letting urgency, algorithms, or other people’s preferences dictate our schedules doesn’t make us more committed, it makes us less effective. Guarding time creates the conditions for better judgment, deeper thinking, and more sustainable contribution.

Ownership in Practice

Once I accepted that my time was mine to steward, the question shifted. The challenge was no longer philosophical. It was practical. If I truly believed that attention was my most valuable resource, then that belief needed to show up in how I responded to requests, how I structured my days, and how I made tradeoffs when everything felt important.

What follows isn’t a complete system, and it isn’t exhaustive. To get started, these are a small set of practices that changed my relationship with time. Each one emerged from noticing a pattern that wasn’t serving me, making a deliberate decision, and then living with the consequences of that choice. Over time, those decisions gave me more clarity, a calmer day, and sharper judgment.

Saying No (and Not Now)

For most leaders, the hardest part of time management isn’t effort. It’s refusal. Not because they don’t recognize bad ideas, but because they’re constantly being asked to say no to good ones. When everything sounds reasonable in isolation, declining a request can feel personal, even disloyal.

What changed for me was reframing what “no” actually meant. I stopped treating it as rejection and started treating it as a statement of priorities. In practice, no usually doesn’t mean “never.” It means “not now, given our current priorities.” That distinction matters. It shifts the conversation away from whether a request is good or important in the abstract and toward how it compares to everything else competing for limited attention. This invites others to engage in collaborative prioritization instead of simply asking “why not?”

Over time, I adopted a few personal rules that made this easier and more consistent. When I am asked if I can take on a new initiative, I frame my response in shared priorities. I don’t accept same-day meetings unless something is truly urgent; meeting invitations are requests, not obligations. When someone asks for time or attention that I don’t have, I anchor my response in what I am focused on, explain why, and offer a next window rather than a vague deferral. For personal or professional opportunities that feel exciting but ambiguous, I pressure-test my enthusiasm with a simple question: If I had to do this tomorrow, and it was twice as hard and half as valuable, would I still do it? If the answer is no, it’s usually interesting, not important.

Building a Blocky Schedule

Once saying no became easier, the next issue was what to say yes to, and when. That’s where structure matters. For me, the single most impactful change was moving toward a deliberately blocky schedule. Focus is where meaningful work happens, and focus is fragile. As anyone who has done engineering, creative work, or deep problem-solving knows, context switching is an efficiency killer. A day fragmented into alternating thirty-minute meetings and thirty-minute gaps doesn’t create usable time. It creates exhaustion. I stopped treating the open spaces between meetings as available capacity and started treating them as protected. Instead of letting my calendar fill organically, I block time explicitly for focused work before it disappears. Not with hyper-specific tasks, but with the intention to think, write, design, or make progress on the most important problems.

To make this sustainable, I lean on tooling to do the mechanical work for me. I use an AI-assisted calendar to help cluster meetings, shift commitments, and preserve larger blocks of uninterrupted time. I’m not good at rigid task scheduling, and I’ve learned not to pretend otherwise. What works for me is protecting time for focus and letting energy and context guide what I do within that block of time. The real leverage is better judgment. When focus is protected, decisions improve and more of the right work gets done.

Aligning Work With Energy

Another mistake I made for years was managing time as if I were a machine; treating hours as interchangeable. They aren’t. Time management breaks down when energy is ignored. Two hours of clear thinking is worth more than eight hours of depleted grind, especially in leadership roles where judgment matters more than output volume. I started paying attention to when I do my best thinking and deliberately protecting those windows for the hardest work. For me, that’s often in the morning. That’s when I try to do writing, strategic thinking, or complex problem-solving. Administrative work, reactive conversations, and lower-stakes tasks get pushed into lower-energy periods. Once I stopped pretending that all hours were equal, my days became less frantic and more intentional.

Deciding Once and Creating Defaults

One final pattern that quietly consumed far more time than I realized was re-deciding the same things over and over. This shows up as constant prioritization debates, meeting churn, and inbox thrash. The most effective leaders I’ve worked with don’t eliminate decisions. They eliminate repeat decisions.

I started paying attention to where this was happening and replacing ad hoc choices with defaults. Default meeting lengths. Clear ownership. Explicit decision rights. Agreed-upon rhythms for team and metric reviews and adjustment. When a decision was made, I established the future checkpoints where it would be revisited and resisted the urge to relitigate it, or deep dive on status updates. This kind of cadence thinking, popularized by Jeff Bezos and others, works because every default removes dozens of micro-decisions. Over time, that compounds: less noise, fewer interruptions, and more space for thinking and leadership.

The Hidden Constraint: Unclear Success

There’s a reason the practices above don’t stick for many otherwise capable leaders. It isn’t a lack of discipline, and it isn’t a failure of will. More often than not, it’s something quieter and more foundational: they don’t actually know how their success is being measured.

Time management systems assume clarity. They assume that you know what matters most, what good looks like, and where your effort creates disproportionate impact. When those assumptions hold, practices like blocking focus time, saying no, and creating defaults feel natural. When they don’t, those same practices feel brittle, uncomfortable, or even irresponsible. I’ve seen this pattern repeatedly. Leaders show up feeling overwhelmed, reactive, and stretched thin, convinced that their calendar is the problem. But as we start to unpack how they spend their time, it becomes clear that the deeper issue isn’t volume, it’s clarity. Without a clear sense of what success looks like, every request feels equally important. Responsiveness becomes a proxy for effectiveness. Busyness becomes a stand-in for progress.

In that context, chaos is understandable. If you don’t know what you’re optimizing for, the safest move is to stay active, visible, and available. It feels productive. It looks committed. But it rarely leads to the kind of impact or satisfaction people are seeking. Clear priorities are almost always a downstream signal of clear measures of success. When those measures are missing or ambiguous, prioritization turns into guesswork, decisions get revisited, and time fills with coordination, reassurance, and urgency theater. The practices meant to protect focus start to feel like indulgences rather than responsibilities. None of this requires a heavyweight framework to fix. It doesn’t have to start with a formal OKR process or a complex planning system. What it does require is an explicit articulation of what success means for you in your role. What are you accountable for? Where does your judgment matter most? What outcomes would make the year unambiguously successful?

For some leaders, the challenge is that these answers aren’t clearly established. This is especially common in technology leadership roles, where expectations can be poorly defined or shaped by people who don’t fully understand the work. When that’s the case, waiting for clarity to arrive rarely works. The more effective move is to take ownership of the definition. That can feel uncomfortable at first, but it’s also an opportunity. Define what your success looks like. Share it with your manager and peers. Explain how you plan to get there. Invite feedback and alignment. Once those measures are visible, time starts to behave differently. Decisions simplify, and tradeoffs become easier. The practices you’ve put in place finally have something solid to anchor to. Until that foundation is set, most attempts at time management are just rearranging deck chairs. Once it is clear, even imperfect practices begin to hold.

Integration: Why Holistic Success Matters

There’s one more layer beneath all of this, one that explains why time pressure can feel so relentless even when the right practices are in place. When progress is visible and momentum is clear, days feel manageable. When it isn’t, urgency creeps in, and anxiety rises. Every idle moment starts to feel like a liability. The calendar fills because stillness begins to feel unsafe.

Arthur Brooks uses the term strivers to describe achievement-driven people who are never quite satisfied; people who need to feel forward motion to feel grounded. I recognize that in myself, and I see it often in leaders I work with. For strivers, having clear goals, concrete actions, and measurable progress isn’t a nice-to-have. It’s how we orient ourselves. The challenge is that when all of that progress is concentrated in a single domain – usually work – the system becomes fragile. Any slowdown, ambiguity, or setback creates an outsized emotional response. Motivation falters and imposter syndrome creeps in. We compensate by doing more, responding faster, and filling time with activity, hoping motion will restore a sense of control.

This is where time management quietly turns into anxiety management. A holistic approach changes that dynamic. When progress exists in multiple dimensions of life – work, hobbies, relationships, physical health, mental health, and spiritual well-being – the pressure on any single domain eases. Work still matters, and excellence still matters, but it no longer has to carry the full weight of identity and self-worth.

That shift is stabilizing. It doesn’t make leaders softer or less ambitious. It makes them more resilient. With more than one path of progress available, strivers can feel forward motion even on days when work is slow, ambiguous, or simply hard. Decisions get clearer. Urgency loses its grip. Time stops feeling like something that’s constantly slipping away. The people we admire most tend to live this way, whether consciously or not. They move with confidence, not because they’re always winning at work, but because their sense of progress isn’t confined to a single scoreboard. They appear calm, motivated, and grounded because their lives are integrated, not optimized in isolation.

This is what makes all of the earlier practices durable. Owning your time, setting priorities, protecting focus, and defining success all work better when they’re supported by a life that can absorb uncertainty without collapsing into urgency. Time management, at its best, is about using your days in service of the life you actually want to live

Fundamentals First

When time feels scarce, it’s tempting to reach for tools, systems, or new habits. I share habits here that I have seen be game changers for myself and other leaders. But they only work once the fundamentals are in place. You have to be clear on what success looks like. You have to decide what deserves your attention. And you have to accept that your time will be shaped by something, whether by intention or by default.

Good time management is a collection of small, consistent practices built on clarity and ownership. When those practices are aligned with a broader, integrated life, they stop feeling rigid or forced. They simply become how you work and live. The goal isn’t to squeeze more out of your days. It’s to use the days you have in service of what actually matters. When that decision is made clearly, time stops being something you chase, and starts being something you steward.

Kevin Kelly, long-time editor of Wired and a self-described futurist, has long argued that the future will be made by optimists. I return to that line often. If Kelly is right about how progress happens, then optimism isn’t optional for leaders; it’s foundational. Every meaningful thing we’ve built, improved, or sustained began with a belief that improvement was possible. Progress does not happen accidentally. It begins when someone imagines a better state than the one they’re standing in, and decides it’s worth pursuing.

“The future will be made by optimists.” - Kevin Kelly

Kelly isn’t talking about optimism as attitude or personality. He’s describing a pattern he’s observed over decades: progress emerges when people believe systems can be improved, even when outcomes are uncertain and timelines are long. That idea is both liberating and unsettling. Liberating, because it affirms that progress is possible. Unsettling, because it quietly assigns responsibility. Opting out of optimism is not neutral. It’s a choice to leave the future to others.

What I mean by optimism

Words like optimism, pessimism, realism, and pragmatism get used loosely. When I use the word optimism, I’m not talking about blind positivity. I’m talking about agency. Optimism, as I see it, is confidence that problems are worth engaging. It’s the belief that improvement is possible, even when it is not guaranteed.

I consider myself an optimist precisely because I know problems will exist. I expect them. I also believe that problems can be solved, or at least transformed into something better than what came before. I often play the role of skeptic in conversations. I challenge ideas, question assumptions, and look for weaknesses in arguments. To some, that can sound pessimistic. To me, it’s the opposite. My skepticism is local, focused on challenging individual ideas to find stronger ones. It is rooted in a broader optimism that says if we surface the hard parts, think clearly, and stay honest long enough, we can make real progress.

Optimists guide the order of things

To create a better future, you first have to imagine it. Then you have to believe that it’s possible. Only after those steps do conviction, creativity, and persistence have anything to attach themselves to. Every advancement we benefit from today, whether technological or societal, began with someone encountering a problem and choosing not to accept it as permanent.

This matters in leadership because optimism shapes how people act under uncertainty. It influences whether leaders invest or retreat, experiment or freeze, or interpret setbacks as data rather than verdicts.

Imagine a world where every challenge is met with the belief that it is insurmountable. Problems would still be noticed. They would simply be avoided. Progress would stall almost immediately.

The same dynamic plays out in business. Over the course of my career, I’ve worked at startups from zero revenue through late-stage growth, and at large, successful public companies. All of them required optimism to move forward. That is especially true in startups, where teams operate with the conviction that something better than the status quo exists, even before there is proof. Building something new is filled with reasons to doubt: markets shift, products fail, and plans unravel. The people who drive meaningful change are the ones who wake up believing that today’s problems can be worked through, and that improvement is available. Each solved problem reveals the next one. That’s not failure. That’s the climb.

A note on techno-optimism

In recent years, “techno-optimism” has taken on a louder, more aggressive tone. Some versions frame technology as an unquestioned moral good, argue for maximum acceleration, and treat concerns about safety or governance as obstacles to progress. I understand why people are drawn to acceleration when systems feel slow or broken. That is not the optimism I’m talking about.

The optimism I speak of is grounded in pragmatism and responsibility. It starts with an honest assessment of risk and unintended consequences. It assumes that systems, guardrails, and trust matter. It is pro-building and human-centered. This is not optimism as ideology or growth at any cost. It is optimism as a leadership stance: imagining a better future, telling the truth about what stands in the way, and doing the daily work of moving toward that future on purpose.

Optimism is hard

It is genuinely difficult for many people to feel optimistic today. The world is full of real problems, and modern media environments are designed to amplify them. Bad news travels fast. It captures attention, and algorithms reward it. What’s harder to see is that much of human progress shows up as things that didn’t happen: diseases that no longer spread, famine that never materialized, accidents that were prevented. Those outcomes rarely make headlines. Optimism isn’t ignoring reality, it’s choosing how to engage with it.

While bad things often happen quickly, good things take time. When you step back and look at long-term measures such as life expectancy, child mortality, literacy, and access to food, medicine, and information, it’s difficult to find any 25-year period where the average human was better off than they are today. That doesn’t mean the benefits are distributed equally, that suffering has disappeared, or that risks are low. It means the baseline we’re standing on is the best humanity has managed to build so far. As a global society, we have made tremendous, if imperfect, progress. There is every reason to believe that progress can continue.

How I live as an optimist

On a personal level, I try to live as if a good future is worth investing in. I want a long, healthy life. I don’t expect to live to be 150 years old, and I don’t want to. The limits are part of what give life meaning. But I am optimistic that consistent effort, healthy habits, and modern medical knowledge can meaningfully extend healthspan and quality of life. That belief doesn’t make me complacent. It’s the reason I act.

Beyond myself, I try to contribute where I can. I mentor and guide people when I have the opportunity. I support causes I care about. I volunteer my time. I don’t expect to solve big problems alone. But I might help solve something small for someone else, and I take that seriously. As I move deeper into the second half of my life, that motivation has only grown. If I didn’t believe my choices, energy, and actions could make the world better for even a handful of people, I’m not sure how I would make sense of why I’m here at all.

Go forth as an optimist

Every goal we set and every system we build is rooted in an imagined future. We act because we believe that future is reachable.

As we begin 2026, I invite you to enter the new year with optimism. Look at yourself and consider the progress you want to see in your life. Believe progress is possible, then start taking actions in the right direction. In your work and with the teams you lead, model optimism. Don’t stop challenging the status quo, and don’t stop challenging ideas. But don’t be someone who only challenges, blocks, or tears down. Be the kind of leader who believes progress is available. Set the vision. Shape the plan. Expect setbacks. Keep driving forward.

Optimism isn’t a personality trait. It’s a practice. It’s choosing to engage with problems rather than turn away from them. Over time, that choice shapes teams, organizations, and futures. This is how progress is made.

Subscribe now

I’m not writing to perform. I’m not writing because I’ve figured it all out, or because I’ve determined the end. I’m writing as part of a journey, for myself first. My hope is that by walking this path openly, some of what I’m learning, questioning, and thinking about might help you in your professional life, your personal life, and your life as a whole.

Why I’m Writing

At the core of everything I do is a simple purpose: to help people find their purpose and reach their full potential. I’ve seen what happens when people do. I’ve lived it myself in moments. And I’ve also seen what happens when people don’t, when they stay stuck, disconnected from their strengths, uncertain about their direction, or playing smaller than they’re capable of.

Over the course of my career, I’ve been fortunate to experience a wide range of roles and environments. I’ve learned a lot, I’ve made mistakes, and I’ve grown in ways I didn’t anticipate. Over time, it’s become clear to me that much of that learning is only truly valuable if it’s shared.

Writing is one way I do that. But it’s also how I think. Writing helps me process ideas, test beliefs, reconcile experiences, and shape meaning. It’s how I slow down enough to notice patterns, and how I move forward with more clarity and intention.

Reach Your Full Potential

I believe deeply that reaching your full potential is the unlock for contentment and success, both professionally and personally. This process requires learning, introspection, discipline, and creativity. It requires a willingness to sit with discomfort, and perhaps most importantly, a willingness to accept a great responsibility: the responsibility of knowing that you can change the world around you.

That responsibility feels heavy. For leaders, this often shows up in the uncomfortable realization that waiting for alignment, permission, or certainty is itself a decision. It’s often easier to tell ourselves that things around us are fixed, circumstances, organizations, or other people are the limiting factor. Growth begins when we acknowledge our agency and recognize that our choices, habits, and perspective matter. Leadership, at its best, is an expression of that responsibility. It’s not about control or authority. It’s about influence, clarity, and service, starting with yourself.

My Own Climb

I’m entering what I describe as the fifth phase of my career. I won’t go deep into my phases in this post, but they matter in shaping how I see the work ahead. First came finding something I liked and was reasonably good at. Then growing as a software engineer, followed by developing into technical leadership. Then came senior leadership: learning how to operate systemically, how to build teams, and how to make decisions with second and third-order effects.

Each phase brought growth and each phase brought blind spots. Now I am entering into my fifth phase. What’s different now is this: I have found my purpose. That doesn’t mean I’ve arrived. I have a very long way to go in my own journey. But I now know what I want that journey to look like. A big part of it is walking alongside others, helping them clarify their path, strengthen their footing, and build the confidence to climb.

Writing to Integrate

I consume a lot of information. I always have. At any given time, I usually have two books going: one for pure pleasure, one focused on learning and growth, though that line is often fuzzy. I listen to podcasts. I read newsletters. I’m endlessly curious about how people think, build, lead, and live.

What I value most is synthesis, taking ideas in and applying them to my own life and work. Without writing, the ideas I consume feel like unwatered plants, full of potential but unable to take shape. Writing is the watering. It gives ideas room to grow. Not all of them are worthwhile; there are plenty of weeds. But among them, some meaningful and durable insights do emerge.

Writing is how I clear space. As Chase Jarvis says in Creative Calling, “stifled creativity is an enormous energy drain.” My mind is constantly full of big visions, small observations, half-formed questions, and competing ideas. At a certain point, that volume becomes noise. Writing moves thoughts from my head onto the page, where they can be examined, shaped, and prioritized. As that space opens up, clarity follows, direction sharpens, and I operate with more intention.

Over time, I’ve come to see creativity less as talent and more as attention. It’s a way of perceiving, a practice of noticing what’s usually invisible. Writing trains that awareness. It slows me down enough to see patterns across experiences and to reconcile belief with action. Connections that were implicit become explicit. Ideas that felt scattered begin to align.

Writing also builds discipline. Each time I sit down and create something from nothing, I reinforce a simple truth: I can make things happen. In The Creative Act: A Way of Being, Rick Rubin teaches that “to live as an artist is a way of being in the world. A way of perceiving. A practice of paying attention.” That idea matters far beyond writing. It shapes how I approach change, risk, and uncertainty in other parts of my life.

Sharing that writing adds another layer. It means accepting judgment and pushing past hesitation. In doing so, it changes how I relate to risk and opportunity more broadly. If I can put my thinking into the world openly and imperfectly, why wouldn’t I be willing to take bolder steps elsewhere? Writing becomes both a practice of clarity and a practice of courage.

Climbing Together

This is not a newsletter about hacks, shortcuts, or performative leadership. It’s a place for me to think out loud about leadership, growth, purpose, discipline, creativity, and what it really means to guide, yourself first, and then others.

A long climb is a journey, not a performance. That belief shapes how I approach leadership. And it shapes how I’ll approach this writing. I don’t know exactly where this path leads. I’m showing up to walk, to reflect, and to share what I’m learning along the way.

If you choose to join me, my hope is simple: that something here helps you take your next step on your climb, in your life, and in your leadership. If this resonates, I hope you’ll walk alongside me.

Welcome to The Leadership Climb.

Subscribe now