I recently wrapped up what was supposed to be a “simple” two-day feature for our iOS app. It took two weeks and three separate releases. Sound familiar? After years of consistently underestimating projects at scale, I’ve finally figured out why we’re all so terrible at this: the visible work is just the tip of the iceberg.

The Iceberg Problem

We think we’re estimating: write code, test it, ship it. Done.

What actually happens in a large company looks nothing like that. You’re getting access to repos, waiting for provisioning profiles, realizing your Xcode version is wrong, fighting the corporate VPN. “Let me just check our internal docs” turns into three hours of Confluence archaeology across five different spaces. Stand-ups, sprint planning, design reviews, “quick syncs” with three different teams eat into your day before you’ve written a line of code. Product asks if you could also support iPad while you’re in there. You hit that weird edge case that only happens on iPhone 12 mini running iOS 15.7.1. And then App Store review rejects you, or you forgot to flip a feature flag, or the backend deployment isn’t ready.

The actual coding? Maybe 20% of the total time if you’re lucky.

My Personal Hall of Shame

Some recent “quick fixes” from our mobile team:

“Just update the launch screen” was estimated at 2 hours. Took 3 days. We had to support all device sizes, dark mode variants, coordinate with brand team, and discovered the marketing assets were the wrong resolution.

“Add haptic feedback to buttons” was estimated at 4 hours. Took a week. Accessibility review flagged issues, we had to create a settings toggle, do a battery impact analysis, and support different haptic engines across device generations.

“Migrate to the new analytics SDK” was estimated at 1 day. Took 2 sprints. Privacy review, legal approval, data governance requirements, fixing every single event that broke, coordinating with 4 different teams who consume the data.

The Hidden Work

After tracking my time obsessively (thanks, quarterly planning!), I’ve identified the main culprits.

There’s the thinking work: planning, architecture decisions, choosing between 3 similar internal frameworks, getting approval from the platform team. Then the talking work: explaining what you’re doing to stakeholders, getting buy-in from security, addressing concerns from that one principal engineer, that Slack thread with 47 participants. The fixing work is never your own bugs either. It’s bugs in internal dependencies, simulator issues, that thing that worked yesterday but the backend team deployed something. There’s the learning work: new iOS APIs, SwiftUI updates, that “better” pattern the architecture guild decided on, internal tools with zero documentation. And finally the polishing work: making it actually good instead of just functional. Performance profiling, accessibility review, proper crash reporting, A/B test setup.

Making Peace with Reality

I’ve stopped fighting this and started planning for it. Some strategies that actually work in a large org:

Take your gut estimate and multiply by four. Add a sprint for cross-team dependencies. Set hard limits on research and internal tool debugging so you don’t lose a full day down a rabbit hole. Keep notes on what actually ate your time, because it’s useful for retros and next quarter’s planning. And build in real buffer. Not 20%. Not 50%. Double it. Then add time for App Store review.

The Part Nobody Tells You

All this “extra” work isn’t waste. The reviews ensure it won’t break for millions of users. The meetings align dozens of teams. The process prevents that 2 AM incident.

Once I accepted that shipping features in a large company is fundamentally different from side projects, I became a better engineer. My estimates got realistic. My manager stopped looking stressed during planning. My code got better because I wasn’t rushing to meet impossible deadlines.

Next time you’re estimating a feature, remember: you’re not just writing code. You’re navigating teams, processes, and platforms that all have their own timelines and priorities. Plan accordingly, and maybe you’ll ship before the next iOS version drops¹.