PILLAR · COMMON GOAL · ALIGNMENT

The Common Goal Framework: a WHY and a WHAT, written down

What managers call team alignment is one term short. A Common Goal is two things — a WHY and a WHAT, written down — not one.

BY EVAN HICKOK
·
JUNE 14, 2026
·
11 MIN READ
·
FILED IN ALIGNMENT

The transformation team met for the first time on a Tuesday afternoon.

Eight of us, in a conference room with a giant TV and the camera COVID had foisted on us and a whiteboard somebody had forgotten to erase. The agenda was one bullet: fix R1. I looked around — these guys were giants to me. They had so much experience, and reputations for getting the toughest things done. I thought, am I one of the giants now? Either way, I was so excited I volunteered for this.

R1 had been a smoldering dumpster fire for a couple of years. It was rated red on cost, schedule, and staffing. Everything but technical — but some thought that was just because we hadn’t yet done much testing, and once we did, that would flip red as well.

I had just taken on a department that staffed half of the sixty-person project. I had met with each of my employees and had a pretty good picture of what was wrong and some ideas of what we could do — but I was even more interested in what the seniors in the room thought could be done. Then I caught the eye of another senior manager who gave me a look that said do you know why we are here?

Everyone in the room described how various things being done on their project could translate to this one and some interesting ideas surfaced. But there was nobody taking notes and I was wondering — who is leading this? How will we decide which of these ideas we’ll pursue? Do they already know what I know? I was waiting for someone to ask me for my opinion, as I had such a significant portion of the team and inherited much of the staffing gap that had us red. In ninety minutes, no one asked.

The meeting started with a bang but adjourned with a whimper. Nobody left with an action item. Nobody had been named to lead. No one had written down what success would look like. We had not even agreed on what was in the scope of fix. The meeting ended the way that kind of meeting ends — people standing up, gathering their laptops, saying good discussion on the way out the door.

I walked back to my desk and sat down, wondering what I should be doing now.

The hundred-page wish

Two major themes emerged from the one-on-ones I held with my team. The first was an uneven distribution of work — some people barely had work, others were drowning. The second was a confusion over the actual point of the project.

Why was the work spread so unevenly?

Many would be sitting around waiting for tasks, then they’d receive something with no context of how this fit into the larger picture. The leads delegating to them complained about that same work — it was incomplete and the lead would have to fix it. The pattern was clear: the busy people were the leads who could describe what the project was doing; the not-busy people could not.

Why didn’t everyone have the same idea of what this project was doing?

R1 had a program plan. In just over one hundred pages, it described the program in considerable detail — scope, schedule, requirements, interfaces. In our domain, a program plan is a charter by another name. It is the foundational document that codifies what the team is there to do.

I asked my staff if they had read the program plan. They had not. I asked why, and they pointed out it was unsigned. Why read something that was still in draft? It was hard to argue with that point.

Why wasn’t it signed? Because the customer and the project leaders had never sat across from each other and confirmed that what was written was what both of them understood. The scope on paper had never been ratified by the people responsible for delivering it. But some sixty people were working on this project at a labor cost around $1M per month. Each of those sixty people had a fuzzy, varying idea of the ultimate goal.

A hundred pages of unconfirmed scope is not a charter. It is a very long wish.

This felt very wrong to me, but none of the seniors had mentioned it in the meeting. These guys know how things get done; my opinion was never solicited. Was I wrong to think it was a big deal?

I had a conversation with the Director first. He had thirty-seven years of experience. He was energetic and approachable. We had a great relationship. I described what I was seeing — the uneven workload, the uncoordinated actions, the absence of a shared goal. The program plan / charter needed to get signed to ensure this $1M/month of labor cost was pointing in the intended direction.

I added that we needed someone formally assigned to lead this transformation, and that, too, should have a signed charter. He looked at me with the expression I have come to recognize in the years since: the look of someone who believes the problem you are describing is probably real but does not want to add it to their plate. He did not disagree. He just did not act.

I was struck by the irony — the team we were to transform had an unsigned charter, and I couldn’t get anyone to charter the transformation team either. The blind leading the blind.

Ben, my manager, found the whole situation so chaotic he eventually concluded he did not want any part of it. He resigned. I was disappointed. He was a really smart guy, and I had gathered some friends from the area to meet him and his family for dinner to show what a great place he was moving to if he signed on.

My next conversation was with Jeremy, the manager who replaced Ben — someone I’d known for years, smart and ambitious, genuinely committed to the mission. Feeling under-qualified to make this recommendation on my own, I tried borrowing authority and mentioned the PMBOK, the Project Management Body of Knowledge, as a reference point for what a project charter was supposed to accomplish:

The project charter is the document issued by the project initiator or sponsor that formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities. It documents the high-level information on the project and on the product, service, or result the project is intended to satisfy, such as: project purpose, objectives…
Project Management Body of Knowledge, 6th Edition

He looked at me and said, without any particular embarrassment: “I don’t even know what the PMBOK is.”

I do not say that to criticize him. He had been promoted quickly. He had succeeded through intelligence and drive. Nobody had ever handed him a formal framework for how projects should be organized. He was not underqualified so much as he was undertrained. Like most of us in that room. We were, in the language of the research, accidental managers.[1][2] The charter was not a tool anyone in that room had been taught to use. So when I kept bringing it up, it sounded less like a solution and more like a pet idea from someone who read too many HBR articles.

I eventually stopped. I concluded, quietly and with some embarrassment, that the charter must be a bad idea. I was the only person in the room who kept returning to it. That many smart people could not be wrong.

Could they?

A Common Goal is two things

The two halves of a Common Goal are not interchangeable. Peter Senge gave me the clearest picture I could find. In The Fifth Discipline, he drew the effort of an individual as a vector — an arrow with a length and a direction.

If this were running, the length of the arrow would be proportional to their speed and the direction of the arrow would indicate their direction of travel. With work, the length of an individual’s arrow is roughly proportional to their productivity, or their commitment to a particular idea. And the direction is toward whatever they think is the right thing to concentrate that effort on.

And then a team’s vector, shown by a larger arrow wrapped around the individuals’ arrows, is the sum of the vectors within it.

When individual intent points in a hundred directions — as when people don’t have the same idea of what it is they are collaborating on — the net resultant of that team is short.

When the intent of the individuals is aligned to a shared purpose, the same people produce a resultant that is long, unambiguous, and strong. The leader does not have to push the team as much as the leader has to establish the direction.

And they do this in a WHAT and a WHY.

EXHIBIT A · SENGE 1990
Two-panel diagram. Left panel: six figures with arrows in scattered directions, drawn in ink on a cream background. No outer arrow shape — there is no team vector yet. Right panel: a large red chevron arrow containing six figures whose arrows all point straight up, parallel to the chevron. Above the chevron tip, a small gold downward-pointing marker labeled WHY · WHAT in Courier.
Six people, the same total effort — only the direction is different. Without a Common Goal, there is no team vector to draw: individuals work hard in directions that cancel. With a Common Goal, the team vector emerges — the red arrow IS the sum of the individual vectors, made visible by their alignment. The leader does not push the team; the leader establishes the direction. After Peter Senge, The Fifth Discipline (Doubleday, 1990), ch. 9.

The Finite and Infinite Goal

James P. Carse gave us the structural rule for how to write that direction down. There are two kinds of games, Carse wrote: finite games, played to win, with a beginning, an end, and a winner; and infinite games, played to continue the play, with no finish line. And then the rule:

Finite games can be played within an infinite game, but an infinite game cannot be played within a finite game.

JAMES P. CARSE · FINITE AND INFINITE GAMES, FREE PRESS, 1986

That is not a philosophical observation. It is operational. Finite goals must nest inside infinite purpose — evaluated against it, constrained by it, discarded when they betray it. The moment a finite goal rises above the infinite purpose it was meant to serve, the organization begins to drift. Not because execution fails — because execution detaches from direction.

The WHY — the purpose that does not complete. The WHY is the unifying account of why the work matters. It is not a quarterly objective. It is a continuity claim: a statement of what must remain true. I speak about personal purpose in my essay The Power of Purpose.

The WHAT — the deliverable that does. The WHAT is bounded, measurable, completable. It nests inside the WHY.

For instance, John F. Kennedy gave the original WHY for the space program when he described the famous moon shot at Rice University in September 1962: “Space can be explored and mastered without feeding the fires of war.” Infinite. Ungameable. You never fully arrive. We are still pursuing it in 2026. And nested inside that WHY was the WHAT: “I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the Earth.” Notice the constraint built into the WHAT — returning him safely — which was not rhetorical. Rather, it was the condition that governed every engineering decision the program of 400,000 people would make for the next eight years. That WHAT was completed. The WHY we are still pursuing.

And Brian Fairbank, the owner of a small ski mountain in Western Massachusetts, eventually wrote his down: “Jiminy strongly believes in preserving the earth for future generations.” But before he made it explicit on their Sustainability web page, he had used the implicit infinite goal to drive his decisions for fifty years — installing flushless urinals, cogeneration plants, and a wind turbine which, together, reduced their $1M annual energy bill to $0. → How to take the long view in business: the Jiminy Peak forever goal.

Likewise, the U-2 program — one of the most consequential intelligence operations in American history — was proposed in a six-page, 1,500-word memo. A WHY (we cannot fulfill our responsibility for maintaining the peace if we are left in ignorance of Russian activity) and a WHAT (fly at 70,000 feet, out of reach of present Russian interception, and photograph in revealing detail a strip of Russia 200 miles wide by 2,500 miles long), in proper hierarchy. Six pages — one of the most consequential intelligence programs ever launched, and an airplane still flying today, 70 years later.

I was reading Jon Gertner’s book The Idea Factory, about Bell Labs (which I believe perfected the team-based invention model Thomas Edison pioneered), and I was struck to read him cite the transistor project — initiated with Authorization for Work Case 38139, signed June 21, 1945 by Harvey Fletcher, Jim Fisk, and Mervin Kelly — the project that produced the working transistor in December 1947, and with it the computer revolution. I wrote to an AT&T Bell Labs archivist and she sent me this very copy of history. I felt completely vindicated by this document — I had not put my finger on such a clear example of a charter in the wild before.

Its companion in the Bell Labs archive, Case 38338, was signed ten months later — chartered to engineer H. I. Beardsley — and commissioned the 500-type telephone set, the black desktop instrument that launched in 1949, stayed in production for fifty years, and became arguably the most-produced telephone in history. Twelve features specified, anticipated completion 1948, one name on every approval line.

Each of these Bell Labs Authorizations for Work shows its WHY and WHAT in proper hierarchy. And you’ll note the signatures — these are signed by both the delegator and the delegatee. A mutual agreement of the scope and the resources. That is what a charter looks like.

The test — clear, challenging, consequential

A Common Goal that actually governs a team meets three conditions. J. Richard Hackman, a fellow team researcher, named them:

  • clear, so members orient toward the same purpose;
  • challenging, so the work generates collective motivation; and
  • consequential, so members invest the full complement of their knowledge and skill.

A goal that fails any of the three will not truly govern.

The diagram of a label

EXHIBIT B · R1, BY PHASE
Venn diagram. Three overlapping circles labeled Design, Production, and Installation. Scope items A, B, C in the three-way intersection. D and F in Production only. E, G, H in the Production-Installation overlap. The label R1 sits in the upper right of the panel, outside all three circles.
The same name. Three different bodies of scope. No three-way intersection. Under PMBOK, this is not the diagram of a project — it is the diagram of a label.

Here is what the framework told me, that I could not see at the time.

R1 had a WHY. The mission it served, the customer it supported — both were real and well-understood. That shared purpose held people together through years of difficulty. The team knew why they were there.

R1 did not have a WHAT. Not a precise one. The project had three different definitions of itself depending on which phase you stood in. In design, R1 meant scope items A, B, and C. In production, R1 meant A, B, C, D, E, F, G, H — five additional items absorbed from other projects, but it was still called R1. In installation, R1 meant A, B, C, E, G, and H — D and F had been absorbed into a different program entirely. Three rooms, three definitions of R1.

(I think this is one of the reasons my bids for a charter went unheard. The leadership I was speaking with had tried to wrap their head around the project, and when they could not, they concluded that was a level of detail they need not understand. But when properly described, we can see how simple this truly should have been.)

Every conversation, whether with the PM or an IC, began with a level-set on which version of R1 we were talking about today. People were proud of their ability to remember what went where. It was one of the reasons the program plan had not been signed — the scope was so confusing that people couldn’t quite figure out how to write it down. Each person on the project had to try to memorize the scope puzzle but, with no definitive answer key, this led to a constant, unresolvable debate.

This all consumed brain power they should have been spending solving the engineering problems the scope demanded.

Worse: there was nobody coordinating the actions of the ICs who were receiving tasks from each of R1’s projects. Requirements documents for a subsystem would be changed by B, then changed again by C, and nobody merging to ensure the subsystem itself was cohesive and functioning.

Under the project-management framework everyone in the room nominally followed, R1 did not even qualify as a project. PMBOK’s Section 1.1 defines a project as “a temporary endeavor undertaken to create a unique product, service, or result.” The key word is unique — one result. R1 had three different results depending on which phase you were standing in, and none of the three could be delivered to the customer or user without other pieces of the larger program that were not under R1’s authority. The name did not point to a unique result.

And it did not point to a Program either — PMBOK defines a Program as “a group of related projects, subsidiary programs, and program activities that are managed in a coordinated manner to obtain benefits not available from managing them individually.” There was no single integrator above the components ensuring coordination and integration into a final thing.

So it was neither a project nor a program, says the textbook. It’s no wonder it had no charter.

The charter is a fundamental instrument, and it was missing.

Well, not missing, I guess. The document existed — all hundred pages of it. But it was unusable.

Had this been properly structured to the boring textbook definitions of a project or a program, the next step would be bilateral confirmation. The moment where the project sponsor (in this case the customer) and the lead sit across from each other and ratify, on the record, that what is written is what both of them understand.

Then the scope debates can end, because it’s actually documented. There is an answer key.

Think about how a restaurant order works. You tell the server what you want. They read it back. If they misheard how many appetizers you ordered, you catch it there — not when the wrong food arrives and the money is already spent. The confirmation is not bureaucracy. It is the moment where both parties hear each other clearly enough to prevent an expensive mistake. The food that arrives at the table is satisfying precisely because the order was confirmed before anyone started cooking.

A signed charter is that confirmation. Both the sponsor and the lead confirm the scope, authority, and resources (people, material, money, time, etc.). If either one is surprised by what is in the document, that surprise belongs at the table — not six months later when the kitchen has been cooking the wrong dish. Or, in the case of R1, spending $1M/month on labor.

That gap cost years. It cost the program in delivered scope, and it cost the people inside it in other ways too — including, downstream of this room, a team boundary that ended up putting one engineer named Steve in charge of two unrelated subsystems, because nobody upstream had defined the work with enough precision to draw the boundary differently. → Bounded — Well-Structured.

The charter does not replace the vision. It carries it. It ensures the clarity in your head is written down somewhere that survives you leaving the room.

The Through Line RETURN 1 / 3
Precision without purpose is energy without direction.
Evan’s notebook, circa 2024

When the WHY drifts

Sonos founded itself on a WHY clean enough to be carved in stone: music lovers should be able to play any song, in any room, with great sound and no wires. For two decades it governed. The mesh network, the proprietary patents, the obsessive ease-of-setup — every finite project nested inside the infinite promise.

Mashable called Sonos setup “a master class in out-of-the-box simplicity.”[3] This reputation brought them to 16.3 million households by 2024 — and those households returned to buy again and again, until each household held an average of 3.1 products.[4]

Then the math of running a hardware company without subscription revenue caught up. The CEO committed the organization to releasing at least two new hardware products per year. It was a reasonable answer to a real constraint. The board approved. The analysts applauded.

But the way they structured this, they put their WHAT above the WHY — violating Carse’s rule that an infinite goal must be above a finite goal. This subtle error put their course just two degrees off from their intended target.

A flight from Boston to Los Angeles is 2,600 miles. Two degrees of departure error, uncorrected, lands you 350 miles from your destination. You were precise the entire flight. You were never accurate. By June 2024, when Sonos’s May app update enabled the Ace headphones and broke the platform that fifty million devices depended on, the cockpit instruments still read on course — two new products, on schedule, on budget. The plane was 350 miles from Los Angeles.

The drift was not a single decision. It was the quiet accumulation of finite goals that nobody checked against the infinite purpose they were supposed to serve. → The Sonos Collapse.

When the WHAT lacks precision

I like to look at this WHY/WHAT through an analogy I learned in my early days working in quality assurance. In QA, we make a distinction between Precision and Accuracy. When we are accurate, we are consistently close to where we aim. If this were darts, we’d measure our accuracy by measuring the distance from each dart to the bullseye. Precision is a measure of repeatability — the distance between the darts themselves. We can have low accuracy and high precision, and we can have high accuracy and low precision. They look like this:

EXHIBIT C · ACCURACY × PRECISION
Four red-and-cream concentric-ring dartboards in a 2×2 grid. Accuracy increases up; precision increases right. Top-left: loose darts around bullseye (High Accuracy, Low Precision). Top-right: tight cluster on bullseye (High Accuracy, High Precision). Bottom-left: darts scattered (Low Accuracy, Low Precision). Bottom-right: tight cluster off-target (Low Accuracy, High Precision).
Four targets, four outcomes. Precision is how tight the cluster is. Accuracy is whether the cluster lands on the bullseye. A team can be one without the other — and most failure modes are exactly that asymmetry.

Execution is pretty hard, and much harder without a clear goal. At best, without a clearly defined goal, we’ll get Low Accuracy, Low Precision. To get High Accuracy, High Precision — like Apollo, like Jiminy Peak — we need to clearly define the goal in both a WHAT and a WHY, and also nail execution.

If we fail to set the WHAT but are aligned on the WHY, our dispersion may be in the Low/Low quadrant if we are lucky. But in the case of Sonos, their WHAT (Launch Ace) was executed at the expense of their WHY (music lovers should be able to play any song, in any room, with great sound and no wires).

And so they looked more like this. Notice the Sonos cluster isn’t just off-center; it’s off the target altogether. Their execution was tight; they were aiming at a target outside their own WHY.

To launch Ace, Sonos had to rearchitect their entire cloud. And that rearchitecture caused millions of previously sold hardware items to not work very well. They didn’t treat the rearchitecture with the same importance as launching Ace. And two years later, the Reddit forums are still full of complaints because it’s still not quite fixed. They can no longer play any song in any room with great sound and no wires.

The Through Line RETURN 2 / 3
Precision without purpose is energy without direction.
Evan’s notebook, circa 2024

The reframe

Come back to R1.

The Director was not lazy. Ben was not weak. Jeremy was not unqualified. The hundred-page program plan was not a bad document. The team that stood up to fix the program was not the wrong group of people. I was not the only one who saw the problem.

But the Common Goal had never been written down in a form the team could survive without any single person in the room.

That is the reframe. A Common Goal is two things, not one — a WHY that must remain true, and a WHAT that gets shipped. The teams that name only the WHY drift, because finite goals detach from infinite purpose and the cockpit instruments still read on course. The teams that name only the WHAT execute precisely toward the wrong target, because no one ever asked whether the target was right. The teams that name both, and write both down, and ratify both with a signature — those teams compound. Their finite wins nest inside an infinite purpose, and their infinite purpose is anchored by finite wins that actually shipped.

Precision without purpose is Drucker’s warning made real: doing with great efficiency something that should not be done at all.

PRACTITIONER’S GUIDE

How to apply this on Monday

Diagnosis — how to tell team alignment isn’t governing. Four tells that the Common Goal exists on paper but not in practice.

One — ask three people on the team, separately, what is our number-one goal right now? If the answers do not match, the goal is not shared.

Two — the same program name means different bodies of scope in different rooms. The Venn diagram problem.

Three — finite goals (launches, releases, quarterly OKRs) get celebrated without anyone asking whether they served the infinite purpose. The cockpit reads on course; the plane is 350 miles off.

Four — the foundational document — call it a charter, call it a program plan, call it a one-pager — exists but has never been signed by both the sponsor and the lead. A hundred pages of unconfirmed scope is not a charter.

Installation — how to write the Common Goal down so it survives the room. Start with the WHY. One sentence. Continuity claim, not quarterly objective. Music lovers should be able to play any song, in any room, with great sound and no wires. Follow the same play Kennedy used to write the original moonshot WHY — the JFK Play in 3 steps. He did it in 35 days. You can do it in two weeks.

Remember: if the sentence completes when the next release ships, it is a WHAT in WHY clothing — rewrite it. Then write the WHAT. Bounded, measurable, completable. Build the constraint into the sentence the way Kennedy built returning him safely into the moonshot.

You can run this play the long way or use AI as a partner.

Run Hackman’s test: clear, challenging, consequential. If any of the three is missing, the goal will not govern. Then — and this is the move people skip — sit across the table from your sponsor and read it back the way the server reads back the dinner order. Confirm the resources. Confirm the priority. Sign it. Date it. Distribute it. The document is real when both parties’ signatures are on it.

Navigation without authority — how to be the person in the room who keeps asking.

Have the data. “I am seeing divergence in how the team defines R1” is harder to dismiss than “this feels off.” Draw the picture — the Venn diagram, the org chart, the timeline with the missing signature — because a problem you cannot draw, you have not yet defined. Borrow vocabulary if you must (PMBOK, Hackman, Carse, this article) and stop when it stops working. Offer the smallest possible version of the fix: not rewrite the program plan, but get the existing plan signed. And if the room still does not move, write down the date you offered the fix. The document becomes the receipt when the goal later fails to govern.

Write the goal down

The manager’s real job is to write the goal down in a form the team can survive without you in the room — a WHY infinite enough to never complete, a WHAT precise enough to ship, both of them ratified by the two people whose signatures matter.

On this side of the boundary, you decide what the work is for and what it produces. On the next side — where Common Goal ends and Bounded begins — you decide who owns it. And on the side after that — Interdependent — you design how the work crosses the boundaries you just drew. The three conditions are different problems. Most managers conflate them. Common Goal is upstream. Get it wrong here, and the people downstream will be solving the wrong problem precisely. → Bounded — Well-Structured · Interdependent — Psychological Safety

A team has a Common Goal when every member can answer two questions and get the same answer — what are we building, and why does it matter — and when both answers have been written down somewhere the team can read in your absence. Get that, and the team’s energy compounds. Get it wrong, and even the best people in the room will execute precisely toward a target nobody confirmed was the right one.

The Through Line RETURN 3 / 3
Precision without purpose is energy without direction.
Evan’s notebook, circa 2024
References
  1. [1]Chartered Management Institute, Taking Responsibility: Why UK PLC Needs Better Managers, research report (CMI, 2023). managers.org.uk/wp-content/uploads/2023/10/CMI_BMB_GoodManagment_Report.pdf
  2. [2]William Arruda, “Why Most New Managers Fail and How to Prevent It,” Forbes, February 15, 2023. forbes.com/sites/williamarruda/2023/02/15/why-most-new-managers-fail-and-how-to-prevent-it/
  3. [3]Mashable, “The Story Behind the Wireless Music System 10 Years in the Making,” December 8, 2011. mashable.com/archive/how-sonos-works
  4. [4]Sonos, Inc., Form 10-K: Annual Report Pursuant to Section 13 or 15(d), U.S. Securities and Exchange Commission, 2024. sec.gov/Archives/edgar/data/0001314727/000131472724000026/sono-20240928.htm

Discover more from Lighthouse Leadership

Subscribe now to keep reading and get access to the full archive.

Continue reading