Inside a Broken Team: What We Found, What We Fixed
If you’ve ever looked at a team and thought, “They’re better than this, why can’t they get anything out the door?” this one’s for you. Sometimes (I’d argue about 70% of the time) it’s not about the people. It’s not even about the work. It’s about the systems, or lack thereof, those people are trying to operate in.
When we were brought in, this engineering team wasn’t just struggling—it was stuck. On paper, they had everything they needed: smart engineers, a product team with big ideas, and a design team ready to ship. But in practice, small features were taking six months to launch. Not big, meaty, complex features. Not full rebuilds. We’re talking about basic functionality that should’ve taken a sprint or two, not half a year.
The CEO had written them off. He told us, “They’re not the type of engineers who build things. They’re more of a maintenance team.”
Which, frankly, is one of the goofiest takes we’ve ever heard. Software engineers love building things. They want to make progress. But you can’t build momentum when you’re stuck in a fog of bad communication, unclear ownership, and zero structure.
Here’s what we found and how we helped them fix it.
What We Found
1. Everyone was hearing a different story
The product manager, well-intentioned but chaotic, was telling different engineers different things. There was no single source of truth, no documentation, and no ticketing system to track progress or decisions. This wasn’t strategy. It was a game of telephone.
Engineers would start building something, only to have it scrapped or rewritten two weeks later because the PM had updated the direction……but only told half the team.
2. Nothing was written down
No epics. No user stories. No roadmap. Not even a consistent backlog. Every “feature” lived in someone’s head or in a random Slack thread from three weeks ago. Engineers didn’t know what to prioritize. Design didn’t know when to hand things off. Product didn’t know what was being worked on.
So of course things weren’t shipping. There was no actual path forward, just a mess of crossed wires.
3. No operating rhythm
They weren’t doing Agile, or Scrum, or even a vaguely regular planning process. There were no retros, no sprint planning, no standups. Communication happened reactively, usually in DMs. Work happened sporadically, based on who happened to have the loudest ask at the time.
This team wasn’t broken because they didn’t have talent. It was broken because no one had ever taught them how to operate as a team.
What We Fixed
1. Created a shared source of truth
First up: ticketing system. We implemented a simple but clean structure using the tools they already had (in this case, Jira and Notion). Every request from product had to be written down, groomed, and prioritized.
No more verbal direction. No more mystery work. Just clean, trackable tickets with context, dependencies, and clear definitions of done.
2. Clarified communication paths
The PM was asked—kindly but firmly—to stop having side conversations that rewrote scope without telling the rest of the team. All product requests had to go through the shared system, and any changes required a group check-in.
This wasn’t about punishing spontaneity. It was about protecting the team’s time, clarity, and progress. Engineers finally had space to focus, and it showed.
3. Introduced a lightweight Agile process
We didn’t bulldoze the team with full-blown SAFe or a 40-slide Scrum pitch. We just gave them a basic rhythm: weekly planning, daily standups, biweekly retros. Let that settle with the team, get them comfortable with it, then adjust as necessary.
Suddenly, the team had a pulse. They could see their own progress. They knew what to work on, how to collaborate, and when to ask for help. Features started getting shipped faster than ever before.
4. Helped leadership reframe their expectations
We coached the CEO through some of his…..less-than-spectacular takes. We showed him the before and after. And, to his credit, once he saw the improvement he changed his tune.
“This team isn’t slow,” he said, “they just needed structure.”
We know. :)
What Happened Next
Within eight weeks, this team was shipping regularly. Not just shipping faster, but shipping smarter. They were working more collaboratively, scoping better, and finally felt like part of a larger system, not a group of order-takers at the bottom of the org chart.
The product team was happier. Design felt heard. And the engineers? They got to build again, to the point where they became the most productive team in company history.
The Threadsmith Group Approach
Sometimes, a broken team doesn’t need a complete overhaul. Sometimes, they just need someone to come in, clear the fog, and help them find their footing again.
That’s what we do.
At The Threadsmith Group, we don’t believe in band-aid fixes. We believe in building systems that support people, not bury them. Whether you’ve got a team that’s falling behind, a leadership gap that needs closing, or just a whole lot of misalignment with no clear root cause—we can help.
Let’s get your team unstuck.