This week, I was fortunate enough to hear Jason Fried, founder of 37signals, talk from “behind the curtain” about his work philosophies at the Philadelphia UIE Web App Masters Tour.
The talented folks at the Chicago-based web application firm run a tight ship. They work in teams of three to five, depending on the nature of the project (two developers and one designer for standard projects; one extra each for “stack” projects). They work in iterations, with each lasting about two months; at the end of each iteration, the work is either finished, or it isn’t. The teams are reassigned after each iteration so everyone gets to know everyone else’s skillsets (avoiding the “hit by a bus” scenario). Many times, the teams get to choose how and on what they’d like to work. There’s no paper prototyping, sketching (beyond broad, simple strokes with Sharpies), or Photoshop mock-ups; they dive right into interactive wireframes using HTML. There’s no user testing before a new build is launched. 37signals accepts feature requests, but they typically scrap them; most times, it’s only when a specific request or complaint keeps popping up that it gets attention. Overall, it’s an amazing and eye-opening process, particularly for those of us working in larger organizations, where such a culture would be challenging, if not impossible, to institute.
But the true take-away for me that day was this: I had more in common with 37signals than I realized.
For seven years, I worked for a medical publishing firm. I was part of a four-person web team: a director, two database developers, and me: a web designer and front-end coder. We worked on online versions of medical journals and image databases. Our process was generally effective but very informal: no product documentation, no project management, no user testing, no multi-year projects, and maybe two to three formal meetings a year. We knew what was expected, came up with our own solutions, and make fixes and improvements organically. Since there was only four of us, we developed overlapping skillsets so there would be coverage for vacations, sick days, etc.
I never really gave the work philosophy at my old job much thought, but this week it hit me: I’ve had a similar experience to the 37signals model.
I’ve been here before. This was an interesting revelation.
The organization where I work now has a much larger workforce and stronger hierarchy than 37signals. Meetings and project management are part of daily life. Much of what Jason preaches resonates deeply with my colleagues, who can feel burdened by day-long kickoff meetings, rounds of conference calls, and chains of e-mails. They see an austere, agile, and geographically-agnostic workplace, with its stream of consciousness projects and “meetings suck” mentality, as Nirvana.
OK, so I had a variation of their experience at my old job, but I’ve since moved on. What about now? Is the 37signals philosophy scalable in large organizations like mine?
Yes and no.
Sure, meetings can and do suck, but in order to get things moved along at my office, it’s often a necessary evil. You have budgets that span several years and strict accounting rules to follow. You have to be wary of risks to security, reputation, and authenticity. You have to play well with multiple teams from varied disciplines and management structures. It’s not that these things don’t exist in some form or flavor in the 37signals plane of existence, but they’re magnified significantly when the people, roles, and responsibilities carry the weight borne by large businesses. My organization can’t run on 2-month iterations or release new features and services without user testing; there’s too much at stake.
The key word here is the “organization”. The business model we follow is too massive for the 37signals way of life, but not the individual teams within it. That’s where the fast-and-loose lifestyle of the agile development firm can take root. I’ll take one example from Jason’s presentation to show how some of their attributes could be applied effectively and painlessly.
During the 37signals session, one trait quickly became clear to me: there was no e-mail between his teams. None. The folks who work on iterations don’t use it during development. Instead, they use an in-house product called Campfire that allows for efficient and swift teamwork. It’s a threaded, collaborative interface, where comments and features for a unique project are posted in a chronology. Team members can upload images and give feedback; everything exists in a proper order and context. There’s no “hey, did you get my e-mail?” nonsense chatter, crossed wires from team members sending messages over one another, or overflowing inboxes (which people don’t often keep well organized anyway). It lets the 37signals team get changes done on-the-fly, in real time, and with great speed. If individual teams in my company were to adopt Campfire or something similar, it could save countless hours of time spent wondering where everyone was in the development, review, and release of our projects. It would help my boss stay on top of our projects and simplify approvals. It’s less burdensome and not as obnoxious as typical help desk ticket systems. And, since every post is captured and recorded, there’s an automatic paper trail created as you work (which should satisfy the auditors).
Think about it. Wouldn’t that make your day so much easier?
We can’t all be like Jason Fried or 37signals. Obviously, not everyone or every organization can or should work the same way. However, there are a gold mine of innovative and efficient practices in their philosophies that, taken in smaller chunks, can translate into your universe. Replacing e-mail with a system like Campfire, for example, could be an easy victory, and one that I hope to discuss with my peers.
Do you work at a mid-size or large company? What could you take from 37signals that would work for you, or have you already done so? I’d love to hear your thoughts, findings, and stories.
