How To Stay Flat Like Apple and Innovate

Issue 009 - New look, and vision for Building Romes; Taking a trip down memory lane and diving into how Apple innovates by staying flat.

Howdy Readers -

Welcome to the 26 new sign ups since my last essay, the most sign-ups ever recorded.

Yay!! The tribe keeps on growing. 🤯🙏🏼🙌🏼🥳🎉🎊🍾🍻

Share Building Rome(s)

Let’s take a moment to acknowledge the historical time we find ourselves in 2020 - a woman of colour - Black and Indian - is the Vice President Elect of the United States of America 🇺🇸, Kamala Devi Harris. Wow. What a time to be alive.


There is a great article in the Harvard Business Review on how Apple is organized to innovate. In complete Jobsian disdain for traditional, hierarchical, bloated management style, “Believing that conventional management had stifled innovation, Jobs laid off the general managers of all the business units (in a single day), put the entire company under one P&L, and combined the disparate functional departments of the business units into one functional organization.” The goal was to build a flat nimble startup-like organization based around functional areas with leaders at the helm who were deep experts within each area.

I joined Apple in Feb 2012. The iPhone 5 was in the works and iOS 6 was mid-development set for an unveiling at WWDC 2012; iOS Software Engineering reported under Scott Forstall, and was separate from Mac OS Software Engineering reporting under Craig Federighi. That is a long way from when Steve created the initial functional org structure but it remained intact, thriving, and became far more complex between when I joined in 2012 and left in 2017.

So, how does Apple build more without adding bloat in leadership or workforce? The discretionary leadership style is the solution.

One of the key elements of innovation is agility. Lack of agility can dethrone industry leaders. It happened to Motorola, Nokia, Palm and Blackberry, where I had front row seats to that show. It nearly happened to Apple before Steve came on board in the late 90s. His decision to restructure to a simpler functional organizational structure changed Apple’s trajectory, along with him at the helm of course. Despite Apple increasing their product lineup and teams over time, that simple functional structure remains intact. But, there is a huge difference between wanting a flat organization versus maintaining one. As companies grow, so do the products and the workforce needed to support them. With this discretionary leadership style Apple stays agile and ready to respond and innovate. 

An agile organization has two key characteristics:

  • Flat decision making structure

  • Hyper centralized accountability

You notice I didn’t say flat reporting structure. Decision speed is a better metric to track than overall layers of management when considering how to structure an organization. How many hoops do I need to jump through before I have a decision? You can have a flat organization yet still have to jump through many hoops to make a decision while the opposite is also true. Good decision making starts with great accountability. The engineering accountability structure at Apple has always been dead simple.


Here are how features teams were staffed when I joined Apple in 2012:

  • Each feature has a designated Engineering DRI or Directly Responsible Individual. This is the Steve Jobs management style and something Apple has retained; arguably the greatest reason why Apple is Apple. It flattens accountability and puts experts in charge instead of general management practitioner.

    • How is the Engineering DRI picked? It is often the engineering team with the most expertise to build the feature. Steve would bypass all the org structure and check-in or ask questions directly from the DRI. 

  • Each Engineering DRI is supported by an iOS EPM from the Program Office. Responsibilities of an EPM include:

    • Define the scope of the work.

    • Identify and work with dependencies across engineering, design, product marketing, QA to craft the feature development schedule.

    • Ensure alignment across dependent teams to support the feature work.

    • Owners of the holistic project plan.

    • Drive exec reviews with Scott and direct reports.

    • Report project status via weekly status compiled and shared via email (that’s right, email). Scott was a leader who loved details and read every single status line. Status was sent to him on Friday, he would ready it on Sunday, and fire off questions via email by Monday Morning.

The decision making flow in 2012 was a simpler time. iOS SW Engineering and Mac OS SW engineering were separate orgs and platforms. 

  • Day to day decision making is the Engineering DRI’s domain.

    • Of course the discussions around the decision are collaborative and exactly the point of the DRI model - experts making expert decisions.

    • Any day to day important decisions that needed to be surfaced to Scott and direct reports were surfaced via the Weekly Status Report sent every Friday. If there are questions or comments from Scott, we would have emails directly addressed to the Engineering DRI and Engineering Project Manager on Sunday night, Monday morning.

  • Two ways we made strategic decisions -

    • If the decision is a straightforward 👍🏽 or 👎🏽 - Engineering DRI and EPM would put the relevant information - problem, proposed solution, any consequences or trade-offs - in the weekly status report. By Monday morning, we had a decision of approval or decline with follow-up questions from Scott.

    • If the decision is not straightforward and requires a more in-depth discussion, the EPM would schedule an executive review with Scott and the appropriate functional leadership to discuss and decide upon a direction.

Simple, straightforward; Decentralized day to day decisions while centralizing strategic decisions.

The Post Forstall Era - Unified Software Engineering Organization

With Scott Forstall’s “departure” in late 2012, Craig Federighi took over the iOS Software Engineering team. I still remember vividly as we all sat in the Town Hall conference room in Infinite Loop 4 as Craig Federighi introduced himself as the combined iOS and Mac OS SW Engineering SVP.

Although the Mac OS SW Engineering team had its own Program Office similar to iOS with their own processes, the concept of DRI was universal. Eventually, iOS and Mac OS engineering went through consolidation over the next few years around functional centers of excellence - Web Technologies and Comms (Safari, Web Technologies, Messages), iOS Systems (Springboard, UIKit, NetApps, etc), Camera and Photos (Camera, and Photos App), etc etc etc to name just a few under Software Engineering.


The Challenge In a Unified Engineering Team

Over time, the cross-functional nature and the multitude of features across Apple under the unified leadership of Craig meant he was required to cover more ground with less time. So, the challenge now is how do you maintain the accountability DRI structure whilst preserving a direct line to the SVP for strategic decision making?  The solution - the concept of the Exec Sponsor was introduced and additional DRI roles were elevated. This meant more strategic blockers could be resolved closer to the frontlines and allow for rapid decision making without bloating the accountability structure.

Let's dive into additional roles elevated:

  • The best decision made was designating a QA DRI.

    • They are the gatekeepers before the release goes to you, the users.

    • The QA team is centralized within the Software Program Office. This central QA team is responsible for not just feature testing but Technical Acceptance testing of iOS, full O/S UI sanity testing, backwards compatibility, everything across iOS and Mac OS.

    • The QA DRI worked with the Engineering and EPM DRI from the very beginning of the feature planning to ensure we had test plans, acceptance criteria and metrics early on instead of playing catch after.

  • Human Interface Producer for UI centric features.

  • Product Marketing DRI.

  • Certain functions like Apple Pay had Business Development and Merchant Support type functions.

So, how were decisions made in this new structure:

  • The Exec Sponsor would be the Functional Engineering VP or Engineering Director who is the expert pertaining to that particular feature.

  • Day to day decisions to a large degree remained within the combined purview of the Engineering and EPM DRI.

  • If a day to day decision had a cross-functional impact, the Engineering DRI and EPM, along with the impacted team DRI’s, HI Producer, Product Marketing, and QA DRI would meet with the Exec Sponsor on a weekly basis to discuss and decide upon these blockers.

  • If the Exec Sponsor determined that this decision has a wide enough impact that we will need to take this to Craig, then the EPM schedules a meeting with the appropriate functional VPs and Craig to discuss and decide on the issue.


What this new structure does is pushes more strategic decisions to the experts who lead the experts without diluting or increasing the hierarchy which may hinder effective decision making and, most importantly, innovation - that is the Apple way.

Staying flat is hard but there are some key lessons we can draw from the Apple way:

  • Trust in experts; empower them to make decisions - Time and time again, I saw Craig, and the Exec Sponsors rely upon the DRIs to provide them their opinions, data, push back, collaborate on hard issues and come up with ideas to resolve some insanely tough questions. But, ultimately, these leaders made the tough calls and owned them.

  • Elevate skills and expertise, not the title - Engineering DRIs are not directors or VPs, they can be individual contributors who are best suited for the task at hand or the Engineering Manager of a given functional area with the most deliverables. For example, an iCloud Photos feature’s DRI will be the Engineering Manager from the Photos App engineering team. An iMessage feature could have DRI who is an individual contributor engineer in the Apple Wallet team. Give them ownership and pride in the work they do and you will build A+ players, not worker drones..

  • Decentralize tactical decisions; Centralize strategic decisions - The power of DRI or Directly Responsible Individual is a powerful one. Not only does it create accountability but visibility and career growth. By enabling a DRI structure for day to day decisions, you open up the leaders to have time to evaluate and make strategic decisions, whilst allowing frontline engineers to become experts and grow personally.

  • QA needs ownership & authority from the start - I cannot emphasize this enough, you need test and quality engineers involved from the start. If you don’t have a dedicated QA team then agree upon the exit criteria for each feature or product as part of the requirement and planning phase.

  • Build centers of excellence, not tiny empires - how do you build centers of excellence and a bench full of experts? Allow individual engineers to take on large and important work. You don’t need an army of engineers working on features; sometimes a small squad of experts on your bench is enough. How many engineers do you think worked on Apple Pay for the Web or the iOS Home App v1.0? Hint - I can count them on one hand.

Staying agile is more of an exercise in decision making structure than organization structure. Hire experts, build functional orgs, and keep innovating. 

That’s it for this week. See You Next Time! 👋🏽


P.S. Take small steps, dream with abundance, and never stop learning.

Massive thanks to my brother, Haider, for being my Editor Extraordinaire.

Leave a comment



I am really excited about this! We have a new look and vision. 👀 😎🤩

First - let’s talk look…

I am a huge fan of eboy and the isometric pixel art style. So, new logo, new banner, and feeling dope. I should get these on stickers 🤔.

Massive thanks to 99designs design competition feature and the amazing work by Nouamane Zarrouki (Opibert)

Now, Vision Time!

My initial vision for this newsletter was about writing on how to manage technology programs. Frankly, that is as vanilla as it gets, boring, and not my superpower.

So, after spending many weeks soul searching and nailing down what I had to offer, here is the new vision -

Actionable knowledge in your inbox on how to think, build, and innovate like Apple & Google.

I have been lucky to have shipped products at two of the biggest names in tech and that taught me a ton of lessons worth sharing. That is the vision, that is my super power.

Welcome to Building Romes 2.0!

How would you rate this week’s newsletter?

😄 Great😐 Average😒 Not Satisfactory

If you enjoyed reading this, please do share with your friends, family, colleagues, Linkedin peeps, twittersphere, or you know whatever/wherever you have.

Share Building Rome(s)