Framework - September 2026

How I Build Shared Purpose in a Technical Team

A security architecture team of thirty-six people spent a day working out what it was for. Here is how that worked, what my partner in it brought that I could not, and what changed afterward.

I built and led a security architecture organization of thirty-six architects, aligned to business and technology domains, accountable for architecture governance, review disciplines, technology standards and strategic planning.

They were good at the work. What I wanted was for them to be clear about what the work was for.

The problem this solves

That distinction comes from a pattern I have watched for most of my career, across two industries that could not matter more. Technical people get deep into the technology. It is genuinely interesting, and getting good at it is most of what the job rewards. But somewhere in that depth, a lot of very capable people lose the thread back to why the organization exists at all. In the energy sector, that thread is protecting our nation with reliable bulk electric power. In banking, it is protecting our country's financial infrastructure and our clients' financial future. Those are not slogans. They are the reason the funding exists and the reason the work is hard.

An architect connected to that makes different calls than one who is not. Not better technical calls necessarily, but better judgment about which problems deserve the effort, and about how to weigh real risk against what the business needs in order to grow. That balance is the work. An architect who only protects is as limited as one who only accommodates.

I wanted that connection made explicit, shared across the team, and owned by them rather than handed down by me. So I reached out to Sarah Updike for help.

I had watched her work with other teams inside the bank. What she does is hard to compress into a sentence, which is part of why she is good at it: some combination of how she reads a room, how she asks, and a communication style that makes people willing to say the true thing instead of the safe one. I had seen that work on groups with no particular reason to open up. I did not have to wonder whether she could do it with mine.

The method

We took a full day, in person, all of us. The method was the group process from Simon Sinek, David Mead and Peter Docker's Find Your Why, what the book calls a Tribe Why Discovery. There was no certification for it then. The book had only recently been published, so Sarah had built her own workshop guide to deliver it, and she ran it as a formal process rather than a conversation with a flip chart.

What surprised people was that it is built on stories rather than statements. The day turns on three conversations, held as a team: what we were proudest of, what we contribute, and what difference that contribution makes. You are not asked what the team's purpose is. You are asked to describe specific moments, particular ones rather than general. People share in small groups and report back. The room then looks for what recurs across all of it. Only then does anyone try to write a sentence, and the sentence is never written by committee: a small group drafts and the room reacts. Every part of that sequence exists to keep the answer from being invented by the most senior or the most articulate person present.

Two jobs, one room

Now consider what that asks of a room of senior architects. Tell a personal story. Say how it made you feel. Do it in front of thirty-five colleagues, most of whom you know professionally and some of whom you barely know at all. A good portion of that room had no intention of going first.

This is where the two of us did different jobs, and I think leaders get this wrong in both directions.

The facilitation had to be hers. Not because I lacked interest, but because the outcome had to belong to the team. If I run the process and ask thirty-six people what they believe, I will hear some version of what they think I want. Sarah owned the method and she owned the neutrality, and that is what made the answer trustworthy.

But handing her the room and sitting down would have been its own failure. I knew these people. I knew who would fill a silence and who would let one sit, and I knew which of the quiet ones had the story the room needed to hear. So I stayed in it. I led a good deal of the discussion, drew people in by name, asked the second question when someone gave a three-word answer, and kept working at the part of the room that had not yet decided to participate.

That is the part worth taking away if you take away nothing else. A facilitator who pretends to understand your domain loses a technical room in the first hour. One who says plainly that she does not, and asks the leader to cover that ground, earns it instead. That only works if the leader shows up to do that job.

By the end, the ones who had been holding back at the start were arguing about word choice with everyone else.

Nested, not invented

We were not writing a purpose for the bank. The bank has one. We were finding ours inside it.

A team inside a large enterprise does not get to declare an independent reason for existing, and any statement that reads as though it does is a statement the enterprise will eventually reject. What we were looking for was narrower and more useful: the specific contribution this team makes to a purpose that already exists above it.

I am not going to reproduce the sentence we landed on. It belonged to that team, in that company, at that time, and it would read as boilerplate out of context anyway. The shape of it is the part that transfers.

We did not stop at the sentence, and this is the part I would insist on if I did it again. A purpose statement on its own is a poster. The work that follows is translating it into behavior: what we would do differently in a design review, how we would say no when no was the right answer, what we would take to a business partner before they thought to ask for it. That work is slower and far less satisfying than the day itself, and it is the part that determines whether any of it survives contact with a Monday.

What changed

What changed divided cleanly into two groups, and the split is the reason I would do it again.

Some people on the team had been struggling, not with competence but with connection. They could not see the line from a standards document to anything a customer or a banker experienced. After that day they could. The work did not change. What changed was that they understood which business problem they were solving and which opportunity they were helping the company take. That is the difference between an architect who enforces a standard and one who explains it.

The others, the ones who already worked that way by instinct, came out with resolve. They had been operating from a purpose they had never heard anyone else articulate. Now they had language for it, and they knew the rest of the team shared it. Focus sharpened. Delivery came from a shared place rather than thirty-six individual ones.

Sarah and I ran the session again later, with a much larger organization I had moved on to lead, and the method held the second time.

If you lead technical people, the odds are good that some of them could not tell you what your organization is actually for in a way that connects to what they will do on Tuesday. That is not a character flaw and it is not a lack of commitment. It is what deep specialization does. But it is worth addressing, because a team that can make that connection makes better calls about what matters, argues about the right things, and is markedly harder to knock off course. You can hope it develops on its own, or you can spend a day on it with someone who knows how to run that day.

The partner who made it work

None of this happens without Sarah Updike, who at the time led the people's side of change inside the same organization.

I have sat through a lot of offsites. What made this one different was not enthusiasm, it was craft. She ran a formal method rather than a conversation with a flip chart, held thirty-six people inside it across a full day, and created the kind of room where people who do not volunteer things were willing to. She also made it easy to work alongside her, which is rarer than it sounds: she owned the process and left me room to do the part only the leader can do. Thirty-six architects walked out owning something instead of tolerating it, and they thought a great deal of her for it. That is the whole game in change work.

She now runs Updike Coaching and Change, working with organizations on the people's side of change and with the practitioners who carry it. If your team needs to move and you want a partner rather than a deck, partner with Sarah. updikecoaching.com

Back to How I Work