Why building "small" features at a FANG company can be surprisingly complex

I was explaining to a Product Manager friend why even seemingly "small" features take much longer to build at large companies compared to smaller tech companies. Here’s an example:

Imagine you want to add the user’s address to all UI components managed by your team. Sounds simple, right? Here’s how this might unfold:

1. You make this feature request to the backend team, only to find that it takes over 3 weeks to get the change implemented. Why? 😕

2. The Address Service, which provides address data, is owned by a team based in Austrialia. This team of 8 engineers is already overwhelmed 😰 with operational tasks — handling 10+ on-call pages daily, a backlog of 100+ items, and numerous requests from engineers across the company. They don’t have the bandwidth to answer individual Slack messages.

3. To manage demand, they host weekly office hours for onboarding new clients. They’re also rolling out a new GraphQL API 🚀 to deprecate their old infrastructure, so they carefully evaluate each new use case to plan for incremental traffic.

4. One of your engineers attends their office hours and learns that address data is PII 🔒 . Before the data can transit through your service, a security review is required.

5. The API integration takes slightly longer because PII data need to be decrypted by your service. Your engineers write a security doc and rush to seek an approval from a certifier. Fortunately, it’s granted because the change is otherwise small 🥲

6. Despite this, rolling out the change takes a few more days. Your service is a Tier 1 product, meaning any new dependency must be introduced cautiously 🐢 to avoid multi region outages.

7. After the rollout, your team discovers that the number of calls to the Address Service doesn’t align 1:1 with the incoming requests to your API. Turns out, the integration was missed in one of the code paths 💔

8. A fix is rolled out, and only then is the feature successfully launched 🎉

What seemed like a "simple" feature ends up taking weeks because of the interplay between operational bottlenecks, cross-team dependencies, organizational policies, and the need for high reliability.

This isn’t to say that feature velocity at big tech is inherently low. However, an engineer may occasionally encounter one of these seemingly “small” tasks once a quarter, which, due to its ripple effect, can delay more critical deliverables.

How should you handle this situation

1. As an engineer, no task is big or small until delivered to customers. Apply the same first principles thinking to every work you do. Ask the fundamental questions for every change. Identify the critical execution path of a project, and kick off the threads required proactively much like how you’d build a latency sensitive API.

2. As an engineering manager, when your engineer provides a 3 week estimate for a small change, don’t shoot the messenger. Try to understand the organizational inefficiencies involved and improve them. Make the hard calls (i.e. dropping the project) because engineers may hesitate to recommend those.

3. As a Product Manager, don’t fire and forget “small” feature requests and go back to chasing the big rocks. Paying attention in stand-ups while separating noise from the signals will help you provide solutions. Building a personal connection with the engineers will help create a bridge for them to reach out to you informally without waiting for the next meeting.