Comment by adriand | Hacker News Reader

Comment by adriand | Hacker News Reader

This is the most interesting part of the article for me:

> Apple, which has about 110,000 employees, breaks big projects down into smaller tasks. Those are assigned to small teams, and each subtask is given to a specific employee, who must get it done — what Apple calls the “directly responsible individual.”

> Pearl has copied this system. “In leading small teams, that’s very effective,” Mr. Gardner said.

Apparently this directly responsible individual (DRI) approach is famous, but it's the first I've heard of it. Is anyone able to comment on how effective this is?

Say you have a multi-disciplinary team of UX designers, a PM, front-end and back-end devs - I'd be accustomed to seeing a team lead in charge of the project who is the DRI for the whole thing, but do subtasks for the project also get parcelled out in formal, DRI-fashion? E.g. user stories for a web app like, "As a user I can log in securely", would this get a DRI assigned to it? What happens when the DRI doesn't have time for that task, are they able to pass it along to someone else, and would the decision to punt it over to someone need to be run past someone, typically, or is the DRI empowered to make decisions on delegation/task transferring?

The way it worked a few years ago, at least, each year new tent-pole features were pushed down from the top. These features came from marketing, design, and Steve Jobs himself. There was always a much larger list of wants than possible for a given release, so the ever powerful hands of EPMs (engineering project managers) would help delegate the tasks and schedule a years worth of work.

The company as a whole loves small teams, they find them effective, and most managers are only given 5-10 engineers before there's pressure to split up into smaller teams.

During each start of a new release, engineers would pick and chose which features they wanted to work on. Depending on the team, some influential engineers and managers could fight for ranking the features they thought most important.

Features weren't always user visible things, one year, one of the tent-pole features was porting everything over to 64-bit. Of course this feature affected the entire software organization, so that radar was broken up into large teams, and then each framework and application had a radar.

Usually the person responsible for the feature at the team level was the DRI and anyone on the team could complete any of the radars associated with it, but the DRI was the main contact. They would be the direct line to the higher level radar DRI and so on. If at any point in the chain you didn't have NDA visibility, the EPM would be your contact.

Pardon my ignorance, can you explain what a "tent-pole feature" is (I'm guessing a feature that enables others, but that seems too general), and what a "radar" is?

IIRC, Radar is an issue in the Apple Bug Tracker.

Radar is the company wide task/bug tracking system, you'll see rdar://0000000 attached to random things across the net, those point to issues. See http://www.openradar.me for publicly tracked issues.

Tent-poles are the those bullet points that you see in a keynote. https://9to5mac.com/2016/06/13/ios-10-features-developers/

Isn't this how every organization in the world operates?

How can anything resembling non-hobby work get done without a "directly responsible individual"?

Two thoughts:

1) That's not something my department handles. Contact department B; a committee will review your question and their analysis will be considered at the next management committee team meeting at the end of the quarter.

2) Parliament / Congress

Implicitly, yes, some person is always doing the work. But in my experience a "DRI" culture is one where at the end of a meeting it's 100% clear what needs to be done and who is doing it. That doesn't happen in a lot of companies, because a lot of companies call meetings to brainstorm.

Reply on news.ycombinator.com