Cross-Functional Teams vs. Feature Factories: What's Actually Different?

Hello there. Welcome back to Engineering Involved. My name is Tom. I am your host for today. Today we're tackling something I see confused constantly in the product world.

The difference between truly cross functional teams and what I call feature factories in disguise. This matters because I've worked with dozens of organisations that proudly declare that they've gone agile and they've reorganised into cross functional teams. Six months later, they're still grinding out features with no real ownership, no outcomes, definitely no innovation. They've changed their org chart, but not the operating model. Today, we're going break down what actually makes a team cross functional, the red flags that you're still running a feature factory, and most importantly, what you can do about it.

Because I'm going to share measurement frameworks that you can start using on Monday. Let's dive in.

Welcome to engineering evolved, where business meets innovation and technology drives transformation. Each episode, your host, Tom Barber, explores the challenges and opportunities facing the organizations in the middle, the forgotten ground where startup rules no longer apply and enterprise playbooks are far too large. From scaling systems and leading teams to aligning engineering with business goals. This is where practical insight meets real world experience. Engineering evolved, guiding today's leaders through the evolution of engineering.

So for those of you who don't know what actually is a feature factory? What do we mean by feature factory? The term was coined by John Cutler and it describes organizations that measure success by shipping features, not outcomes. Feature factories are obsessed with velocity, with story points completed and releases shipped. And the roadmap is as long a long list of features usually dictated from above and the teams just build what they're told.

Loads of places operate like this and it's not necessarily, it's definitely not necessarily, it's not even remotely the most effective way to operate. So here's the thing that trips people up. Feature factories can have cross functional teams on paper. You might have developers, designers, QA and a product manager all sitting in vaguely the same office space or at least on the same team schools. But if they're just executing a predetermined backlog with no real decision making power and no connection to outcomes, you're still running a feature factory.

So what are the three hallmarks of a feature factory? In a feature factory, success is measured by what you ship, not what you achieve and the performance review mentions how many story points you completed not whether you moved conversion rates or reduced churn. I worked with fintech companies over the years where their team celebrates hitting sprint commitments many quarters in a row which sounds impressive except customer satisfaction declines and they were building features that nobody wanted except the factory kept on humming and so no one saw the red flags. Hallmark number two of a feature factory is that there's no real autonomy in the group. The teams have no real decision making power and sure, they might decide how to build something but they don't get to decide what to build or why it matters.

And this is called autonomy theatre. Leadership says you're empowered, but then hands you a detailed roadmap that's already been committed to investors. And that's not autonomy. That's just outsourcing implementation. So you end up with two very distinct groups, one of which is the leadership who are deciding what features are getting built, what the roadmap for that looks like, what the timelines, who cares what the actual developers think.

And then you've got the developers who then take that and then have to turn that into something that's actually implementable. Is that a word? I think it's a word. But they have no real autonomy. They have no pushback.

They have no way of declaring that that isn't going to work for them. And so that's just like an outsourcing group that works happens to be on the same payroll. Hallmark number three of a feature factory is whether or not it's stakeholder driven and not mission driven. So in feature factories, a roadmap is driven by whoever shouts the loudest. And I'm sure we've all been there.

Sales want this feature for a big deal. Marketing needs a feature for a campaign. The CEO saw something at a conference. The team becomes an order taker, jumping from request to request with no coherent strategy. There's no clear mission.

There's no target customer segment, no measurable outcome of the thing that they're actually trying to achieve. Smart companies still run feature factories. Smart people build these by mistake. It usually starts with reasonably good intentions and you need to coordinate across multiple teams. You need to move faster.

You read about Spotify's model and think we should organize around squads. So you reorganise around squads. You put people into teams, you call them cross functional and you think you're done. But you didn't change how the decisions got made. You just changed how the success is measured.

You didn't give teams a mission or outcomes to own. You just rearranged the furniture within your organisation. Of course, the result, you have all the overhead of a team based structure with none of the benefits. So what actually makes a team cross functional? And it's not about the disciplines, it's about capability.

Here's the biggest misconception though. People think cross functional teams means has all the disciplines And so they make sure that each team has a designer and some engineers, maybe a data person. But that's not necessarily sufficient. True cross functionality is about capability. Can this team independently deliver value to customers without constantly escalating to other teams or stakeholders?

Let me try and give you a bit of a concrete example. Say you've got a company that wants to reorganise into cross functional teams And then you've got one team that's responsible for payments. So on paper, they look like a cross functional team where you've got a number of engineers, a product manager, a designer, and a data analyst. But here's what they may not be able to do. They can't change pricing without legal approval, which takes weeks.

You couldn't run experiments on checkout flows without approval from a VP of product who thinks about things slightly differently. They can't change how payment errors are displayed because that was controlled by a different team and they couldn't analyse conversion data because those requests need to come from the data platform team. So were they actually cross functional? Not really. They were dependent on a team that needed permission for everything meaningful.

And so if you take an example like that where people can shop with inside of their boundaries, make difference, but they can't actually go and run experiments or test different things. It's not a cross functional team. They can't make those executive decisions. And so this is where that misconception lies. So what do you end up with?

The five capabilities of true cross functional teams. So based on patterns that you can see across many organisations, there's five different capabilities actually define cross functionality. Capability number one is end to end ownership. So a truly cross functional team owns a complete customer value stream, not just a feature or a component. So the best team, if you want the best team, owns a specific customer outcome or product space.

It's assuming, again, you're building a product or a platform, but of course the customers may be internal. The metrics that measure success in that space are owned by this team. All the touch points that a customer experiences in that journey are owned by this team, as are the ability to instrument, measure and learn. So this payment team that we've just been mulling over should have owned Completing a Purchase, which includes pricing display, the checkout flow, payment processing, error handling, receipts and post purchase confirmation by literally everything. That way they have end to end ownership.

Moving on to capability number two, then you're looking at the decision authority. So real cross functional teams can make consequential without constant escalation. And this doesn't mean for every senior manager who's currently freaking out and about to type something into my comments. This doesn't mean that they decide things in a vacuum. They should be constrained by strategy and collaboration with stakeholders, but they have clear decision rights when it's within their domain.

At Stripe, for example, a team's own API design decisions within their domain. They don't need approval to change endpoints or parameters. They own the developer experience for their area, which is fair enough when you think about it. They're implementing the features. They also need to implement the API that makes those features make sense.

And so if they need to change the API in their little subsection, they should have the authority to do it. Capability number three, direct customer access. Feature factory build what they're told. Cross functional teams talk to customers. Not once a quarter, not through an insights handoff from research.

They directly interact with customers, run the tests, watch the session recordings and read support tickets. One of my favourite examples from this is a team at Atlassian that has a standing rotation where each team member spends one day every sprint doing customer support. And that means that they see the real problems in real time. Someone on the engineering team ends up doing customer support, and it's a good eye opener for cross functional teams. Capability number four, a complete skill set.

And this is where the has all disciplines part comes in, but it also goes deeper than that, of course. So a cross functional team needs engineering skills to build and ship. They need design skills to create good experiences. They need data skills to measure and learn. But they also need business skills to understand the economics and viability and research skills to discover customer needs.

Notice that I say skills and not people because in small teams people might wear multiple hats. The key is that the team can do all these things without being blocked by external dependencies. So, for example, you might end up with a UX UI research and design person. It's actually the same. So they can do some designing.

They can also do some researching. Your engineering team might also have the data skills. You don't necessarily have to break them into separate people. They could just be the same people wearing multiple hats. But yes, they do have to be in this team and the team can do all these things without being blocked by these external dependencies.

Capability number five is clear outcomes. And this is like the most Of all the things that I'm running through today, this is the most important one. And it's the thing that's often lost, especially in fast paced organisations where you've got this push down from up above. Feature factory teams have a backlog. Cross functional teams have outcomes.

And the difference is a backlog is a list of things to build, and an outcome is a measurable change in customer or business behavior. So a bad goal would be build a recommendation engine. A good goal would be something like increase repeat purchase rate from 22% to 30% by helping customers discover complementary products. One's measurable, one's not. So the second one gives the team latitude to solve the problem however they want.

Maybe it's a recommendation engine, maybe it's better bundling, maybe it's email campaigns. And the team itself will figure it out, but it's also got metrics to go with it to make it measurable. So here's a simple test for whether you have true cross functional teams. Can this team run a meaningful experiment from hypothesis to learning in two weeks or less without getting approval from anyone outside the team? If the answer to that question is no, you don't have cross functional teams yet.

You have component teams that are cosplaying as product teams. So there's some red flags that you're still running a feature factory. Let me give you eight of them that will point out that you're still operating as a feature factory, even if you're reorganised into Teams. Red flag number one, your roadmap is a Gantt chart. If your roadmap is a timeline of features with delivery dates, you're running a factory.

Real product roadmaps show themes, bets or outcome areas, not a detailed delivery schedule. Red flag number two: Teams are measured on velocity. If your team tracks velocity, burndown charts or story points as primary metrics, that's a factory metric. Cross functional teams, as we mentioned before, track outcome metrics. So conversion, retention, satisfaction, revenue and churn.

And again, I keep talking about an external facing product, but of course your retention and satisfaction this may be an internal group working as product delivery internally. This is not necessarily just customer facing external things. You can apply these metrics internally as well. Red flag number three: product managers are project managers. And this one is quite subtle.

And so you can look at what your PMs are actually doing day to day. Are they writing detailed specs for engineers, running status meetings, managing stakeholder expectations, coordinating dependencies and tracking delivery dates? Because that's project management, not product management. So real product managers should spend their time on understanding customer problems, defining success metrics, evaluating solutions, making trade off decisions and coordinating with other teams on strategy, not delivery. Can you see the subtlety in the way that that works?

And you can have project managers, but you also need to have product managers. Red flag number four, engineering estimates drive prioritization. And so if a feature gets cut because engineering says it's eight story points, you're running a factory. In outcome oriented teams, decisions are driven by expected impact, not implementation cost. So if something has 10 times the expected value but costs two times more, you do it.

Red flag number five: you have alignment meetings every week. If you're constantly having meetings to get alignment, that's a symptom of unclear strategy and lack of real autonomy. When teams have outcomes, clear outcomes and decision rights, most alignment happens asynchronously and through structured communication and not through endless meetings. Red flag number six, features ship but nothing changes. And this is like the ultimate of red flags even though we've still got two more to go.

You ship features every sprint and you hit the release targets, but your business metrics, the ones that actually matter, are flat or declining. And this is the feature factory trap where you've got lots of motion but no progress because you haven't actually gone to investigate what people want and how it should be delivered. And these teams don't have the autonomy to go and do it, and so you implement what you're told and nothing more. Red flag number seven: Teams can't say no to stakeholders. And if your team regularly gets urgent requests from executives that jump the queue, you're again running a factory.

Cross functional teams with clear outcomes can push back on requests that don't serve those outcomes. And they might say, that's interesting, but we're focused on reducing churn this quarter. Here's our rationale. If you want us to change direction, let's discuss changing our goals. It's legit.

You can have push down from senior managers, but they need to also understand what the trade offs are going to be and also what the impacts on the team and the way that that team works is going to be because they're not one and the same. Red flag number eight is we can't because is a common phrase. And so listen for phrases like we can't experiment with that because marketing needs to approve it, we can't change the flow because it touches the shared navigation, we can't try that idea because legal would need to review it. Every one of these sentences is a dependency, a place where a team lacks the capability to move independently. Some dependencies, of course, are completely unavoidable.

And I'm not suggesting for a second that an engineering team or a cross functional team should try and undermine the legality of the way that stuff works. If you can factor that in and make it more flexible for your engineers and your cross functional teams you're going open a better spot. If you hear we can't because constantly your teams aren't truly cross functional. So how do you actually measure cross functionality? Let's get practical for a second and just see what we can do.

You want to know where you stand. So here are some frameworks. So you've got the team autonomy audit, and I will include some of these in the description in the notes below. The team autonomy audit. And this is simple.

For each team, list out 10 significant decisions they made and then classify each decision. Was it full autonomy? Team decided without external approval. Was it consultation where the team decided after consulting with others but made a final call? Approval required where the team proposed, someone else approved, or directed where someone else decided and the team executed.

And if more than 50% of the decisions are approval required or directed, you've guessed it, you don't have autonomy yet. Framework number two is the dependency debt score. And there are some utter riddles for trying to get some of this vocalised today. So the dependency debt score, and this one's from Jeff Patten. For each team, count how many other teams they need to coordinate with to ship value, how many approval layers exist for common decisions, and how many shared systems they depend on that they can't modify.

And add those numbers up, and that's your dependency debt. And teams with dependency debt above 10 are basically stuck. They spend more time coordinating than creating. And your goal here is simple. Get the dependency debt under five.

Framework number three is the outcome ownership matrix. And this is possibly the most powerful one. So you create a matrix where on your rows you've got key business outcomes like activation, engagement, monetization, retention, all those types of things. And on the columns, you've got your teams. And so for each cell, you then mark this team clearly owns the outcome, this team contributes but doesn't own, and this team doesn't touch this outcome.

And so a good pattern for this matrix is if each outcome has exactly one team with a tick, a bad pattern, of course, is lots of crosses or zeros where you have no clear owners. And when everyone is responsible, no one is responsible. And so you can, of course, run a quarterly team health check. Here's an example. You can ask each team once a quarter, can you describe your current mission in one sentence?

What's your primary success metric? What's the current value of that metric? And where do you want it to be? In the last month, what decisions did you make without needing external approval? How many days does it take to ship a small change to production?

And when was the last time you talked to a customer? And if teams struggle to answer these clearly, you know where the problems are. All right. So let's say you reorganize your organization into this. You've got feature factory patterns and how do you actually transform?

I'm not going to mess around. This is quite tricky. You're not going to just change the structure. You're changing culture, incentives and power dynamics, but you can do it. It'll be painful and take time.

But let's start with strategy number one, which is start with outcomes and not structure. The biggest mistake that organisations make is reorganising first. Instead, start by defining clear outcomes you want teams to own. Force yourself to articulate what customer behaviour are we trying to change? What business metric are we trying to move?

Once you're clear on outcomes, team structure becomes more obvious. You'll organise around these outcomes. Strategy number two is do a dependency purge. And this sounds dramatic, but it does also work. So pick one pilot team and make them the guinea pig in this purge and then systematically eliminate their dependencies.

Block off a couple of weeks in workshops, identify every approval gate, every shared service, every coordination point that slows them down, and then one by one, find different ways to eliminate those dependencies. Duplicate systems if you have to change approval processes, give them dedicated design support, whatever it takes. Because the goal is by the end of the two weeks, the team can ship value independently and then measure the difference. Most organisations see that pilot teams ship three to four times faster with higher quality and that becomes your proof for the model. If it doesn't work or if they're still getting all the distractions, then you need to keep trying.

Change what you measure. Strategy number three is change what you measure. And so you can't run cross functional teams while measuring velocity. You need to change the dashboards, your OKRs and your performance reviews to focus on outcomes. At a place I've worked at before, we completely eliminated velocity tracking.

Instead, each team had a dashboard with these metrics. Their primary outcome metric, which may have been engagement conversion, something along those lines, a quality metric like a bug rate or system performance, and a customer satisfaction metric like NPS for their specific feature area. And every sprint review then became, here's what we've learned, here's how the metrics moved, and here's what we're trying next. And that shift in conversation completely changed how the teams operated. Strategy number four is train PMs to become owners, not feature brokers.

And so your product managers need different skills in an outcome oriented model. They need to be able to define good outcomes and key results, run experiments, interpret data, facilitate team problem solving, say no to stakeholders diplomatically in a way that doesn't piss off the stakeholders, and tell compelling stories about the strategy. And if your product managers are spending all their time writing specs and managing delivery, invest in training or coaching to help them level up. Strategy number five is create strategic buffers. And so here's a tactical one.

Create buffer capacity in your system. If your teams are running at 100% capacity, they cannot absorb variation, they can't experiment and they can't pivot. I usually try and reserve 20% for tech debt and operational excellence, 10% for exploration and learning, and 70% for outcome focused work. And that buffer is what gives teams space to actually be strategic. Strategy number six, the final one, is fix your incentives.

Finally, you've got to change the incentive structure. If engineers are rewarded for code shipped, you'll get lots of code. If product managers are rewarded for features delivered, you'll get lots of features. If executives are rewarded for hitting project milestones, you'll get projects. Instead, try tying rewards to outcomes.

Make the entire team accountable for the metrics they're trying to move. In places I've been at before, the company is given quarterly bonuses based on whether teams hit their outcome targets. Not their delivery targets, but their actual outcomes that have been targeted. And that changed the behaviour overnight. So let me try and bring this all together.

The difference between cross functional teams and feature factories, it's not about having designers and engineers in the same room. It's about capability autonomy and outcomes. So true cross functional teams own complete customer value streams. They have decision authority in their domain and they track outcomes and not outputs. And they can also learn and pivot without endless coordination.

And so if you take one thing from today's episode, make it this: stop reorganising and start empowering. Give a team a clear outcome to own, remove their dependencies, and then get out of their way. Now this, I appreciate, requires some level of buy in from everybody from the C suite down to wherever it gets to. But try that. Try to clear a path for this team to own what they're supposed to provide, remove the dependencies, then just get out their way.

Then watch what they can do. So that's it for today's episode. If you want to dig deeper in any of this, I've put together a team assessment worksheet that you can download that's in the episode notes below. It'll help you evaluate where your teams are today and identify the biggest gaps. Check the show notes for the link and we'll be back in a week's time with the next episode.

Until then, keep building better products.

Thanks for listening to Engineering Evolved with Tom Barber, where ideas meet innovation and leadership drives change. If you enjoyed today's episode, please leave a rating and review wherever you listen. It helps more leaders discover the show and keeps the evolution moving forward.