What it took to propose and deliver a project on iPhone at Apple

A lesson from the iPhone team on how to propose work that actually gets a yes.

One of the clearest signals that you’re ready for a senior leadership role is your ability to propose, manage, and deliver projects, not just the ones assigned to you, but the ones you identify and drive.

You might be wondering: “Isn’t that just what a project, program, or product manager does? Why does a senior engineer need to propose projects?” Because the role is changing. 

In the age of AI, the expectation is no longer just that you write great code. It’s that you think in terms of business goals and impact. Proposing a project and connecting it to a measurable outcome is one of the clearest ways to demonstrate that. You can still think like an engineer: data, quality, reliability, product integrity, scale. However, you also need to show your acumen through initiative, execution, and results, and do it with consistency. 

I know that sounds like a lot. That’s exactly why I’m here, and we’ll take it step by step.

It’s tempting to pitch a bunch of ideas and see what sticks. But that approach works against you, especially when you’re trying to demonstrate growth. Proposing the right project, at the right time, for the right reasons, that’s the skill.

Here’s how I’ve done it and what I learned along the way.

The first step isn’t pitching. It’s listening long enough to understand the terrain.

Start by understanding the landscape

In November 2024, I was four months into a transition from Senior Software Engineer on Macs to Senior Engineering Program Manager on iPhones. I spent the first month just observing: how the iPhone line of business operated, where it differed from Macs, and where friction was building.

One pattern kept surfacing: code quality issues with certain cross-functional teams were creating downstream pains such as longer integration times, instability in the codebase, and a lot of noise during crunch time (build phase for iPhone).

Diagnose before you prescribe

I didn’t jump to a solution. I spoke to cross-functional teams and managers across the org. What I found fell into three groups:

1. Teams that didn’t know there was a problem. Or at least didn’t understand the downstream impact they were causing.
2. Teams that knew but were stuck. Aware of the issue, constrained by resource contention, unable to act.
3. Teams that needed a realistic solution. They understood the problem and wanted help with a rollout that fit their existing process and timeline. This is where I started.

Present your recommendation clearly — even when it pushes back

When I brought my recommendation to the senior engineering manager on our team, someone with over a decade of experience, his approach had real tradeoffs. I had tried a version of it myself on Macs. I knew why it would fall short.

So I named them, in a meeting, concretely:

“Here are the tradeoffs of your approach and why. Here’s the alternative I’m proposing, and the expected outcome. Here are the next steps. Shall I get started?”

That’s what managing up actually looks like: leading with the tradeoffs, proposing an alternative, and closing with a decision. Not winning an argument. Giving your stakeholders what they need to say yes.

I was confident because I wasn’t theorizing. I had dog-fooded the approach for nearly a quarter. Using your own proposed process before asking others to adopt it is one of the best ways to develop real intuition and credibility under pressure.

How to sequence and deliver

1. Start where there’s already energy. Pick the team that’s motivated and has capacity. Starting there isn’t a shortcut, it’s smart sequencing. It lets you build proof before tackling the harder cases.
2. Expect scope creep and roadblocks. Plan for them anyway. This project took longer than expected. That’s normal. What kept it moving: regular check-ins, asking for help when we were stuck, and proactively communicating progress to the people who needed to know.
3. Name this as phase one, not the whole plan. Framing your work in phases signals strategic thinking. The teams who didn’t know there was a problem, and the ones still stuck, those become phases two and three. That’s a roadmap, not just a project.
4. Let the results do the talking, but don’t be quiet about them. Code quality improved each quarter. Integrations got smoother. The work earned recognition. That doesn’t happen by accident, it happens because someone kept the team focused, communicated progress, and saw it through.

Proposing and delivering the right project is one of the highest-leverage things you can do as you move toward senior leadership. It requires seeing around corners, communicating under pressure, and driving cross-functional work that isn’t in your job description.

Remember, this is just the tip of the iceberg, which is why I called it phase one. The next phases are where most people struggle: managing the project once it’s underway, delivering despite shifting priorities and scope creep, and maintaining momentum after delivery so the work actually sticks. I’ll be covering each of those in the posts ahead.

Tweet

Pocket