I just walked out of a fascinating panel at SXSW Interactive by the Meetup guys, about how their company's R&D culture evolved from fun/fast/startup-mode to, boring/slow/process-oriented, and then back to fun/fast/"self-organized". They call what they have now "100% Time".
Here are my unedited, loosely organized notes...
Great entrepreneur/startup culture first few years. One day announced "we're no longer a startup and we need processes". Within a year, Product and R&D were at each other's throats and engagement had plummeted. The processes had made their business like every other business and crushed their company culture. Leadership had 2 week offsite to figure out what to do. Could not decide. Decided to hold a 6 week Hackathon to more buy time to figure out what to do.
Held company meeting to tell everyone to put current projects on hold. Told them to pick a 6 week Hackathon project. 3 rules:
- Project must add value
- Must convince 3 people to work on project w you (1 product, 1 frontend dev, 1 backend dev, 1 support)
- Must impress your peers
First day, people pitched their ideas to the company, including leadership. Leadership tossed out their feedback and then walked out and went to see a movie.
Teams then formed. Teams commandeered conference rooms and other spaces. Teams got to work. They got more built in those 6 weeks than prev year. Staff's engagement level was all time high. It was a clear choice to keep this "self-organizing" team structure.
Every so often they have a deadline and slip structure back in, and it always turns out to be a mistake. They learn this lesson frequently as structure creeps in.
On usability:
The theory that Developers/Engineers can't understand humans and need product and design processes to drive usability is false. Typically developers/engineers just don't have access to the users. At Meetup Developers/Engineers routinely watch normal users use their product, and it us very humbling for them and the usability of the product improves because of this.
On hiring:
- To get things done, their developers have to be able to work with others. People who just want to sit alone and hack will not get anything done, since a rule is you must work on your project w 3 others. Makes hiring really difficult. But finding the right people that fits this mold pays off.
- interview process: written test, then meet w 4-5 people from all sorts of groups, then meets w leadership. Takes Joel Spolsky approach where one maybe = No
On management:
- Tried peer-to-peer reviews. Created too much work. Now peers are asked to voluntarily give feedback to an employee's manager
- everyone has a manager. Managers are essentially the top technical guys. Managers are also on dev teams themselves. People on the same team do not have to have the same manager.
- everyone works at their office. Not remote.
They encourage lots of communication channels. Small company. 60 people. Their office is mostly one big open space. Lots of overhearing.
Interesting comment... "Leadership can't create a company culture. It rises out of who you hire. Hire entrepreneur startupy people and you'll have and entrepreneur startupy culture. Your job as leaders is to not squash the culture."
Q&A:
How do you resolve product vision conflicts?
- we're extremely transparent, so everyone understands the vision, sales/finance, product adoption, etc
Do you have a product roadmap?
- no. This made it really hard to raise money. When people ask, they make shit up. Normally it doesn't matter.
Do you have a company wide development methodology?
- no. Teams pick their own methodology.
Do you have any dev metrics or goals?
- nothing company wide. Each team tells us how we should measure their success. And I spend a lot of time asking the teams questions and offering suggestions as they design, develop and set milestones.
Release Cycles?
- week releases every Tuesday
- QA person signs off
Do you think this model would work if you guys had Customers, not Users?
- I don't know.
Do you think this model would work for a much larger organization?
- we don't know yet.
Have you written about this?
- no. But here are 2 books we read after we started doing this:
Maverick
Seven Day Weekend
What did you learn that's not common sense? ;)
Posted by: Pat | March 17, 2009 at 08:24 PM
Did you read what I wrote? Running your business as a permanent Hackathon is not common sense.
Posted by: Bill Boebel | March 17, 2009 at 08:30 PM
I don't know... it all sounds grand, but apparently they only have 40ish people at the moment (and they are expecting to double this year http://docs.google.com/View?docid=dg2z5whw_41cb322p).
I'd be interested to see how the next year goes for them.
Posted by: Stu | March 18, 2009 at 12:35 AM