What Apple and Elon’s Boring Company Taught Me About Project Management

A19Grey
6 min readApr 4, 2024

--

This is the first in a series I’ll be writing to share tips I’ve learned for ‘getting shit done’ managing projects. My background — applied physics PhD from CalTech then doing hardware at Apple, Boring Company, and now a startup Trace Vision.

The iphone is the largest consumer product in the world and a new flagship version ships every year. And not just every single year, but every single September and even more specifically around the 3rd week of september.

This is a level of insane and incredible precision that we’ve become numb to. Have you ever managed a large project and predicted the delivery date to within 2 weeks?

Yes, some notable exceptions with Iphone X and Iphone 12 but even these were only a few weeks late! And the Iphone 8 still launched on time in 2017 cycle.

So, how do they do it? There are two core principles that I’ve come to call “Descope your way to success” and “Create a stakeholder feedback loop”.

And it has nothing to do with fancy project management software. I assure you. The iphone is kept on schedule and ramped largely using charts made by hand on Keynote slides!

Descope your way to success

First — it’s impossible to ‘predict’ how long a large multi-person complicated task will take. Full Stop. Please stop thinking it’s possible.

It’s not even asking the right question. You’re treating the project as a single fixed thing and then treating ‘time’ as the free parameter. It’s like you’re imagining widening or shrinking some little box called ‘time’ until it’s just the right width for the project to fit neatly inside.

But the project is not a fixed thing! It can change. And specifically it can and should change to fit the schedule.

See, if the goal is “to sell 100 million iphone 16’s in 2024” then… ther’es a lot of freedom on what, exactly the iphone 16 is. Maybe the iphone 16 should have 6 cameras, a new quantum camera sensor inside, a 240Hz display screen, and maybe it has a sapphire front glass or… maybe it doesn’t have any of those.

Exactly what the product is, the features it has, are all choices you make in the design and launch of a product. You control this! So no one can predict how long the iphone 16 will take to make because it uh, could depend on what they decide to put inside it!

Instead, what you can control is when the iphone 16 will ship and then asking “what features am I pretty confident can be done in time to ship the f*king iphone by the third f*king week in September” (iphone mass production ramp season drives everyone a bit crazy and even the execs start to drop f-bombs).

You can make the project take less time by making hard choices such as cancelling quantum camera sensor, and not doing the sapphire glass screen.

This is descoping your way to success. Start with the time for the project then throw out stuff until the project fits into that time. If someone asks you to finish something by Wednesday don’t say you can’t do it, lay out what version of the project you can do by Wednesday, or what resources you need to do it by then.

As Elon often said ‘you can buy more equipment, and you can hire more people but you can’t buy more time’

Working at the Boring Company was a lesson in hitting schedules. An engineer once told me it would take a few days to make a wiring diagram for our work site. Instead we sat down and did it in 15 minutes together. Implicitly he had assumed I needed him to do a good job, but if we relaxed that constraint and settled for doing a bad job with ~30% accuracy we could do it way faster. Then we could just buy an extra 30% of wiring (copper wires don’t go bad). This meant we could order wiring today and hammer out the details while it shipped.

Scope the project to hit the schedule. When you get close to the deadline — descope your way to success. Hit the schedule by doing less.

Also this is one good reason to NOT ANNOUNCE FEATURES BEFORE LAUNCH. It commits you to including some specific detail that may take longer than you expect so you risk delaying the project OR risk being embarrassed when you cancel later OR you hit the schedule and just do it poorly. Apple did this once when they canceled their wireless charger mat. I was there at the time and everyone felt very stupid for being convinced to announce something before it was ready.

The psychological fact is that people will 100% delay projects to avoid looking silly for not shipping something they said they would instead of just cancelling that part. It’s super normal and very human and I’ve done it too. Everyone has. So if your goal is to hit a schedule don’t announce the product features early.

Does Apple tell you 6 months early what will be in the next iphone? No, and trust me, along the way a lot of things that were supposed to be in that product are absent. Things are getting cut and descoped all the way up to ramp.

Descope FTW

Create a Stakeholder feedback loop

Now, descoping to hit a target delivery date is not a new concept and it’s often just called “doing a shitty job”.

Just about anyone can achieve target delivery dates by just doing it poorly. I assume no one reading this is interested in that particular solution….

This is why you need *someone* that ‘keeps you honest’ and decides on the right tradeoffs to make to save time. At Apple that was the Industrial Design (ID) team. They were the ones who obsessed over everything and had final say on what features were critical. A significant project that I and hundreds of others had worked on for ~5 months was cancelled when the current technology of a single component just wasn’t good enough to make the design feel right. I was the module lead for one of the key new elements… and I wasn’t mad, it was extremely very much the right call. We canceled and didn’t look back.

Day to day this is the role of a Project Manager, someone who is making these calls and deciding which blockers can be discarded and which blockers have to be solved. But to avoid delivering total shit the PM needs an external resource that makes the bigger calls. At a startup like the Boring Company that was usually the CEO, at Apple it was Industrial Design. When possible it should be the customer, but you cannot beta-test every single line item in your project. Famously Steve jobs said ‘no’ to a shitty plastic screen and this is why the first iphone had a nice glass one at launch.

This is why I say it should be *someone* not a spec sheet typed up before or some agreed upon plan. It needs to be someone at the company who has enough authority to say “no”. If you assign this role to some random schmuck that person will try to say no… and then get steamrolled and quickly learn that just saying ‘yes’ to anything is the best survival strategy.

The person can often be your head of product or the product focused design lead for the project. Probably this person should talk to customers a lot. Or be well tied into the vision for the company and the problem to be solved (we don’t all have customers yet!).

Your job as a project manager is to make sure you have that external stakeholder who cares about the quality of the product otherwise in your quest to hit schedules you’ll deliver a pile of shit… right on time.

Conclusion

The concept is simple — if you want to actually hit deadlines then you have to make the deadline the important thing. If the deadline is the most important than other things are not. So that will always mean features and details you wanted must be sacrificed to hit the deadline.

To make sure you don’t sacrifice the wrong stuff you need someone keeping you honest.

Descope your way to success = Sacrifice product features to hit timelines

Create a stakeholder feedback loop = Get someone to make sure you’re sacrificing the right stuff

It’s not easy. It’s incredibly very much hard. Which is why only a few companies/teams do it really well. Good luck.

Subscribe to get the next pieces which will be shorter technique pro-tips about how to do this well.

Reading List

The Goal, BUILD

--

--

A19Grey

Was CalTech physicist, now a Scientist. Econ/Politics are a hobby. DM me if you tried to prove the Twin Prime conjecture #forScience