5. The Shape of the Work
The best teams are as intentional about how they build as they are about what they build.
Every product team talks about outcomes—what we are building, why we are building it, and how we are going to build it. If the goal is ambiguous, it’s difficult to understand who you need to fill the seats of those who will be building it. The goal of a healthy executive team is to understand and communicate the vision in broad strokes. This can be end-goal products, feature suggestions, and/or engagement or sales lift.
We can’t build out a budget or understand time and effort if we don’t know the goal, or if the goal seems to always move.
The Shape of the Work Shapes the Team
At Sonic Drive-In, from the start, the goal was clear: omnichannel experiences to drive sales, reduce operational overhead, and increase digital engagement. We were to figure out how to build and deliver a digital-first ordering experience.
The executive team, in particular the Marketing leadership, had created a vision video that showed a Drive-In of the future with all sorts of crazy ordering flows with social tie-ins, and cringeworthy dialogue. The script read like a soap opera, and the implementation was very much movie magic, but it did one thing very well… It put in the minds of our entire company—from operations to technology and, more importantly, our Franchisees—a vision for what could be. That we were swinging for something GAMECHANGING, and not just an e-commerce app.
The goal was to build a uniquely SONIC experience!
The team started small. We had a vision, we had a runway, and we needed some wins. In the first couple of years of work within this new trajectory, it was evident that the vision was being communicated, but the culture was not there, because we had the wrong team in place. Not an indictment on the people—more a critique of the transformation needed to move in the right direction.
The shape of the work shapes the team. We needed more builders and fewer project managers. Team leads who were better suited to lead through complexity and build strong teams than to organize and communicate with outsourced vendors and agencies. Sonic had, like many companies, a tendency to outsource the delivery of technology and digital capabilities.
On Outsourcing and Ownership
There is a quiet but persistent debate within most delivery organizations about how much of the work should be kept in-house and how much should be offloaded, whether to agencies, vendors, or overseas contracts. On paper, the logic is straightforward: full-time employees are expensive, and if the work is a temporary spin-up—intended to get a feature out the door or satisfy a regulatory requirement—then the cleanest path may be to contract the labor, pay the invoice, and move on. This is the more efficient path, and it reduces HR involvement in layoffs or reorgs. And, perhaps most importantly, it creates a layer of distance between the core team and the risk of failure.
Maybe I’m saying the quiet part out loud here, but when something goes wrong with a vendor, it’s rarely viewed as a failure of leadership. It’s a sourcing problem. A procurement process to be optimized, as the vendor was chosen through an RFP process, and the contract decision was made by a committee. It was scored, weighted, and justified by objective logic. So if the vendor underdelivers, if the product is late, or the quality is poor, the fault is absorbed by the system. The failure belongs to the process, not the person. No one’s job is at risk, and the team moves on.
But when the same failure happens in-house—when the people who own the roadmap also own the implementation—there’s no place to hide. The failure has a known cause that can be attributed to specific seats. The organization cannot ignore the failure; to maintain control of the project and talking points to the board, it has to reckon with it. And that, more than anything, is why internal teams are often held to a higher standard than external ones. Because when we keep the work, we also keep the consequences.
To be clear, outsourcing is not inherently a bad strategy. There are legitimate reasons to use it: cost, speed, specialization, and security. And there are projects where internal ownership would be the wrong move, where the overhead would outweigh the value. But it’s worth naming what is often left unsaid: that outsourcing doesn’t just externalize the work. It externalizes the risk, creating a dynamic where accountability can be diffused, and where the integrity of the process is harder to assess because the team doing the work isn’t the one carrying the vision.
This isn’t a moral argument. It’s a framing one. Because if culture is a product, then we have to pay attention to the relational and structural dynamics of how the work gets done, not just who gets credit when it succeeds.
Outsource Innovation At Your Own Risk
One caveat to the outsourcing conversation is a lesson I’ve learned the hard way. I was once asked to step into a project where an outsourced entity had been paid a significant amount of money to deliver a solution, only to find it three years behind schedule, mired in legal trouble, and (to top it off) unpaid for the past six months.
At that point in the project, do you think we were getting their best staff? Of course not. Not even close.
The team had asked an external vendor—one that didn’t understand the culture, the context, or the stakes—to deliver the most innovative project the organization had ever attempted.
That’s a recipe for disaster.
After that experience, I formed strong opinions about when and how to outsource innovation. If you are thinking about outsourcing innovation, don’t.
If you want to innovate, you need to separate the artists from the soldiers, the innovators from the operators. You’ll want to, at the start, keep your innovation team small and nimble, and choose an Executive to be the Innovation whisperer—that is, the person responsible for managing the transfer of knowledge from Operations to Innovation, and vice versa. This person should be in lock-step with the strategic plan of the business and have strong relationships with the leaders in operations, marketing, and technology. This proximity creates a multiplying effect—stronger connections, tighter communication, faster iteration.
If you need more reasons to avoid outsourcing innovation, here are a few:
1. Institutional knowledge takes too long to transfer.
An outsourced team, no matter how talented, starts behind. The time required just to get up to speed is often months. By the time they start building, the window of opportunity has already narrowed.
2. Communication gets layered.
The more layers between idea and implementation, the more risk you introduce: misalignment, miscommunication, misplaced urgency. Especially with time zones, language differences, and cultural nuance—the delays can stack.
3. Knowledge doesn’t stay.
With external teams, the knowledge leaves when the contract ends. Or worse, it stays locked in with a junior support team billing high maintenance fees. If you're asking about the SLA during a crisis, you’re already dead in the water.
4. Internal teams are faster and smarter.
Internal teams know the rhythms, landmines, and shortcuts. Communication is faster by default. Institutional learning compounds.
5. The builders are the best fixers.
Innovation isn’t a fixed deliverable—it’s a living process. The people closest to the work are the ones best equipped to respond with speed and care.
Outsourcing as a Strategy
Outsourcing is sometimes necessary when the project is large and the timeline is tight. Consider near-shore outsourcing for easier collaboration.
At Sonic Drive-In, our timelines on Order Ahead were tight. With 3600 stores receiving new hardware, software delivery had to track with the installation schedule.
Our solution: outsource the delivery, not the leadership.
We increased team size from 12 to 120, and started strategically hiring full-time members as the project matured. By launch, we had around 45 internal members maintaining what the larger outsourced team had built from 0-1.
The investment was huge—but it paid off. Order Ahead was delivered in less than two years, in lock-step with hardware rollout. Together, software and hardware (ICE - Integrated Customer Experience) drove a 19% increase in sales, far greater than the 3% lift we had forecasted. The system scaled to support $1M+ days and a record of $4.8M in one day of sales.
The work mattered. But the people mattered more.
This was a team win. As we celebrated on the fourth floor of Sonic HQ in Bricktown, I remember exchanging nods and air-fives with the team. The executives were on stage, but the gladiators were in the chairs.
Cultural Traction: Why, What, & How
When a project fails, Product Managers often carry the blame. When it succeeds, the team gets the praise. Our role is influence without coercion. Which means we must cultivate cultural traction—that quiet alignment where people understand the why, feel ownership of the what, and trust each other enough to shape the how.
A product lead moves between departments to ensure the team has the information, space, and ownership to deliver. Sometimes that means pace setting—scouting ahead, pulling the team forward, pushing the executive tempo. But pace setting is exhausting, and risky without executive cover.
More often, a good product lead adopts a shepherding posture—strategically placed behind or within the team, nudging it gently toward the goal, while avoiding pitfalls.
I like this metaphor because I spent my childhood on a farm, raising sheep. And there’s a misconception: sheep aren’t dumb. They’re easily spooked. Just like teams.
Shepherds use two tools:
- The double-hooked cane – The large hook for steering, the small hook for pulling to the ground before shearing.
- The slingshot – Not for punishment, but for redirection and protection.
Product leads must nudge teams away from apathy or ignorance by consistently beating the drum of vision, values, and constraints. That’s how we build rhythm.
Product is responsible for articulating the what and the why, then empowering the team to shape the how. Like a shepherd with a slingshot, the tools we carry are not for control—they’re for momentum and protection.
A few tools I lean on:
- Product briefs — Not just what we’re building, but why it matters.
- Personas — Who it’s for and what it solves.
- Constraint Framing — Innovation thrives at the edges of the box.
- Timeboxed Exploration — Bandwidth for the team to explore new approaches.
- Figma Kickoff — Contextual orientation around the solution.
- Agile Rituals — Daily standups, sprint planning, retrospectives.
- Demos — Code walkthroughs to align expectations.
- War Room — High-intensity collaboration during crises. Focus on mean-time-to-recovery.
- Scrum of Scrums — Alignment across large, interdependent teams.
- Relationships — Maintain informal trust lines. Not for politics—for alignment.
None of these work without trust. But in the hands of an intuitive product leader, they can turn chaos into forward motion.