Apple product manager android#

Here's how we have DRIs: We have a cross-functional team working on Android (frontend, backend, QA, product manager, marketing, design, BD, account management) with the eng lead as overall Android DRI. It's one of the most valuable, practical things I learned at Apple, and it's a tool we use at Flipboard when it seems helpful.įlipboard's a startup, and we don't have nearly as many formal processes as Apple does. Obviously, I am a huge fan of the DRI model. At other times, they will act as DRI and exercise more of their leadership muscles. Instead, an engineer can feel comfortable knowing that sometimes they simply show up and other people will tell them what to do, freeing them to focus on the challenge at hand. Having a DRI is also efficient for the team because you don't have fifteen people all worrying about the same things. You will obsess over metrics and track down issues and rally people and want to do nice things for them when you achieve something great. When you feel like something is your baby, then you really, really care about how it's doing. The benefit here is more ownership than accountability. In a fast-growing company with tons of activity, important things get left on the table not because people are irresponsible, but just because they're really busy.

When everyone knows that something is important, but no one feels like it's their responsibility to see it all the way through.

It's not just 'the marcomm team,' it's a specific person. This is not only reassuring to other people working on the same issue, but it also helps cross-functional management gain clarity on who *exactly* is driving what. You assume that they have figured out a dependency and are waiting on that to happen first, or that they are working on something behind-the-scenes that will prove useful. When you trust your DRI, you don't have to worry when you don't see any recent activity about that issue.

When it's unclear who's got the ball and what should be happening, everyone trusts that the DRI is driving.

If something keeps failing on the prototype testing lines, then you could have a TPM (test program manager) as DRI, working in conjunction with the Apple engineering teams, testing equipment vendor, and contract manufacturer teams. Then usually a PD (product design) engineer will be the DRI, and they will work with the HW engineers to resolve the problem. Say it's mostly a mechanical engineering issue with a little bit of HW involved. Often this is an engineering lead or an engineering program manager.

When solving a complex, cross-functional engineering issue, you want a DRI who is responsible for driving the team's sleuthing until the issue is solved.More frequently, having a DRI helps you in the following situations: The MobileMe screwup is one of those few examples where something goes poorly and then someone gets fired. In the minority of cases, it's about accountability after something went wrong. With DRIs on everything from major initiatives to bug reports, a lot of questions of ownership are cleared up.