Momentum Leadership Summit 2026 · Group 3

Turning execution into a competitive advantage

Koddi's ability to sense the market, make fast decisions, and build strong partnerships is a real differentiator — but there's a persistent gap between that speed of intention and the quality and consistency of what we actually deliver. Customer expectations are high, delivery is sometimes inconsistent, ownership isn't always clear, and the same friction points appear across initiatives and quarters. Closing this gap permanently — making Koddi as reliable in its execution as it is strong in its strategy — is what translates our position into growth.

Group 3: Boaz · Brenna · Bryce · Chris · Christie · Eric · Jason · Nanda · Tasha · Trevor · Tyler

0
Leaders across programs, product, engineering, and customer success on Group 3
0
Recommendation areas every working group brings to senior leadership
0
Active initiatives selected to pilot the new execution standard in the first 30 days
30·60·90
Day path from pilot initiatives to company-wide adoption

Our opportunity

Koddi's ability to sense the market, make fast decisions, and build strong partnerships is a source of real differentiation. The feedback from our leaders also reflects a persistent gap between that speed of intention and the quality and consistency of what we actually deliver. Customer expectations are high, delivery is sometimes inconsistent, ownership is not always clear, and the same friction points appear across initiatives and quarters.

The opportunity isn't just operational improvement, it's competitive. Closing this gap permanently — making Koddi as reliable in its execution as it is strong in its strategy — is what translates our position into growth.

Our primary assignment question: What would it take to make Koddi's execution as strong as our strategy — where every major initiative has a clear owner, a clear outcome, and a clear standard for what done looks like?

Where we're starting

  • 1No defined outcome, no commitment — every major initiative needs an accountable owner, a measurable outcome, and an explicit definition of done before it starts.
  • 2"Done" means two things — customers actively use and are delighted by the solution, and it generates sustainable revenue or margin.
  • 3Organize around end-to-end projects, not services or customers — no more hole cutters and light fixture installers.
  • 4Every urgent priority must name what it displaces — strategic capacity is protected, not silently spent.
  • 5Customer validation — not technical launch — is what closes an initiative.
01
1
Section 01

Two or three high-impact actions

A clear, shared definition of "done"

No defined outcome, no commitment. Before a major or cross-functional initiative becomes active, it must have:

  1. One accountable owner with decision authority.
  2. A measurable customer or business outcome.
  3. An explicit definition of done.
  4. A delivery scope and target date.
  5. The capacity source, including what will stop or move.
  6. Clear readiness requirements covering validation, reliability, observability, supportability, and repeatability.
  7. The accountable owner remains responsible through customer validation, not merely through launch.

Done means two things: 1) clients actively use the solution and are delighted by the experience and outcomes, and 2) the solution generates sustainable revenue and margin — new revenue, cost savings, or revenue protection. Today that's applied inconsistently, because teams use their own functional definition of completion.

How this connects to customers

This closes the gap between what we believe we delivered and what the customer actually experiences. It improves adoption, reduces post-launch disappointment, accelerates revenue, and gives customers greater confidence in our commitments.

Our commitment

We will roll this definition out and hold ourselves and our teams accountable to it.

A project-based ownership framework

We will reorganize our product, engineering, and customer-facing teams around projects, not specific services or customers. Teams will tackle projects end to end — no more hole cutters and light fixture installers. Teams have complete ownership over the ultimate customer outcome and are expected to understand it and be able to verify it empirically.

Project documentation sits alongside product documentation:

  • Project — summarizes the customer ask, details, and potential risks. Owner: CS / Programs teams.
  • Product — summarizes the changes to our product, isolated as durable platform capabilities. Owner: Product / Engineering teams.
How this connects to customers

Customers experience Koddi as one company, not a collection of services, functions, or internal teams. Organizing around end-to-end projects gives each initiative a team that owns the full result, from understanding the customer need through delivery, adoption, validation, and business impact.

Our commitment

We will organize product, engineering, program, and customer-facing teams around end-to-end projects with one clearly accountable owner for the ultimate customer outcome. We will maintain one visible list of active priorities and available capacity, and review it weekly.

Two or three specific behaviors we're changing — start, stop, continue

Start: enforcing development gates that require the right planning information up front. If it's not met, the team gathers the required information before the project continues; if capacity is delayed as a result, the full delayed team participates in defining the correct information. Initial emphasis is on quality of documentation, rather than leadership enforcement of accuracy.

Stop: allowing urgent work to consume that capacity without making the tradeoff explicit and establishing when the team returns to the strategic work. This can happen in retro for critical items, but the work must be re-planned and re-communicated based on the change in priorities and capacity.

How this connects to customers

Customers will experience fewer surprises, more reliable launches, and clearer communication about what will be delivered and when. Better planning and protected execution capacity will reduce rework, prevent recurring issues, and help us turn customer needs into durable capabilities. Our goal is not to add process — it's to give customers greater confidence that when Koddi commits, we will deliver a complete, reliable, and supportable outcome.

Our commitment

We will not begin or continue major work without the information required to execute it well. We will establish clear development gates, validate readiness before launch, and make tradeoffs visible when urgent work disrupts the plan.

02
2
Section 02

The leadership ownership required

30-day ownership

OwnerWhat they're accountable for
Senior leadership teamApprove priorities, capacity guardrails, and tradeoffs.
Operating-model ownerBuild the execution contract, priority view, and weekly review.
Outcome ownersComplete and operate the contracts for the pilot initiatives.
Product & engineering leadersConfirm platform strategy, readiness, reliability, and observability.
Customer leadersConfirm customer requirements, adoption, validation, and business outcomes.

What senior leadership needs to model differently

Fewer simultaneous priorities, one accountable owner, no drive-by requests, explicit capacity tradeoffs, respect for delegated decision rights, and inspection of customer outcomes rather than activity. Leaders must accept that adding a priority means removing or delaying another. It's fine to disagree on priorities — but we cannot change them without working it through the plan.

Holding leaders personally accountable

By the 90-day mark, each senior leader reports on:

  • Priorities they introduced or changed.
  • Tradeoffs they made.
  • Work they stopped or simplified.
  • Commitments that missed, and why.
  • The customer outcomes their initiatives produced.
03
3
Section 03

Key decisions for senior leadership

These are the calls we're asking our senior leadership team to make — not decisions Group 3 can or should make on its own:

  1. Approve the definition of "done" as a company-wide standard, applied across engineering, product, and customer-facing teams — with the accountable owner responsible through customer validation, not merely through launch.
  2. Approve reorganizing product, engineering, and customer-facing teams around end-to-end projects rather than services or customers — while holding off on a broad organizational redesign until 60-day pilot evidence is reviewed.
  3. Approve a single, visible priority-and-capacity list that senior leadership reviews weekly, where new or urgent work only becomes active once it states the outcome, names the owner, identifies what it displaces, and records the consequence of that tradeoff. If those decisions aren't made, the new request does not become active work.
  4. Decide how every bespoke, customer-specific request gets classified: build as durable platform capability, approve as a funded and time-bound exception with an expiration date, or decline or defer.
  5. Decide where dedicated project teams are justified once 60-day pilot evidence is in, versus where clearer ownership alone is sufficient.
04
4
Section 04

Measures of progress and success

Measures of execution quality that go beyond shipping — customer validation, reliability, repeatability, and observability:

  • Timeline hit rate — how many projects were marked "done" by the date we originally defined.
  • Roadmap achievement in quarter — the percentage of projects achieved in the quarter against what was originally defined.
  • Client feature happiness — an NPS-style score on feature acceptance post-release.
  • Alert / error rate for core services.

At 30 days, we establish a baseline for: unplanned work as a percentage of capacity; commitments completed against the full definition of done; post-launch defects and support escalations; and time from technical launch to customer validation. By 90 days, the scorecard needs to show improvement against that baseline across execution reliability, protected strategic capacity, post-launch quality, and time to customer value — and customer validation, not technical launch, is what's used to close an initiative.

05
5
Section 05

A 30-, 60-, and 90-day path forward

HorizonFocusEvidence
30 Days Create one execution standard and apply it to three active pilot initiatives, each with a one-page customer outcome (problem, owner, scope, definition of done, validation and adoption requirements, reliability and support requirements, and capacity source). Create one visible priority and capacity list. Begin a weekly execution review focused on decisions, not status updates. Three pilots operating under complete execution contracts, each with one accountable owner; one visible priority and capacity list reviewed weekly; one urgent-response rotation operating; baselines established for unplanned work, definition-of-done completion, post-launch defects, and time-to-validation; zero new pilot priorities without a documented capacity tradeoff.
60 Days Enforce "no defined outcome, no commitment" and "no new priority without a swap." Run formal launch-readiness reviews. Classify every bespoke request. Evaluate the project-based team model — without beginning a broad organizational redesign until the pilot evidence is reviewed. Every pilot initiative has passed the required planning and readiness gates; every priority change has a documented capacity tradeoff; every bespoke request in the pilot has been classified; every missed commitment has a root-cause owner and corrective action; leadership publishes the first execution scorecard and identifies behavior changes still required.
90 Days Extend the standard to all critical initiatives, major customer commitments, integrations, and material platform investments. Institutionalize the priority-and-capacity mechanism. Embed the standard into existing tools and meetings, and eliminate duplicate documents and status meetings that don't produce decisions. Publish a monthly execution-quality scorecard and hold leaders personally accountable. All critical initiatives operate under the shared execution standard; zero new critical initiatives begin without an owner, outcome, definition of done, and capacity source; zero priority changes occur without an explicit tradeoff; customer validation — not technical launch — is used to close initiatives; the scorecard shows improvement from the 30-day baseline; leadership has made an evidence-based decision on where to adopt dedicated project teams permanently.

Routine status reporting happens before the meeting. The weekly execution review itself is for decisions, not updates.

What the launch-readiness gate actually checks

Before launch, the outcome owner confirms: customer requirements and success criteria are validated; dependencies and material risks are resolved; reliability and monitoring are in place; customer-facing and support teams are ready; post-launch ownership is named; and the validation period and evidence required to declare "done" are clear. Missing customer validation, ownership, capacity, or success criteria stops the work until resolved — the gate tests decision quality and readiness, not the length or polish of the documentation.

06
6
Section 06

Important dependencies across the other workstream

This workstream doesn't operate in isolation — the 30-day ownership model itself names the functions this depends on:

  • Product & engineering leaders need to confirm platform strategy, readiness, reliability, and observability for every pilot initiative.
  • Customer leaders need to confirm customer requirements, adoption, validation, and business outcomes before an initiative is considered done.
  • People & Culture is a named partner in the rollout — clarifying roles and expectations, preparing managers to lead through the change, addressing talent and capacity risks, and reinforcing the accountability and behaviors needed for adoption.

The project-based reorganization is itself a structural dependency: it's proposed as a recommendation here, but a broad organizational redesign is explicitly gated on reviewing 60-day pilot evidence first — not something Group 3 is proposing to decide unilaterally. Any other workstream touching team structure, roles, or org design should expect this pilot evidence to inform that decision.

07
7
Section 07

What we should stop, simplify, or do differently

Stop tolerating

  • Initiatives without one accountable owner.
  • Commitments without clear outcomes or success criteria.
  • "Shipped" being treated as "done" without validation.
  • Repeated failures without root-cause ownership.
  • Missed commitments that are communicated too late.
  • Escalation used as a substitute for decision-making.
  • Hole cutters vs. light fixture installers.

Stop doing entirely

  • Starting work before aligning on the customer need, scope, owner, and definition of done.
  • Making customer commitments without confirming delivery readiness.
  • Silently reprioritizing strategic work for every urgent request.
  • Building repeated one-off solutions without deciding whether they should become platform capabilities.
  • Treating handoffs as the end of accountability.
  • Launching without monitoring, support, and post-launch ownership.
Simply put: stop accepting ambiguity, and stop beginning work without the conditions required to finish it well. Shift decisions left, and document the plan and the commitments.

What capacity this frees up

We'll eliminate duplicate project documents, status meetings, and reporting that don't produce decisions, and quantify the capacity that removing them frees up. Routine status reporting moves before the meeting; the meeting itself is reserved for decisions. And by naming what every urgent priority displaces before it's accepted, we stop strategic work from quietly slowing down because people were pulled onto something else — the tradeoff becomes visible instead of invisible.

08
8
Section 08

A specific personal commitment from each member

Not the team. Not the function. Here's what each of us is personally committing to changing, starting the week after we leave Dallas:

Team memberCommitment
ChrisI will dedicate my time and Program's team capacity to improve launch validation, post-launch monitoring, and customer value communication.
NandaI will no longer accept shipped as done; every Tier 1 initiative must define its customer outcome, validation evidence, operating standards, and accountable owner before development begins, which I will review weekly. Within 30 days, all active initiatives will meet this standard and remain open until results are validated.
EricI will not create drive-by priorities. When I introduce or support urgent work, I will clearly state the customer outcome, name the owner, identify what it replaces, and own the consequences of that decision.
JasonI will be more active & vocal in the final acceptance and initial definition process for K1 projects, representing the voice of clients.
TylerI will commit that Program owners (PM, TPM) are responsible for documenting client projects independent of product/engineering scopes, and define the template and organizational structure for the team to use.
BryceI will run all project management and ensure clear communication on status, changes, and releases.
BrennaI will champion customer readiness alongside launch readiness. Before we declare success, I'll ensure our customer-facing teams understand the value, know how to position it, and have what they need to drive adoption and customer outcomes.
TashaI will work with P&C to partner with the business to clarify roles and expectations, prepare managers to lead through change, address talent and capacity risks, and reinforce the accountability and behaviors needed for successful adoption.
BoazI will hold the line on planning and execution gates and ensure every initiative has one accountable owner, a clear customer outcome, and a definition of done.
TrevorI will maintain a list of 5 key projects I am personally monitoring at any given time and will share a written weekly update in #leadership and #kads-directors on how each is going, risks, input needed, and potential capacity tradeoffs.
ChristieI will prioritize accountability for my client's initiatives, owning documentation around the client ask, details, feedback, potential risks, and ensuring overall visibility and alignment across the mission team.
The bottom line

Conclusion

The issue is not that Koddi lacks urgency, talent, or willingness to work. The issue is that we allow commitments to enter and change without forcing clarity, capacity, and end-to-end accountability.

Simply put: stop accepting ambiguity, and stop beginning work without the conditions required to finish it well. Shift decisions left, and document the plan and the commitments.

Our standard for every recommendation: will this create a meaningful and visible change in how we lead, execute, develop our people, or deliver value to customers? If the answer is yes, we have the foundation for action.