3 ms·
I really like seeing this approach listed: "resourcing for projects is purely voluntary. A PM lobbies group of engineers, tries to get them excited about their
by michaelmartin 14y ago
I really like seeing this approach listed:
"resourcing for projects is purely voluntary. A PM lobbies group of engineers, tries to get them excited about their ideas. Engineers decide which ones sound interesting to work on."
That sounds exactly the same as how Github's engineers work.
It's an awesome concept; no-one can justifiably be bored with their projects if they chose them. And if you can't get anyone interested in working on the project, then it's a good indicator it may not be a project worth completing for the company anyway.
I'm sure there are times when someone has to say "We need someone to do this", but I'd be curious to hear from someone who works in one of these environments how common an issue that really is.
- moondistance 14y agoI'm curious - what happens when an engineer wants to propose an idea? Do they need to get a PM on-board to lead the project? Who decides if the idea is good? The PM/engineer divide feels uncomfortable to me, but I have limited experience with these roles, so it's likely simply for lack of knowledge. I hope someone can clarify this for me.
- michaelmartin 14y agoFrom the article at least, it seems like there aren't a whole lot of PMs at Facebook. If an engineer has an idea, they seem to be more encouraged to just find some people to work with, build it, and then roll it out to a very small section of Facebook's users and see how they react to it. Good ideas might then be taken further, but bad ones (Or I guess, ones people just don't care about) won't be. (I don't work there though, so I have no way of knowing if that's right or not, sorry!)
- wilfra 14y agoFrom the article: 1/10 PM's to Engineers and 500 engineers = 50 PM's. That's not an entirely small amount for Facebook since they don't have a zillion different products and features that need to be owned, like a company like Microsoft or Google.
- jacques_chester 14y ago> It's an awesome concept; no-one can justifiably be bored with their projects if they chose them. Eventually people lose interest. It's only human. But The System has been written, it is in production, and it has accrued a healthy stock of user data. One day, The System breaks. "Only" tens of millions of users -- less than a percent of all Facebook users -- rely on the The System. But they rely on it utterly. Who will fix The System? Of the five engineers who wrote it: * Jack and Mandeep left to launch myfornaxisnatrr.com * Wei Li has moved to a different group * John doesn't want to touch it, he only came on board to help Jack * Michael was an intern but has since taken a job with Google. Uh oh! There's nobody around to voluntarily fix an existing system. That's boring, and there are no incentives for fixing bugs in obscure features because only launching successful new features gains visibility from higher-ups. Guess we'll need some mean old managers to round up a posse. If they care enough. Meanwhile, The System has acquired millions of users, cost millions of dollars to develop and operate and will now abruptly cause tens of millions of customers to become incredibly frustrated. And at no point has anybody stopped and asked: "Was this the Right System to build?"
- jrockway 14y agoThe world doesn't work like this. In addition to doing-whatever-they-want-24-7, people are also trying to get promoted. That means there is always an incentive to do some task that nobody else will do. This kind of causes talent to even out between high-profile new projects and not-as-fun legacy projects.
- jacques_chester 14y agoIt doesn't work like this in places where shit being broken is something management cares about. In places where the goal is to make engineers happy and to impress other engineers, there are incentives for behaviour that are perverse from the customer's point of view.
- angstrom 14y ago> That's boring, and there are no incentives for fixing bugs in obscure features because only launching successful new features gains visibility from higher-ups. Companies really should find a way to incentivize this. Rewrites are about as silly. "Write the next generation xyz." Translates to "No one here has any idea how xyz was written, so it's being rewritten instead of modified. We look forward to rediscovering the same problems we did the first time."
- TezzellEnt 14y agoThis sounds to me exactly how Valve and other organizations operate (http://blogs.valvesoftware.com/abrash/valve-how-i-got-here-what-its-like-and-what-im-doing-2/ http://blogs.valvesoftware.com/abrash/valve-how-i-got-here-w...). I think that if you get buy-in from the engineers working on the project it can induce ownership and a willingness to watch it succeed and work towards it's success. The issue occurs when there isn't adequate a/b testing (or something similar), which could create the fiasco such as facebook's switching of email addresses. Companies such as Google allow 20% time to work on projects that might not make it to production, or get killed after acquisitions. I think that policies such as those work better than code being committed on the fly.