Go energy vs. stop energy on Microsoft 365 projects
“On a [technology] project, you have 6 go people and 60 stop people.”
I heard this line a few months ago from Sludge, Part 2: Is Government the Problem, or the Solution?, and it's stuck with me since.
The host on the podcast interviewed an expert product leader, Jennifer Pahlka who worked with the US government on a technology project for the IRS: the IRS Direct File project. For this project, a small team was tasked with delivering an automated tax service to lower-income people. A great idea! But they were also surrounded by a well-meaning team whose primary job is to tell them "no." The project stalled and was eventually cancelled.1
This isn't a problem unique to government. It's an organizational problem and a leadership problem. When driving any kind of change, such as AI adoption, digital transformation, or a simple process improvement, there's a tension between "go energy" and "stop energy."
Understanding this balance can help unlock progress on stalled projects. This article explores how I’m thinking about this concept in the context of Microsoft 365 and SharePoint projects.
What is Go Energy vs. Stop Energy?
Let’s start with defining go vs. stop energy:
Go energy is when people focus on delivery. These are your product teams, your innovators, the people who wake up thinking about how to make something happen. They have a bias toward action, they're outcome-focused, and they're willing to take calculated risks to get things done.
Stop energy comes from people whose role is to slow things down or prevent things from happening. Teams that come to mind are security teams, legal, compliance, finance, procurement. They're risk-averse, process-focused, and they act as gatekeepers.
To be clear: Stop people aren't the problem. They're necessary. We need security. We need compliance. We need risk management. The problem isn't that these people exist, the problem is the ratio.
When you have 60 people whose job is to tell you what you can't do and only 6 people whose job is to actually deliver, you've got a structural problem. And that's not the fault of those 60 people, that's a leadership problem.
Pahlka puts it well:
"Those 60 people are well-intentioned and often very thorough, very bright, very dedicated public servants. I mean them no disrespect. It's not their fault that there's 60 of them and 6 people trying to deliver the product. That's a problem of leadership.”
A Case Study: Microsoft 365 cleanup project
I’m going to use this framework to analyze a case study of a typical Microsoft 365 clean up project. This is based on my experience working with organizations in regulated industries, such as government or insurance, who have decided to tackle their messy SharePoint, Teams and OneDrive sprawl issues.
The situation:
Years of unchecked document creation
Abandoned team sites
Duplicate files in across SharePoint sites and Onedrive's
Outdated policies sitting next to current ones
ROT (Redundant, Obsolete, and Trivial) content eating up storage costs and creating compliance risk.
They've also recently rolled out Microsoft Copilot, and people were complaining it wasn't helpful. In other organizations I've seen Copilot launched, but then IT blocks all SharePoint sites and OneDrives, dramatically reducing the utility of Copilot!
It makes sense why this happens.
Turns out when you ask Copilot to pull information from SharePoint and it's sifting through 15 versions of the same policy document from different years, plus a bunch of draft files that were never finalized, plus meeting notes from projects that got canceled in 2017...it's going to give you irrelevant answers. The AI tools everyone was excited about couldn't work well because the underlying data was a mess.
On top of it all, it's common to throw more money at the problem. I've seen an organization spend roughly $400K annually on storage, but they didn't actually know how much of that was ROT that could be deleted. This the Catch 22: it's hard to inventory the content without either the automated tooling (which they haven't bought yet) or massive human effort (which they don't want to fund). It's a frustrating catch-22.
Lastly, there's the regulatory risk. In some cases, organizations are breaking the law if audits find retention policy violations.
The company wants to invest in automated tooling, maybe with AI, and with records management to clean it up.
The go energy
So based on this situation, here's how I see the go energy on this situation or possible cleanup project:
A records management team of 3 people who have been advocating for this for years
An IT director who found a promising AI-powered classification and cleanup tool for Microsoft 365 content
A frustrated compliance officer who wanted the regulatory risk gone
A clear vendor, a reasonable price tag, and some ideas for ROI including productivity gains
The stop energy
But then came the stop energy:
Executives want a formal business case with detailed ROI analysis and three-year projections. But how do you project ROI when you can't measure the current problem without the tool you're trying to buy? The records team spent two months interviewing teams, building models based on estimates and assumptions, knowing full well the numbers were soft.
Legal want a risk assessment. What if the tool deleted something important? They needed protocols for review, approval workflows, and an appeals process. Add a couple more months.
Security needs thorough evaluation on any tooling or vendors. Penetration testing, security questionnaires, architecture reviews. Another two months.
Compliance wants to understand how the AI classification worked. Could they audit the decisions? What about bias? They needed the vendor to explain their algorithms and provide accuracy metrics. Two more months.
IT plans to pilot it, but only in one department. But which department? That required executive buy-in, so they scheduled steering committee meetings. The committee met monthly. A few weeks later, they picked the Permits department.
By the time they were ready to pilot, the original records management champion had left the company. The compliance officer who pushed for it had moved to a different role. The IT director was focused on other priorities.
Eighteen months after the initial proposal, they ran a 90-day pilot in Permits. It worked well. Then they needed to do another business case to expand beyond Permits. Executives wanted updated ROI numbers based on the pilot results. Another round of Request for Proposals was needed to expand beyond the pilot.
One and a half years after starting, the project eventually stalled. The executive sponsor retired. The budget got reallocated. The SharePoint sprawl is still there.
Tweaks to the schedule by adding in more go energy might have helped. The legitimate stop energy (security reviews, compliance validation) could have been done in parallel with the pilot. But the layers of approval, the sequential decision-making, the risk aversion that demanded perfect information before any action—that's what killed it.
The few people with go energy were drowned out by the organizational default to stop. Not because anyone was malicious or incompetent, but because the ratio was off and no leader stepped in to rebalance it.
Source: Unsplash
How Do You Reverse the Ratio?
You don't need to fire people or blow up your org chart. What needs to shift is what's rewarded, what's measured, and where energy is focused.
When your next AI or technology initiative stalls, don't immediately blame the technology or the people. Look at the ratio. Look at where the energy is going.
Leaders make a choice every day about whether to add another approval layer or empower teams to move faster. I think it starts there—with how leaders show up and the choices they make.
More often than not, it's productive for leaders to show up with go energy. In practice, this means staying focused and articulating all the reasons why something will work versus the 100 reasons it won't. In my cynical moments, I sometimes think that leaders believe it's their primary job to kill projects. That's stop energy dressed up as strategic thinking.
Reward the behavior you seek. If you want tech projects to launch, reward that. Don't punish teams when things don't go perfectly—keep showing up with go energy to help people adopt the change.
→ For more practical advice for tech leaders, see a related article on good enough change management.
Now, I don't think you need to audit all the go energy versus stop energy people on a project. You could certainly do it, and if you see a high ratio like 60 versus 6, you might want to try flipping it. Change people's roles or focus on hiring for more go energy.
In reality, most people are a mix of go and stop energy. It's not either/or. As Jennifer Pahlka writes on her article Stop Making People Do the Wrong Jobs:
“Of course, every great employee is some mix of these energies – a “go only” employee would be exhausting and dangerous in all but the most extreme circumstances – so we’re talking about a general orientation. More importantly, having fewer brakers will only result in enormous backlogs if they have the same stopping power. But there are plenty of functions where its possible to safely move from default no to default yes, possibly with an after the fact correction mechanism....it’s still worth considering the value of moving to default yes processes where appropriate.”
Focus on changing processes, having systems in place to fix things when there's a compliance issue or an AI classification tool that doesn't do everything perfectly out of the gate, but you can get to ‘good enough.’
Of course, there are circumstances where the stakes are high, the risk is high and you need have more checks or 'stop energy.'
Finding the balance is my point!
Conclusion: A Leadership Choice
The 6 vs. 60 problem isn't inevitable. It's a choice.
Leaders decide what gets rewarded. They decide what gets measured. They decide how many approvals are needed. They decide whether the default orientation is "let's figure out how to make this work" or "let's figure out why this won't work."
If tech initiatives keep stalling, this is what I’m asking myself on projects that I lead:
First: What's the ratio of go energy to stop energy on this project?
Then: am I adding to the go energy or the stop energy?
The answer to that question might determine whether your next project actually launches or just becomes another cautionary tale about why change is hard.