TBM 340: Path to $

A quick post on different team types and how that influences the ROI discussion.

Picture six teams, consider the implications on funding and understanding ROI.

Team 1—Close to Impact

The first team has a tangible "line" to benefits, revenue, and business outcomes and can work independently. A good example might be an e-commerce checkout team whose work directly impacts conversion rates and sales revenue. Finance loves this team because the outcomes are so clear-cut.

Team 2—Everything and Nothing

For the second team, it's much harder to illustrate the benefits. One day, they rush to complete an urgent sales-driven request; the next, they're prototyping an idea the CEO had the night before. They may also be stuck propping up a dozen inherited, disparate services—assumed to be critical but never prioritized for meaningful investment or improvement. With no continuity, the only way to assess return on investment is to scrutinize every story, task, and "project" and attempt to estimate the impact (which is a pain in the butt).

Team 3—Focused, But Multiple Hops

The third team has a well-defined domain and sphere of responsibility—they own an internal platform that is critical for enabling other teams to build and deliver customer-facing features efficiently. They are much more focused than Team 2; they have a strategy, a stable-ish roadmap, and clear partners with whom they interact regularly. They're clear on their proximate actionable input metrics, but it takes a combination of work and logical leaps of faith to build a business case, especially given that their partners are so diverse.

Team 4—Journey Team

The fourth team is one of a dozen teams that contribute to optimizing a key customer journey. Their work is somewhat independently valuable, but it is also highly interconnected to the work of other teams. Like Team 1, they are "close" to customers and customer impact, and maybe only one hop removed from revenue. In that sense, it is relatively easy for finance to total up the budgets for these dozen teams. Where things get tough is isolating the impact of any one particular team. Finance has a choice: worry about it or imagine the dozen teams as a single budgetary unit.

Team 5—Startup Mode

At StartUp co, there aren't really any "stable" teams. Teams form and re-form as needed based on the challenges of the day. They've opted to "go broad" for a while, which means having teams focused on one area for an extended period isn't beneficial. When many people need to work together, they form big temporary teams, and when you can have a lot of people cranking on solo or two-person teams, they make that happen. You might assume their work is chaotic and poorly thought out, but the team has exceptional focus and follow through when they are "on" a project (1w to 4-6 months). Because everyone is rowing in the same general direction, there is no real emphasis on figuring out the ROI of every initiative. The focus is on growth and optionality.

Team 6—Spreadsheet With Engineer Per Row, And Project Columns

Lastly, we have a team in a more traditional "project factory" model. Someone walks around with a big spreadsheet every month or quarter, with a row per engineer and a column per project, and asks each team to dole out where they spent their time. The "object" of funding is the project. Another team tries valiantly to estimate the "impact" of the project—upfront before work starts, for sure, and if you're lucky, once the thing has shipped.

Note how these teams vary in terms of three factors:

1. Close to customer impact and business outcomes vs. Far

2. Independent vs. Dependent

3. Stable vs. temporary

For example: Team 1 and Team 3 are stable and independent, but Team 1 is much closer to revenue. Team 5 has temporary teams that operate independently on a range of efforts (close to far).

Discussion

Reviewing the teams:

• Team 1—Close to Impact

• Team 2—Everything and Nothing

• Team 3—Focused, But Multiple Hops

• Team 4—Journey Team

• Team 5—Startup Mode

• Team 6—Spreadsheet With Engineer Per Row, And Project Columns

Some thoughts:

1. In product-forward companies, you will often find a mixture of Team 1, Team 3, and maybe Team 4. You shouldn't need any Team 6s; however, some % of the work will involve large, complex, cross-cutting projects. If kept below a certain percentage, you typically don't need to worry too much about them from a financial perspective.

2. Early on, many successful startups started as Team 5. Some scaled successfully into the couple hundred-person range using that model—typically because of a passionate and disciplined founding team that ensured it didn't get out of hand. It looks like Team 2 or Team 6 when it gets out of hand.

3. Organizations need a lot of patience and discipline to work things out properly for Team 3s. Too often, they never get the opportunity to develop actionable input metrics and a "map" to customer and business value. I know plenty of companies that are extremely "product-led" regarding their customer-facing teams but relegate the teams that are a couple of hops removed to the Team 6 or Team 2 model.

4. Many companies aspire to adopt the "product operating model" but keep a PMO and project-based model external to product/technology (Team 6s) while trying to be more outcome and team-focused internal to product/technology. Everything and anything gets named a "product," but there is no theory whatsoever on how these stable teams get funded and their contributions flow into anything durable and lasting.

5. Dependencies are an interesting beast. They aren't inherently "bad". But they are a clue to do more discovery. In many cases, I see dependencies as a strong signal that you are early on in the emergence of a Team 4 or Team 3 situation. There is more overlap than you would like now, but you'll figure out how to foster more sturdy boundaries over time. Great platforms often start out as high-touch collaborative situations. That's OK! On the other hand, repeatedly being pulled in multiple directions—your "day job" and then catering to disparate ad hoc requests—is a good sign something is off.

Some companies treat engineers and designers as too fungible. They end up with Team 2s or Team 6s and maybe try but fail to implement the Team 5 approach.

At the same time, especially in larger Silicon Valley companies during ZIRP, you often saw companies prematurely converge around theoretical Team 1s or Team 3s. They hire VPs and GMs around the premise of theoretical independence. That independence never really materialized, and dependencies ruled the day. When reality came crashing in, the only option was to do layoffs because there was no history of more fungible and adaptable approaches (e.g., Teams 3, 4, and even 6).

I see this pattern in several enterprise companies trying to be more product-forward. Instead of accepting that a lot will change as they dial in their architecture, tooling, skills, etc., they rush to "define products" only to find out that their initial definitions were too aspirational, theoretically correct but impractical, or at actual odds with customer journeys, new platform strategies, or collaboration demands.

Try to mentally list where different teams sit in your organization as an exercise.

Can you do more to:

1. Help the 2s focus?

2. Help the 3s connect their work to what matters?

3. Ensure the 1s do not locally optimize at the expense of global outcomes?

4. Demonstrate the full value the dozen of Team 4s are driving?

5. Experiment with a Team 5 model when and where it makes sense?

6. Figure out what needs to happen to shift from the Team 6 model?

How would you cluster teams based on:

1. Close to customer impact and business outcomes vs. Far

2. Independent vs. Dependent

3. Stable vs. temporary