macrumors bot
Original poster
Apr 12, 2001


In an interesting blog post, Posterous co-founder and former Apple engineer Sachin Agarwal describes how Apple runs its engineering divisions "like a huge startup", with engineers frequently being moved from project to project based on whatever is the highest priority at the moment. As an example of the effect of Apple's lean staffing policies, Agarwal points to the company's stagnated Remote application for the iPhone, which has yet to see such enhancements as iPad compatibility or iPhone 4 retina display support.
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.
While the engineer responsible for Remote is not identified in Agarwal's post, it is believed to be Alan Cannistraro, who has been one of the primary lecturers in Stanford University's iPhone Application Development course [iTunes Store] that has seen significant success through Apple's iTunes U program. Cannistraro has introduced himself as the developer of Remote as part of that course.
Startups also thrive by keeping things lean. Great startups have small teams that can build quickly and pivot when needed. When working at a startup, you don't own just one part of the application: you have to be able to work on whatever needs your attention that day.
Apple's staffing strategy even goes as far as moving engineers between platforms, as had been suggested in reports earlier this year claiming that Apple had diverted resources from Mac OS X 10.7 development in order to push forward on iOS 4. While the lack of dedicated projects for engineering staff provides for efficiency and flexibility, as well as offering employees opportunities to develop breadth of expertise and fresh intellectual experiences, it can result in certain low-priority projects such as the Remote app becoming stranded as their developers are redirected to other areas.

Article Link: Apple's Flexible Engineering Teams Said to Operate Like a Startup


macrumors 601
Oct 20, 2008
Please apple, update the remote app! It's kind of buggy on my iphone 4 :(


macrumors 603
Jun 19, 2009
this explains why a lot of Apple's "other" software is always behind the times. don't use it, but i've read that software like FCP and some of the others is still only 32bit because Apple hasn't got around to porting it to the new API's yet


macrumors 65816
Apr 26, 2005
..."like a huge startup", with engineers frequently being moved from project to project based on whatever is the highest priority at the moment...
like the article inferred in parts, this is a problem. why not get a higher quantity of quality engineers and speed production of more products? this excessive cost savings is lame, and i doubt the salary savings is really adding that many pennies to the aapl stock i own.

...claiming that Apple had diverted resources from Mac OS X 10.7 development in order to push forward on iOS 4...
Isn't this just plain old news? This sort of thing has happened ever since apple debuted their flavor of a cell phone.


macrumors 65816
Jan 8, 2009
Hmm. Do they really need a lead developer to port the Remote app to an iPad version? Put some lowly intern on that job.

Yeah - I was thinking the same thing. It couldn't take more than a few days for any decent programmer to update Remote for the iPad and O/S 4.



macrumors 6502a
Jan 2, 2010
Menlo Park, CA
Great concept in running a company.

That explains why the MacBook Air, (just recently) Apple Displays, 10.7 , FCP, FCE, iLife (Heck Randy ubellos is the lead engineer for iMovie iPhone , FCP, iMovie for iLife) , iWork all see slow updates.

This type of managing is also to drive the psychological factor of their teams.


macrumors 65816
Aug 3, 2007
I guess this is why Apple seems to forget about what it makes. They haven't updated 85% of the original iPhone apps :(


macrumors 65816
Feb 23, 2005
At least update it for the would think that the very few apps they have out they would update them for now products.


May 18, 2008
They've been working like this for almost their entire history, minus the times they operated like every other major company and look what happened there.

Maybe apple seems different because they really ARE different from the mold. Google is another good example of a unique workplace environment.


macrumors 603
Jan 6, 2004
Western US
Oh, that explains why iDisk sucks. Maybe the guy who wrote it has been out buying black turtlenecks for Steve. Or he died a decade ago and no one noticed.


macrumors regular
May 14, 2008
Ottawa, Canada
Yeah - I was thinking the same thing. It couldn't take more than a few days for any decent programmer to update Remote for the iPad and O/S 4.


Yeah. The remote app seems extremely simple to update. Weren't much more complicated apps updated to higher resolutions/iOS 4 compatibility within days of release?

Don Kosak

macrumors 6502a
Mar 12, 2010
Hilo, Hawaii
Yes, updating the Remote app will probably go to more junior team member - but it still might require the original developer to point that junior member in the right direction. (Brief them on the code, answer questions, etc.)

Overall, this Team Allocation approach has major benefits, especially compared with "walled" structures with engineers assigned to projects "for life".

It encourages reuse of technology between different application silos, as the developers are familiar with those technologies. Developers are more aware of interoperability issues, and more likely to feel ownership of the entire assembly of different products. This probably helps a lot with bug acknowledgement and correction.

The drawback is in judging optimal team size. Making the team too big creates expense, idle hands, coding for codes sake, and reduces the energy level and efficiency of the team. Make the team too small, and some things may slip between the cracks.

Ideally, the only things slipping between the cracks are inconsequential to the business. (ex: the Remote App, or Texas Hold 'em App.) It's a warning sign that your team is too lean when larger issues slip. (ex: WiFi patch for iPad.)

Microsoft seems to really focus on Silo's -- partly because of US Government intervention in the anti-trust investigation that created walls between the OS, and Apps groups.

Google seems to operate in more of a hybrid model. It has longer term teams, some of which operate in various remote offices (ex: New York, Pittsburgh). It also has project lists that engineers can select projects from, and the famous "20%" innovation projects.


macrumors 601
Nov 19, 2007
Georgia, USA
I work for a software company, and that's exactly how we work. There are only 3 developers (including myself) that constantly switch between MANY different projects and applications.

I actually like working like this because I'm not stuck just doing the same thing from day to day.


macrumors regular
Jun 16, 2005
London, England
Totally! My reaction in those words too

Throwing more developers at a problem like this doesn't usually help (trust me, I've seen it happen). It takes time to find and integrate new development staff into a company.

Having said that, I think Apple's spreading itself too thin these days and some of it's software products are beginning to look distinctly out of date...
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.