Thriving During The Great Flattening

In our discussions with product and product operations leaders, a couple of themes stand out:

1. Leaders are being asked to "get into the details" and be more hands-on.
2. There is a strong push to do more with less and "have a high sense of urgency."
3. In addition to doing more with less ("efficiency"), teams are being asked to jump headfirst into AI efforts, innovate, and respond to a generational shift in the technology landscape. It is like asking a race car driver to drive the race of their life while in fuel-efficiency mode.
4. In many organizations, layoffs targeted middle management layers and/or spans and ratios. As a result, organizations are flatter, and ratios are higher—less support and more to manage.
5. Org charts are in flux. Leaders need to choose between a) disruptive reorganizations and b) keeping the organizational chart stable while reorienting teams to tackle cross-department and cross-functional efforts.

We've dubbed this the Great Flattening internally here at Dotwork.

It appears in our conversations with prospects and customers and manifests in the object models teams operationalize in our product. Whereas before, you might have seen a hierarchical goal/work structure like Program, Initiative, and Epic, some companies now opt to "flatten" that into a flat goal-focused Bet model. Similarly, as companies abandon ambitious multi-product growth strategies, we see complex multi-tier product taxonomy hierarchies get folded into a single platform approach.

Tools give you a glimpse into macro trends, and we're witnessing the great flattening firsthand.

To prepare for a recent workshop with a customer experiencing these trends, we put together eight actionable tips for leaders navigating the Great Flattening. None of these are "easy," but they are backed by a high enough "N" to hopefully be useful for you and your team.

Explore the hidden costs of your planning cycles, ritual prep, rituals, etc.

It shouldn't take a product manager fifteen hours of busy work to prepare a couple of slides for a regular review lasting one hundred and twenty seconds. Most of that time should be spent thinking strategically, not copy-pasting data from different systems and spinning up countless tasks for direct reports and/or peers.

We've seen examples of single reporting asks (e.g., "Can you pivot your capacity by alignment with one of these three horizons?") collectively take teams dozens or hundreds of hours to respond to. An org of 1,500 designers, engineers, and product managers recently estimated the cost of quarterly planning at ~$4,000,000 per quarter in salary time alone, not to mention opportunity costs. And the NPS for the ritual was less than zero. If you know how NPS works, you know how bad that is.

Perform an audit and ask yourself how many decisions are informed by this prep time. If the information is important, yet it involves a lot of manual friction to collect, then consider investing in streamlining those efforts. If the information goes unused or acts as a safety blanket—there but not really helpful—consider the power of subtractive change. Your team will thank you.

Tip: Consider creating Dotwork artifacts for key rituals. This artifact allows you to 1) link the objects used in those rituals, 2) track the history of that ritual, and 3) if you add decisions or outputs into the mix, you can keep track of decision velocity and ultimately follow the path of those decisions to outcomes.

Be on the lookout for perverse incentives.

To be "efficient," many teams are falling into common traps like:

• Chasing false precision
• Incurring high multitasking costs to maximize utilization
• Letting well-meaning efforts to be "involved in the details" become performative micro-management.

We are in a strange time. On paper, current macro-trends lend themselves to ideas like continuous improvement, cutting through bureaucracy, and removing friction. At the same time, due to layoffs and general uneasiness, people are being less transparent about their problems on the team level. So, the incentive mix may not be what you expect.

If leaders incentivize teams to be proactive and set ambitious goals for the quarter, that might be fine in certain contexts. But if there's a tendency to overcommit, given current volatility, that might set those teams up for a big crash come the end of the quarter. Teams may hesitate to raise blockers and friction areas for fear of being branded as problematic. In short, watch for situations where teams shoot themselves in the foot trying to chase the current efficiency trend and don't feel comfortable speaking up.

If you find yourself having a conversation like this:

"If George and Ina each allocate 50% time to Project Thunder, and then Lenny does 10% time combined with moving the two open reqs to Team Apollo and hiring those roles in the next two months, we should—if we sort of combine Project Thunder and Project Inferno—be able to finish Thunder, Inferno, and chip away at Homestead so that when The Hex Pistols are done with the event streaming re-architecture and Project Kafka-esque, assuming Xenia approves the design document, we should be able to hit the deadline for Project Sycamore as promised in the 2025 annual plan."

Step back, breathe, and realize your efforts to help will likely hurt.

I'm constantly amazed by how, in the throes of the efficiency craze, leaders are somehow OK with burning 50% of their capacity on multitasking and trying to do everything. This practice is the definition of inefficiency. My hunch is that this is fear-based or incentive-based. They're either too afraid to raise the issue, or the underlying incentive is to say yes to everyone.

Tip: We recommend limiting the percentage buckets used for capacity allocation to 20% buckets. Why? Once a team starts working with allocation buckets smaller than 20% (e.g., 12.5%, no joke), you realize that the multitasking and coordination tax exceeds your other buckets. For example, if you're working with something like a 10%, 20%, 15%, 15%, 20%, and 20% allocation spread across goals, you're probably burning 30-50% on multitasking. In effect, the cost to be that precise is higher than the reward.

Surface when people are engaged in "no win" tradeoffs.

Navigating tradeoffs is part of the product game. But often, you find yourself caught in the "meh" middle of a tradeoff. You end up saying, "Yeah, we'll do both, but both will suffer," when there might have been an opportunity to do one thing and knock it out of the park.

One of the costliest things from an efficiency standpoint is when either 1) decisions on tradeoffs must be "run up the chain" to leadership to play tiebreaker, or 2) when teams—to avoid that hassle—decide to do both, even when they know better.

One of the pushes to be "in the details" is to accelerate these tradeoff decisions. The reasoning is that if leaders are in the details, they can reconcile these tradeoff decisions before they lead to paralysis. That's the theory, at least. In practice, escalating things up the chain is still time-consuming, requires calendar Tetris, and often results in a "do both" outcome.

A better approach is to use prioritization heuristics to anticipate these tradeoff decisions and have an opinion. This approach enables faster decision-making without getting caught in the trap of trying to fit both things into a timebox and/or dragging teams through countless estimation exercises that ultimately end up in trying to do everything.

Tip: Use a Priority object in Dotwork mixed with stack ranking to create a prioritization heuristic. Consider general guidelines like "If you can help with or are asked to help with the item in slot 1, always do it; otherwise, don't get in the way and keep working down the list." Also, it enables team members to pose questions about priorities and invite leaders to respond. This approach helps you escape the perpetual "it depends" discussion (where it depends on _____ is always an estimate).

Fewer rituals, but better rituals.

When you remove management layers, you will naturally have to decide: do you have bigger meetings, or do you run many SMALLER meetings and then ask "go-betweens" to transfer that information down to the front lines?

Many organizations default to spinning up countless 1:1s or small meetings and, to be hyper-efficient, trying to relay decisions to the front lines.

We think that is a mistake. With a little prep, good supporting information/insights, and a tight ritual, you can run larger meetings that 1) engage the right people at the right time, 2) ground the ritual in good habits and good information, and 3) bring people with the context much closer to the decisions. Fewer well-executed rituals beat countless 1:1s attempting to save everyone time. It takes a little forethought, but the teams that do this well accelerate learning, decision velocity, and role modeling.

Tip: If you create an artifact for a key ritual (see above), consider incorporating the pre-work and pre-reads into that artifact. Use our Slack agent to notify attendees that new information is available to prep for the ritual. Consider dot voting or other techniques based on silent reads to kick the meeting off. Teams that converge on the same artifacts and information experience a huge boost in ritual effectiveness.

Care for your feedback channels. They may need some TLC.

In the current environment, we're observing two opposing trends. In some contexts, you see newfound beneficial transparency driven by a healthy sense of urgency and focus. Org shifts have triggered a reset. In other contexts, there is a lot of fear about exposing too much or airing dirty laundry without controlling the optics. At the moment, I think it is a safe assumption that leaders need to lean in and be very intentional about creating environments where teams can surface blockers AND to reiterate to their direct reports that doing so will not be seen as a way to cut them out of a loop by going straight to skip-levels.

Tip: Consider creating a "paper cut" or "blocker" object in Dotwork to signal areas of friction, but use our templating feature to help teams frame these problems with more specifics and details. Consider how many retros surface the forever-problem "communication issues." That is not enough detail to act on.

Build conviction around actionable inputs.

Actionable inputs are levers/drivers that teams can directly influence. Without actionable inputs, you're stuck shipping without early signals that your work is having the effect you think it is having.

Too many teams dream up everything they want to build and then slap ad hoc metrics onto those things. This practice has a destabilizing effect. There is nothing to return to quarter over quarter to see the big picture (while working small and knocking out experiments and projects along the way). In the current landscape, actionable inputs are important because you need tempo and reflection, all in tight feedback loops.

Tip: 3–5 actionable inputs should be sufficient for each team. Don't stress on the first pass. Model a metric object of type = "actionable input" in Dotwork, and then weave that into a ritual. Consider adding a "confidence" field so the team can track their confidence in the link between the input and long-term outcomes. Low-confidence actionable inputs can be safely retired and replaced.

Get your platform strategy in order.

Over the last decade, some companies have scaled wildly while ignoring their platform strategy. This left them highly inefficient, and they relied on growth rates to cover up this inefficiency. Other companies saw massive re-platforming efforts produce no outcomes. They funneled a lot of money into the promise of platforms and nothing materialized (often because they were moving quickly and asked those platform teams to do double duty).

Platforms are an efficiency unlock—do something in one place that somebody can reuse in other areas. The problem is that platforms require a strategy and nurturing over an extended period to get right. You need to think big and work very small, providing value weekly to internal customers. It is a perfect time for a product strategy reset that clarifies long-term platform benefits and aspirations while figuring out how to catalyze that sense of urgency and regular progress.

Tip: Use Dotwork to tie platform investments to friction-busting and time-to-market enabling variables. Make sure these teams' funding models take into account the core hypothesis underpinning the platform.

Finally, socialize the difference between efficiency, as commonly discussed, and capital efficiency.

As commonly discussed, efficiency is basically about doing more with less or doing something with less "waste." It is an important view. However, it is not the same as capital efficiency, which centers around using sources of capital (including human "capital") to achieve your long-term strategic goals.

The underlying message for your teams is that they need to consider both the near-term "efficiency" of their operating system and whether they are allocating capital in ways that boost the company's long-term prospects. The ZIRP era gave rise to very cheap capital at a macro level. This triggered the growth at all costs mentality (grow while capital is cheap and multiples are high). We are in a new era, and teams cannot be as swashbuckling. Discuss the difference between "regular" and capital efficiency with your team. Both are critical, but they are different concepts.

Tip: We suggest being concrete about operational efficiency goals in Dotwork and framing capital efficiency using a multi-horizon, portfolio-based investment frame.

Hopefully, these tips are useful. We're always excited to chat with people facing the Great Flattening and to explore how thoughtful operations can help.

Reflection Questions

We'll close with some questions for reflection:

• Are there rituals, reports, or planning efforts that consume time but rarely inform decisions or outcomes?
• What's the true cost of multitasking? If we examined the real impact of context-switching and fractional allocations, how much capacity are we losing in pursuit of false precision?
• Are our teams empowered to say no or challenge tradeoffs? When faced with "do both" mandates, do people have permission and heuristics to push back, or are we defaulting to diluted efforts?
• How confident are we in our feedback channels? Are people speaking up about friction and blockers, or has fear, re-org fatigue, or optics sensitivity made transparency risky?
• Are our efforts to be "in the details" helping or creating noise and second-order coordination burdens?
• Which of our rituals are truly helping us move faster and learn more? Are we investing in shared context and effective formats or defaulting to more meetings and 1:1 relays?
• Are we measuring and adjusting based on things we can directly influence, or are we just tracking outputs and lagging indicators?
• Is our platform strategy reactive or designed with intent?
• Are we clear on the difference between operational efficiency and capital efficiency? Are our current decisions helping us hit quarterly targets and improving our long-term strategic position?