In the months preceding the release of the iPhone, it was rumored that Apple removed a key number of software engineers working on OS X 10.6 and placed them on the iPhone team to ensure that everything was ready to go in time for launch.
That said, former Apple engineer and Posterous co-founder Sachin Agarwal has an interesting blog post up describing how Apple runs its engineering teams in such a way as to emulate a bustling start-up. In other words, the top engineers at Apple aren’t stuck working on one project in perpetuity, but are rather moved around as management sees fit to meet ever-changing needs and priorities. In doing so, Apple ensures that it has its best minds working on its most important projects at any given time.
As an example, Agarwal brings up the fact that Apple’s remote app for the iPhone hasn’t been upated in a long while, precisely because the person who coded it is off working on other and higher priority initiatives.
Yes, the Remote app is due for an update. But here’s why it hasn’t been updated: the person who wrote it is busy working on other things. Yes, the person, not the team. (He’s a good friend of mine)
Apple doesn’t build large teams to work on every product they make. Instead, they hire very few, but very intelligent people who can work on different projects and move around as needed.
The engineer behind the Remote app is largely believed to be Alan Cannistaro, one of the primary lecturers in the popular iPhone Development course at Stanford who also happens to be a DJ by night.
The engineers on the Mac OS and iOS teams move back and forth between the two projects based on release cycles and what needs to ship next. Even on Final Cut Pro, team members were sometimes asked to work on the other pro applications if they needed help to ship on time.
An engineer at Apple can’t just assume they will be working on one project forever. And teams at Apple won’t grow to sizes beyond what is absolutely necessary.
Steve Jobs often exclaims that when it comes to releasing groundbreaking hardware and intuitive software, hiring the right people is ultimately more important than blindly dumping money into R&D. In that vein, Apple trusts that the folks they have working on their core software are talented enough to quickly hop from one project to the next without missing a beat.
Agarwal concludes that Apple’s engineering teams operate similar to folks in a start-up, where employees must work quickly, efficiently, and “be able to work on whatever needs your attention that day.”