2010: The year of the products
2009 was definitely the year of infrastructure at 37signals. We put in a lot of work behind the scenes to improve our hardware, software, and security setup. We also launched our biggest infrastructure project to date: 37signals ID. Infrastructure improvements are never over — we’ve got at least one big one brewing right now — but 2009 saw big progress on that front.
2010 is going to be the year of our products. With some of the big infrastructure projects behind us, we can focus more of our energy on improving our products. We’ve got some great ideas for new features, integrations, UI design/redesigns, streamlining common flows, etc. We have some new product ideas we may explore as well.
A new way of working
At the heart of the product renaissance is a new way of working. In the past each person at 37s has been pretty isolated. Everyone pretty much worked on their own own project. There was some overlap in a few spots, and occasionally a small team might come together to tackle something big, but most of the time it was every man for themselves.
We also had a tendency to pull people in different directions. We might ask someone to work on A, but then a few days later ask them to pitch in on project B, and then also ask them to help fix bug C. That makes settling into a focused zone really difficult.
In 2010 we’re going to change that. Here’s how:
Teams
We’re going to start working in teams.
A team is made of three people: One designer and two programmers. A system administrator will also assist the team when necessary.
To start, we will have two dedicated teams plus one slack team. The slack team is available to help either team, or take on other stuff that inevitably comes up. In March we expect to have a third team dedicated to the products.
We will also have one programmer dedicated to working with the customer support team on bug fixes and optimizations. This person will change every time teams reset (more on this below).
Time
Each team will stay together for two months (a “term”). When two months are up, the teams split up and form again with different people. This way everyone gets to work with everyone else.
During the two month term, there will be four iterations. An iteration lasts for two weeks. An iteration can tackle one feature, a variety of smaller features, or part of a bigger feature that will require multiple iterations to complete.
Each team will be asked to work on the same product for the full iteration. So, if Team A chooses to work on Basecamp for an iteration, they’ll stay on Basecamp for those two weeks. Two teams can’t work on the same product at the same time.
If something isn’t done in two weeks, then it goes back into the pot. Another team can choose to pick it up as a future iteration, or it may just die. This encourages team to make sure they have something launchable at the end of an iteration. The goal is to push new stuff out to our customers every two weeks all year long.
Projects
Teams can pitch their own projects or choose a project from a living list we’re constantly massaging. We keep the list in Backpack. Some of the items on the list come from customer requests, others our own ideas. Some of the projects are just half-baked ideas (“Custom fields in Highrise“), while others are fully fleshed out projects complete with basic UI ready to implement. We use Backpack’s comment feature to discuss the ideas and attach files to the list items.
Projects are selected one iteration at a time. They are chosen on day one of an iteration. When the iteration over, the team will choose the project(s) for the next iteration. Once the two month term is up, the teams split, reform, and choose a new project for the next iteration. And on and on.
Projects are managed in Basecamp. We’ve set up one project per team. Each iteration gets its own to-do lists and milestones. Each team only worries about their current iteration, so when it’s done, and they pick a new one, they create new lists and milestones. At the end of the two month term we’ll have all the iterations for that team in a single Basecamp project.
An experiment
We’re excited to see how this method of working works out for us. We’re about one week in on the first team iteration, and we like what we see. Team Alpha is working on a series of improvements for Highrise, while Team Bravo is working on an entirely new project. The slack team is working on a variety of things – some for Highrise, some for the 37signals ID Launchpad – and thinking about some new stuff for Basecamp and Campfire.
Once we have a few terms behind us, we’ll report back on how it’s all working. We wish you success in 2010.
(The original inspiration for this idea came from Scott Heiferman at Meetup)
Josh B.
on 08 Jan 10Interesting. What happens if Team Alpha works for 2 weeks on a feature, pushes it live, then disbands? Some other team needs to bugfix and support that feature after it goes live?
JF
on 08 Jan 10Josh:
One answer is: We don’t know yet. We’ll see what happens and how often that happens.
Another answer: The slack team can come in and help with post-release issues. We also have a support programmer to help with issues.
Of course if the feature is totally broken then the team needs to put other things on hold to get it fixed up.
But the idea is that since the iterations are short (2 weeks), most things we’re pushing aren’t going to be massive projects that could derail future development for weeks.
Richard Harrison
on 08 Jan 10Love it.
@Josh B – that’s one of the benefits, it gets all their employees working on all the different projects, and keeps their code/documentation honest.
1 designer + 2 developers = win. I would like to work like that.
Resetting the teams every 2 months is clever too, getting everyone working with everyone else.
Chris Cuilla
on 08 Jan 10This will be interesting. Correct me if I’m wrong but it seems like you are trying to apply the “least you can do” principle to organizational and project structure, recognizing that as you grow (people and products) so does the need for some level of structure and organization. Where some places would immediately jump to the typical corporate template, you seem inclined to ease your way there. I like it. I’ll be curious to see how it works out.
There are multiple aspects to learn about: productivity, morale, overall effectiveness in development of products, etc.
One question I do have though is in regards to product vision. Who “owns” this? Does this approach risk jumbling or meandering the overall vision and cohesiveness of any given product?
Brad
on 08 Jan 10Looks like you accidentally backdated this post to 2008. Cool stuff, btw.
Rob
on 08 Jan 10How rigid are the coding guidelines at 37s? Do any exist or can programmers create their own as long as they are consistent?
This is a large part in a having a rotating team that works on the same product.
Thanks for sharing.
JF
on 08 Jan 10One question I do have though is in regards to product vision. Who “owns” this? Does this approach risk jumbling or meandering the overall vision and cohesiveness of any given product?
The list of potential projects are within the vision. And if a team pitches a brand new idea, it ultimately has to be approved by “management”. Team Bravo pitched a new idea for this first iteration and loved it and gave them the green light. I don’t see us rejecting many ideas – our whole team has a great feel for what’s important.
Victor P
on 08 Jan 10Is one of the two programmers a sweeper? (as in Getting Real’s 3 Musketeers?)
Laura Creekmore
on 08 Jan 10I’m curious that you’re setting up projects by team, instead of by product. I wonder if you will find you would prefer to have all Basecamp-related projects together, etc., instead of by rotating teams.
Noam
on 08 Jan 10Very nice method! When the team resets, who decides who works with who? Not everyone works well together – for example person A will work much better (and have a better time working) with person B, while person C works well only with person D. Some people work well with everyone. How do you approach this, beyond looking only at member’s professional skills?
JF
on 08 Jan 10Noam: For the first go around we picked the teams just to make it easier. And we don’t have that many people so there aren’t really that many combinations. Within a year people will be working with everyone a few times.
Derek
on 08 Jan 10This seem a lot more rigid than the typical ethos of 37 signals. I understand that as your employee count grows, so do the problems of organizing them. It will be interesting to see how this plays out. Thanks for “experimenting” for us all!
Terry Sutton
on 08 Jan 10Woah – structure!
Angela
on 08 Jan 10This sounds like a great idea. It will be interesting to hear the results of this. Will giving strict timelines for each feature or project cause them to rush through certain areas? Or will it make them focus on what’s most important in that project so time isn’t wasted on the insignificant things? (I see that quite often in this field – spending too much time on the little things that don’t really matter.) Or will the pressure of the strict timeline that they have to work on it make them be more valuable with their time and get even more done than they would have otherwise. I guess we will find out. I think it’s great that you are experimenting with this new process. Good luck Jason!
Tim
on 08 Jan 10I’m with Derek. I’m surprised by so much structure and apparent “rules” coming from you guys.
That being said, it sounds good.
JF
on 08 Jan 10So much structure! 3 people working together! Short, focused projects! OMG!!!
EH
on 08 Jan 10You should run a pool to predict when the team resets will start slowing down as people figure out who they prefer to work with and as you find out who The Best Team is. These things have a way of congealing unless mgmt is committed to keeping the switches up.
Aditya
on 08 Jan 10When you say 2 developers, does that mean one developer doing front-end (CSS/XHTML/JS) and one developer doing backend or does every one do everything?
JF
on 08 Jan 10@Aditya: Our designers do the HTML/CSS. JS is usually a split depending on who’s working on the project. To us “developer” means Rails coder and “designer” means visual look/feel + HTML/CSS. There’s overlap, but that’s basically how it goes.
Chris Cuilla
on 08 Jan 10EH raises a good point. What is your longer term philosophy regarding teams settling in vs. forcing change-ups? There are clearly pros and cons of both, but it seems when a team naturally “congeals” it is likely a good thing as the people become comfortable and work more effectively together. Like a band or a sports team.
JF
on 08 Jan 10We don’t worry about things that may or may not happen down the road. None of that matters today. If patterns reveal themselves one day, then we look at the patterns then. Anything else is just a waste of today’s time. Today’s time is the only real time so use it wisely.
Tony
on 08 Jan 10This sounds like another way of making features ‘earn’ their way into your applications.
If a feature keep dying every iteration, then it either doesn’t fit well into the app or you haven’t yet found the best way to do it.
As you say, its an experiment. It will be interesting to see how it works out.
MIchael Uschold
on 08 Jan 10Getting a chance to work with different people has its benefits. It is also true that when the right combination of people work together productivity can multiply dramatically. Changing all the time risks breaking up highly productive teams that love working together.
Michael
Richard Harrison
on 08 Jan 10With your 2-week iterations have you thought about QA?
We’ve been working short iterations (1-2 weeks) and have struggled a bit. We’re changing it up to do a 4-week cycle, 3 weeks coding + 1 week QA/release.
Colin
on 08 Jan 10I wish my designers did all of the HTML/CSS.
I find that when I design a site and I know I have to code it then I build it and organize the files so that it’s easier to put up. From my experience designers just organize the files and layers so it’s easy to design, not necessarily easy to code.
Tim
on 08 Jan 10re: “So much structure” and your following comment making fun of it. (a bit)
I guess my thought was that, compared to what I’ve been used to from 37signals, the laying out of the plan like this felt more structured than usual: teams = 3 people, iterations = 2 weeks, change of teams = after 2 months.
So, sure, not really “structured”, but I’d say “unusual” compared to many other things mentioned here where how things feel seem much more important than rules.
That being said, I think I’d enjoy that kind of setup. And I guess my comment was mostly based on the fact that the “rules” parts stuck more in my mind than what’s left free: like what projects to work on and how to do it, pitching new things…
Good luck!
Spencer Fry
on 08 Jan 10This is a neat idea. It’d be cool if you launched another page of the 37signals.com site that detailed the projects over the course of the year. It’d be cool to see the progress / what was being selected / what didn’t get completed / etc.
BJ Nemeth
on 08 Jan 10I think this is an interesting experiment, and I expect good things. I think small teams are the best way to go, because everyone is accountable, and everyone has a better idea of what is expected of them.
I look forward to reading about the results after a few terms. (And seeing the results in your products.)
Sean McCambridge
on 08 Jan 10Jason, what do you say about designer/developers, “dev-signers,” whatever you want to call it? Is there room for us? Also, do you think HTML/CSS should come before backend programming, or should the developers make an app work first and have the designer come back and clean up the HTML/CSS?
Glad to hear you split the JS. I get so frustrated when a developer tries to act like he’s the only one who can write code.
Appwerks.
on 08 Jan 10Sounds interesting. I assume some of this stems from and/or is addressed in “Rework” (I hope I got the title correctly).
It will be pretty interesting to see how this goes for you both in short term and over long(er) haul. Keep us posted.
Udi
on 08 Jan 10Good idea. Please write back if there any changes or new thoughts about it.
JF
on 08 Jan 10Sean: UI comes first. Designers build the UI first, programmers hook it up. This is our preferred way of working.
“Dev-signers” are great. Wish there were more of them out there. Would be wise for designers to get some developer chops, and vice-versa.
DHH
on 08 Jan 10Rob, there are no explicit coding guidelines, but we all share similar sensibilities and we use Ruby on Rails for everything, so there isn’t that much variability in style.
Victor, sorta, yeah. Currently we have our two key sweeper people (Craig and Sam) on a team each. They’re programmers with strong visual design skills.
Laura, we explicitly do not want one team owning one product. We’re small enough that everyone should be able to work on everything. In fact, we’re setting this up in part to break out of some of the silos that were developing.
Chris, this might well be a valid concern when you have 4, 5, 7, 10 teams. It doesn’t really matter when we’re 2-3 teams of only 3 people each. Our entire company is smaller than many teams at bigger companies.
Ryan Heath
on 08 Jan 10Sounds pretty cool. I often do a lot of development work (and design work, frankly) by myself, and it’s really limiting not having another person to bounce ideas off of. I know 37signals has always been able to bounce ideas off one another, but you definitely get the most benefit when doing this with someone who is also working on the feature. Talking to someone not involved won’t have the same understanding as the person who has been thinking about it for a week.
So I personally think this will work out pretty good.
As for the people claiming “structure”, it’s funny, because while 37signals has always been kind of “loose” with their methods, they’ve also always been very open to something that might work better. I’d say that’s all this is; trying something that might work better.
Good luck!
Brad
on 08 Jan 10I’m an idiot. Jan 08 is Jan 8th, not Jan 2008. I’m glad my idiocy could be of service earlier in this thread. If anybody has any further questions about how dates work, I’ll be happy to answer questions.
George
on 08 Jan 10Interesting. How did you come up with this system?
Guy at HockeyBias dot com
on 08 Jan 10Based on your current approach, I think this sounds very smart! All the best.
Brian
on 08 Jan 10Fascinating stuff.
Does the Backpack list of potential projects include any bugs or are all of those handled by the support team/developer? If a bug fix needs additional designer and developer help, but isn’t time critical, would it become part of an iteration?
JF
on 08 Jan 10Brian: The list mainly consists of new stuff or improvements to existing stuff. There are a couple things on there that are bug-like, but not really bugs—they are more like things we’d like to “fix” even though they aren’t technically broken.
BradM
on 08 Jan 10I was just thinking of the same idea this past week. However, I like your idea of ‘Teams’ much better. Especially how you will rotate members.
It reminds me of the Freshbooks ‘Release Planning’ cycle, where they push out a release or feature every 2 weeks.
Have you guys put any thought into the idea that Google uses to allow employees Flex time to work on ‘anything’ sort of, out of the box ideas?
Brian Doll
on 08 Jan 10This sounds like good progress from isolated teams-of-one and will likely do a lot for productivity. I’ll predict, however, that after a few “terms”, the false structure and durations of iterations and terms will need to dissipate into a more adhoc model.
I think a progression toward Kanban would be a better fit, and remove the management tasks that tend to follow with iteration planning and similar unnecessary tasks.
Chris Blood
on 08 Jan 10Would you be comfortable sharing how you came up with, decided on, and communicated this new approach? E.g. was it just one person saying “let’s try this,” or a collaborative evolution? Was it a suggestion that had come up naturally, or in response to a specific request for thoughts on how else you might tackle your projects?
maetl
on 08 Jan 10I thought this is how any design agency works – small 3-5 person teams on a particular project. I don’t know what’s so shocking or surprising, except that they are working on sub-projects on interconnected internal company apps, rather than completely separate client accounts.
People who insist on the dogma of “agile story cards” should pay particular attention to JF’s comment, regarding a “living list” being constantly massaged.
Rahul
on 09 Jan 10@maetl Who said anything was shocking or surprising? It’s just cool that they’re sharing their way of doing things. I know it’s valuable to me to hear that others are doing things similarly to how we do them.
George
on 09 Jan 10Based on past experience I see this only working for companies building their OWN software products, like 37Signals. For agencies or software companies working on fixed-fee project work this method fails.
When we worked at Refinery (now part of G2) they used this exact same idea but called it PODS. However during periods of high-utilization the slack-team / open-POD was busy helping out other PODs and inevitably staff was pulled out of POD A to help POD B. It became a real mess and was quickly abandoned.
Good luck to 37S in pulling this off, I have no doubt it will work for companies generating their own revenue via products.
Dave Giunta
on 09 Jan 10Wow, this is so totally the kind of environment I’d love to work in. I think it’s fantastic that you guys spend time thoughtfully considering how you work, and have the balls to make changes and try out new things. Why don’t more employers consider doing experiments like this, and commit to them for more than two weeks?
Also, would Deselopers be a better term than Devsigners. Devsigners sounds a little too much like a developer is signing something. Deselopers has the advantage of sounding completely nonsensical… which is good when you’re coming up with a new word to describe those of us that have both Design AND Ruby chops.
Thanks for sharing your plans with the rest of us!
Pete
on 09 Jan 10Interesting concept, I’m another one who’s interested to see how this works out
The strict two week deadline is especially interesting. I’m wondering if the teams will end up rushing their work to meet the deadline, making mistakes. Or are the tasks small enough for this not to be a problem?
I’ll also be interested to know how the teams will cope with tasks that are half complete and entered back into the “pot”. Of course, good developers write readable code that anyone else can understand, but it will be interesting to see what happens anyway
Michael Del Borrello
on 09 Jan 10I love how you guys share this information, big thanks!
I’m interested in your decision to not allow 2 teams to work on the same product. Have you found that more than 3 people working on a product at one time becomes a problem?
Scott Heiferman
on 09 Jan 10sounds fantastic. thanks for the “inspired by” props—looks like you made it your own in quite a fresh way… maybe we’ll be inspired back. sometimes constraints/structure makes for the most productive creativity. can’t wait to hear how it goes & how you evolve it
Sanat Gersappa
on 10 Jan 10Interesting. Thanks for sharing. Waiting to see how this works out.
Mark
on 10 Jan 10Wow. This is DIFFERENT 37signals. And in next few years you will end up with 20 teams, 10 project managers, reports, big time-consuming meetings etc.:)
Sam
on 10 Jan 10Do you have a plan for how to handle vacations/time off in your 2 week iterations? Maybe you’re just going to let that evolve naturally?
JF
on 10 Jan 10Sam: That’s why we have some slack. If someone’s out for a couple weeks, someone from the slack team can help fill in. Or the team can take on some smaller stuff.
Nekojoe
on 11 Jan 10It sounds like you’ve taken some ideas from agile . Terms sounds like sprints to me. The pot could be seen as the backlog.
I like the idea of rotating teams as it keeps everyone up-to-date with all the products you produce. Rather than have bottlenecks of knowledge where certain functionality is trapped in one developers head.
I’m curious to know who does the code review? Would it be the other developer in the same team? Or another developer in a different team?
ron
on 11 Jan 10OMG!! you discovered basic project management! when will the book come out!!???
T
on 11 Jan 10In a way, it makes me think of Scrum ( http://en.wikipedia.org/wiki/Scrum_(development) ). The project list being the product backlog, and the 2 weeks being the sprint.
Have you been also inspired by it?
Si
on 11 Jan 10You guys are so awsome. I can’t believe you keep coming up with all these great techniques. Better get writing a new book with these latest breakthroughs in project management in!
Ryan Angilly
on 11 Jan 10@Si: I wouldn’t exactly call “working in teams” a breakthrough technique in project management. Lets go a little easier on the Kool-Aid :-P
@JF: It takes some cojones to throw a wrench in your development process like this. Looking forward to hearing how the transition works out. Good luck.
Helgi Þór
on 12 Jan 10Exciting stuff!
Some questions that come to mind:
What will you learn – and share with the rest of us?
How will working in teams affect your products? (v. excited, would like more team focused view in Basecamp)
What is the analogy here? Cooking? Gardening? Hiking?
Speaking of dedicated teams vs. slack team reminds of rescue teams, where one team goes ahead (light-carrying) to reach the lost/injured people as fast a possible, with a second team following with the heavy equipment. Not sure that it fits here as an analogy, but you already have Basecamp and Backpack, so maybe somehow related to hiking?
Many thanks for sharing, looking forward to hearing more!
Helgi Þór
Ji
on 12 Jan 10I thought you guys had it all worked out. You know it all. Structure and rules are bad, and freedom to express if/when is where it’s at. Now the real world intervenes and you’re finding existing business structures are making more sense. Welcome to the real, proper business world. What you might call “Getting real”
Si
on 13 Jan 10Joel was going all corporate on us last year. Now you guys. Man I’m depressed.
Derrek Pearson
on 13 Jan 10Whether you call them devsigners or desolopers or simply designers who know where it’s at, strong web designers with HTML/CSS knowledge are hard to find gems. If you’re one of them and you’re looking for work get in touch with me. I’m not hiring today, but I probably will be before the year is over.
I like the new way of working 37s. I like how you pulled a few of the better concepts from Agile and integrated them into your existing way of working rather than trying to simply take Agile as is.
Anonymous Coward
on 14 Jan 1037 Signals Corporation
Anonymous Coward
on 14 Jan 10I’ve always kinda wondered that…......how can 37signals grow without becoming more “corporate” like….... well, I guess you can’t.
Anonymous Coward
on 14 Jan 10This might cause some unnecessary pressure on your employees…...I’m betting one of them will quit within 3 months.
Jamie Hillsman
on 14 Jan 10How do you divvy up roles and responsibilities since you are a small team? Or are you big enough to have 1 person assigned to one role/function (promotion, testing, bookkeeping, development, design, bugs, support, etc). How much, if ever, do people contribute to areas outside their normal design/development role?
J
on 14 Jan 10Surprised by the “corporate” comments here. 37s went “corporate” because they get stuff done in 2 weeks with small teams of 3? FUCK… I wish ALL corporations worked like that! Most places I’ve seen take two months and 30 people just to make a single fucking decision about what to do next.
Esteban
on 15 Jan 10Structure isn’t always a bad thing. Wonder how you’d feel about teams not being able to finish up a couple of iterations back to back. I’d feel like a waste of money. Also, and this is more in regard to the vision of your product, do you think that 37sig products are more of a team effort rather than how YOU think things should work? In my short experience, products need an extreamly focus vision and are the brain child of it’s owner rather than everybody else in the team. Not saying the last option is a bad thing just wondering how you guys work and perhaps challeging you a bit on this matter.
This discussion is closed.