Is any transformative change ever truly “done”? Or do we simply reach a point where the steering committee exhales, the org charts stop multiplying and a shiny, new priority hits our desks?

If you’ve spent time around agile teams, you know they are fond of a few practical concepts: prioritize people over process, respond to change over worshipping the plan and avoid pretending that a slick, 47-slide roadmap is the same thing as progress.

Those ideas translate well to organizational design. After all, org design is complex, human, political, iterative and occasionally held together by sticky notes and one brave person willing to ask, “Wait, who actually owns this decision?”

One agile concept I especially love for org design is the Definition of Done. In Scrum, the Definition of Done is the shared quality standard an increment must meet before it can be considered complete, usable and ready for inspection or release.

Org design needs the same discipline. Without a shared Definition of Done, teams can spend weeks polishing boxes and lines without really knowing when enough is enough.

Why “Done” Gets Weird in Org Design

In software development, “done” might mean the feature is tested, integrated, documented and ready to be released. In org design, “done” is more slippery. Is it done when the future-state model is approved? Announced? When employees know what changes when they show up on Monday morning? Or is it only ‘done’ when employees are successfully working in their new roles, with new responsibilities?

The answer, inconveniently, is yes. And also, it depends.

A strong Definition of Done creates transparency. It gives the design team, sponsors and stakeholders a shared understanding of what “complete enough to move forward” actually means.  

What “Done” Might Mean

For an organization design effort, a practical way to get to Definition of Done might include aligning on a few key questions:

• When we say the design is complete, what will be true in the organization?
• What would a leader or employee experience that tells them the new design is working?
• What are you assuming is happening when we say this transformation is complete?
• What would not be acceptable to call done?
• What needs to be in place for you to confidently step away from this and trust it will sustain?
• Have all areas of our organization been aligned around our central strategy?

When moving from design to implementation, these questions can help the project team draw the chalk line of what is done vs. what is required maintenance.

Why “Done” Matters

Having a definition of done does not automatically guarantee success. It does, however, establish a shared standard the team can point to and say, with confidence, “This is coherent, communicable, and ready to sustain.” Without that standard, it’s all too easy for “done” to become wherever you land when priorities shift or the redesign team runs out of steam.

The value is straightforward:

• Clarity over guesswork. It replaces “we’ll know it when we see it” with questions the team has already answered together.
• Protection for your people. It ends the cycle of endless polishing.
• Protection for your design. It prevents work from being declared finished before it can stand on its own.

This discipline only grows more critical as transformations move toward smaller, continuous shifts. When change never fully stops, clear milestones become essential, defining when to pause, assess and reset before the next adjustment.

The bottom line is, define your “done” before you begin. Document it. Align on it explicitly. The alternative is not flexibility; it’s confusion.