Mike's Notes
Recognition of the scale of a significant problem that exists in large enterprise systems.
Resources
- https://www.linkedin.com/pulse/why-everything-so-slow-large-companies-vitaly-friedman-uvvje/
- https://www.seangoedecke.com/difficulty-in-big-tech/
- https://www.linkedin.com/in/davestewartuk/
- https://davestewart.co.uk/blog/the-work-is-never-just-the-work/
- https://www.linkedin.com/in/johnpcutler/
- https://www.openorg.fyi/resources
- https://thewavingcat.com/publications/the-little-book-of-strategy/
- https://newwaysofworking.notion.site/New-Ways-of-Working-Playbook-dc607e37f7894f4a9be698a6573cb97b
- https://www.linkedin.com/in/markeddleston/
- https://thewavingcat.com/publications/the-little-book-of-strategy/
- https://www.linkedin.com/in/pbihr/
- https://www.doc.cc/articles/form-factor-trap
- https://www.linkedin.com/in/pavel-samsonov-44ba2833/
- https://www.seangoedecke.com/how-to-ship/
- https://www.linkedin.com/in/sean-goedecke-5495a7137/
- https://measure-ux.com/
- https://smart-interface-design-patterns.com/
References
- Reference
Repository
- Home > Ajabbi Research > Library > Subscriptions > Smashing Magazine
- Home > Handbook >
Last Updated
11/06/2025
Why Is Everything So Slow In Large Companies?
If you work in a large organization, you might find yourself puzzled by how slow and seemingly inefficient they can be. Decisions take time. Reviews tend to run in circles. Meetings always start late and overrun. Features get infinitely delayed. And teams become growingly protective of their silos.
And with larger companies, it compounds dramatically to the point that shipping on time becomes an exception, rather than the rule. But why does that happen? Why do projects have to be so painfully slow to have the slightest chance of being successful? And how do move the needle in the right direction? Well, let’s get to the bottom of it.
Heads up: Meet How To Measure UX and Design Impact — on how to show the business impact of your incredible UX work. Use a friendly code LINKEDIN to save 15%. Jump to table of contents.
“Wicked Problems”
At best, slowdowns are highly inefficient and wasteful. And at worst, they create a poor culture that propagates throughout the entire organization. The result: teams that feel utterly frustrated, confused, slowed down or simply ignored. That’s when people stop talking in team calls and send their AI notetakers instead.
As Sean Goedecke beautifully explains, the reasons for that aren’t inefficient processes, poor coordination, or lack of competency. It’s simply a different scale of problems that need to be solved, with many dependencies, decisions, and business goals to meet.
Wicked problems are unique and interconnected, which means failures have big consequences on the business.Large companies are heavily constrained by a very small but very consequential set of problems, called ”wicked problems”. These are deeply inter-connected problems that interfere with many features, actors, systems, flows, and users — and often live at the very heart of the organization.
These are typical challenges of wicked problems:
- Problems are “unique” and not properly understood
- Many dependencies, with legacy or third parties
- Multiple stakeholders with conflicting agendas
- Involve many different parts of an organization
- Every solution affects parts of the entire system
- Solutions aren’t right or wrong, but better or worse
- Take a lot of time to evaluate and make decisions
- Can never be properly solved, just addressed
- Failures have big consequences on the business
If you find yourself in the middle of a wicked problem, you’ll need to shift gears. The only option to avoid disastrous failures is to slow down. You have to spend more time in planning and risk management before designing a single pixel on the screen. Every UX decision comes at a cost, and there will be people keeping a very close eye on these costs.
With wicked problems, you will always be perceived as a disruptor who endangers business-critical processes if you aren't meticulous and careful enough. As a result, you become more strategic about your UX work. It means assessing risks and setting up a testing strategy early, but also building working groups and design guilds. It also means running cross-team workshops to uncover dependencies, conflicts, and constraints early.
The Curse of Slow Shipping
As a company and its products keep growing, by default it becomes more difficult to ship new features. Each new feature will in some way interact with existing features and systems, critical user flows, potentially legacy systems, third-party vendors, and custom systems done by other units.
And as Dave Stewart noted, the "work" is never just the "work". It's meetings, reviews, research, experimentation, scoping, setup, infrastructure, procurement, iteration, maintenance, tooling, changes, omissions, nice-to-haves, scope creep, surprises, contingency, sudden change of timelines and priorities, updates and fixes. And with larger companies, it compounds dramatically to the point that shipping on time becomes an exception, rather than the rule.
In many companies, projects get indefinitely delayed, moved, cancelled or abandoned all the time. The sad reality is that despite all the incredibly hard work put in by UX and engineering teams, such projects are perceived at best as wasted efforts, and at worst as costly failures by “undeperforming” teams.
In fact, even if the work was completed well ahead of the schedule, the underwhelming impact of that work might still reflect badly on the entire team. The whole project might be perceived as a good idea poorly implemented — with little room for debates about small wins and successes here and there. And for that reason, I spend an enormous amount of prep work to filter out, prioritize, scrutinize and pre-test design ideas before heading straight into the design mode.
In complex projects, execution is at best around 35% of all work, with only 20% of time needed for planned work. That's why many estimates are utterly wrong.
Ensuring that a feature can be neatly integrated with all dependencies around it takes time and effort — and the more complex the product, the more time and effort it will require with every single change. It holds true especially if a particular change is the main “hub” for key user flows or business priorities.
In larger products, failures can have disastrous consequences at scale. So every change must be meticulously reviewed. High-risk scenarios must be thoroughly addressed and mitigated. More planning and prep work is required as it’s the only way to reduce the likelihood of things going terribly wrong. The illustration by John Cutler below beautifully shows how the usual workflow plays out if not enough strategic thinking has been done.
Slowdowns are often caused by habits and structures deeply rooted in an organization. Addressing them is crucial to improving workflows. (Credit: John Cutler)
Plus, user flows typically need to be revised as features must be easy to find, easy to use efficiently but also difficult to make mistakes with. Not to mention the usual politics and powerplay as different units thrive for attribution, higher visibility, influence, and budgets for the upcoming year.
Unsurprisingly, with all of it in play, things slow down enormously as the project is being pulled and pushed and reshuffled and revisited over and over again.
How To Slowly Introduce Change
Most companies claim to put quality over schedule any time, but very often there is nothing more critical for companies than to ship frequently, and on time. In fact, research and UX work often are perceived as blockers of shipping early and refining on the go.
Im practice though, we need to know at least enough to not be wasting time on a feature that provides little business value or little user value. Research isn't a blocker but a filter for shipping projects that matter. And that's one of the most common points I tend to raise early.
Company Culture Playbook (Notion docs) is a fantastic effort to bring free tools, templates and resources to improve company culture (Image links to the Notion hub).
Slowness doesn’t mean that it’s impossible to make a change in such environments. But you will need enough patience, enthusiasm and trust to slowly start moving the needle in the right direction. Personally, I would start by zooming in on things that affect everyone in the team. Well-known bottlenecks that slow people down. Meetings that end without action points or run late. Communication channels with key decisions made all over the place.
Little changes there can make a huge impact on everyone, and people will notice. The goal is to help other people see the benefits that your contributions bring and build up confidence for your work and your good intentions. Sometimes that might be just enough to get them on your side to address wicked problems with the due diligence and attention they deserve.
The Little Book on Strategy, a wonderful little cheat sheet with actionable advice on strategy and leadership, by Peter Biehr (image linked).
Most importantly: become more strategic and calibrate expectations. We don’t know how our stakeholders work, so we shouldn’t expect that they know and understand design process. The more sincere and vulnerable you are, the more likely you are to get understanding and support, rather than fast turnaround requests.
Useful Resources
- Company Culture Playbook, by OpenOrg
- New Ways Of Working: Playbook For Modern Teams” (Notion), by Mark Eddleston
- The Little Book of Strategy, by Peter Bihr
- Design Is Taking Too Long. When Can We Ship?, by Pavel Samsonov
- How I ship projects at big tech companies, by Sean Goedecke
Happy Birds: How To Measure UX (Video + Live UX Training)
I've been spending quite a bit of time reviewing and drafting new sections for the video courses on UX:
- Measure UX and Design Impact (8h + live UX training)
- Smart Interface Design Patterns (15h + live UX training)
- Both video courses come with a live UX training with 1:1 feedback and UX certification.
- Use the coupon code ð LINKEDIN to save 15 off.
Thank you so much for your support, everyone — and happy designing!
No comments:
Post a Comment