Getting Real: Less Mass - Signal vs. Noise (by 37signals)

Getting Real: Less Mass 24 Mar 2005

37 comments Latest by Mike Mindel

My first two posts on our Getting Real process talked about no functional specs and just say no to lorem ipsum dolor. This post introduces the concept of “less mass” — a method to make change easier and cheaper. BTW: Some of this was covered in my SxSW 2005 presentation and at eTech 2005.

If you want to build something great, there are a couple of things you have to know going in:

You’re not going to get it right the first time
Change must be easy and cheap

Change must be easy is really the most important point. If you can’t change, you’ll lose. Change needs to be your business. And the best way to make sure you can change when you need to change is to reduce your mass.

A quick look at physics makes this obvious. The more massive a moving object the more energy it takes to change its direction. What applies to the physical world also applies to the business world. Less mass makes change easier.

What do I mean by “mass” in a business sense? In the business world, mass is increased by things like:

Long term contracts
Excess staff
Permanent decisions
Sign-offs and signatures
Thick process
Big teams
Inventory (physical or mental)
Hardware, software, technology lock-ins
Proprietary data formats
Formalized press releases
Excessive hubris
Too much middle/muddle
The past ruling the future
Long-term roadmaps
Excessive paperwork
Office politics
Playing catch up
Me-too mentality

Mass is reduced by limiting the above and embracing things like:

Just-in-time thinking
Multi-tasking team members
Embracing constraints, not trying to lift them
Less software, less code
Open-source products
Open data formats
Humility
Admitting mistakes early
Having customers evangelize your product
Enjoying what you are doing
Passion for your product
Using what you’re building

For example, let’s look at a lean, less-mass widget manufacturer using the Just-in-time methodology, and a fat, more-mass widget manufacturer with three months of parts inventory. The Just-in-time factory only has 1-day worth of parts inventory on hand. They get a new shipment of parts every morning. If their suppliers invent a better part, they can get that better part into their widget tomorrow — they can begin building a better product tomorrow. The more-mass company, however, with three months of parts inventory, needs to work through all that supply before they can even consider getting the new part in their widget. Sure, they may have saved a few bucks by stockpiling inventory for tomorrow, but they’ve squandered the opportunity to build a better product today (and for the next 90 todays). They can’t improve today because of a decision they made 3 months ago. They’re letting the past rule their future.

Let’s choose an example a little closer to home: building web-based applications. Let’s look at a lean, less-mass company that built a product with less software and less features, and a more-mass company that built a product with more software and more features (by a power of 3, let’s say). Then let’s say a new technology such as “Ajax” or a new concept such as “tagging” comes around. Who is going to be able to adapt their product quicker? The team with more software and more features and a 12-month roadmap or the team with less software and less features and a more organic “let’s focus on what we need to focus on when we need to focus on it” process? 12 months out the less-mass company will have made better decisions and adjusted to the real demands of the marketplace better while the more-mass company will likely still be discussing changes or pushing them through their bureaucratic process.

Bottom line: Nimble, agile, “less-mass” businesses can quickly change their entire business model, their product, their feature set, their marketing message. They can change their priorities, their product mix, their focus. And, most importantly, they can change their minds.

37 comments so far (Jump to latest)

Brady Joslin 24 Mar 05

Interesting analysis - I completely agree.

This is very similar to the ideas produced by http://www.lean.org/

Lean manufacturing principles should certainly be translated into improving the manner in which services are delivered.

Further, the importance of effective designs certainly play a role in the idea of lean consumption. The more effectively a user can use your product throughout its lifecycle the lower the cost of the item or service will be in real terms.

Allan White 24 Mar 05

I’m curious to hear what would substitute for signatures in an approval process. I’m sure I’m not the only one that hates trying to get a client to sign off on a design document or other deliverable. But how else do we hold them accountable when changes occur? How do they hold us accountable for actually executing on the project?

In my personal life, I try to “let my yes be yes, and my no be no” - I try to fulfill my committments. But in the business world, I find that a handshake is insufficient to seal an agreement.

Is there something better?

JF 24 Mar 05

Allan, I concur that signatures and sign-offs are required at times. However, they also lead to permanent decisions. And permanent decisions are barriers to change. So let’s just keep that in mind when we sign on the dotted line. If you must sign, then sign, but if you don’t have to, don’t.

Also, if you are in charge of creating process, look for places in your process where you can remove sign-off. Sign-off may be important in some places, but excessive granular sign-off can be a dangerous thing.

One of several Steves 24 Mar 05

Nothing really surprising - or new - here. It’s good thinking and advice on most points, which is why many industries have been adopting a lot of the bullets you list (it’s a challenge to find anyone in the auto industry, for instance, who hasn’t gone to just-in-time inventory, and that system is a huge factor behind Dell’s ability to get good margins out of a commodity product).

But as with anything, there are two sides. To carry the physics metaphor a bit further, if you don’t have enough mass, it’s too easy to be blown away or for someone to come along and push you out of the way.

Take your very first bullet point: On the account I work for, we have a long-term retainer agreement with our client. This gives us more flexibility, not less, because we don’t have to spend so much time sitting around waiting for the new work order to be signed. We can get moving, laying down the groundwork, working on requirements and specs, allowing us to respond to both our client needs and our internal needs to do a good job much more quickly than we did back in the days when everything was a short-term contract for each distinct project.

The dangers of lean mass can be apparent in other ways. Multitasking is all well and good, but numerous studies have shown that in most cases, multitasking does not mean doing several things well in less time, it means doing several things less well in the same amount of time. I’m by no means advocating the ridiculous compartmentalization I’ve seen in large organizations where people do not step outside their precise job description, and three people do a job that one could easily do, but at the same time you can’t assume that everyone is going to be able to do everything. You need to provide people with core responsibilities that play to what they’re good at, and make it clear that their first job is to take care of that. Spreading them around may work in the short term, but it’s ultimately going to harm the person and the organization if it’s kept up too long.

What I’m really getting at is that, while I certainly agree with the subtsance of the concept here and the vast majority of the details, I see a risk in focusing too much on the short term. The object of a business is not to get the current project done, or to meet the current quarter’s numbers. It is to provide sustained, long-term viability and growth that comes from continually responding to customers’ needs and getting better at doing so. U.S. business is often too concerned with the immediate goal without keeping in perspective of the consequences to the long term (let’s slash staff now to meet our numbers, never mind that next quarter we’re not going to have enough people to get done the things we need to get done). I typically hate slippery slope arguments, because any and everything can be taken to absurd extremes, but this is one case where the drive to be lean can easily lead to getting too lean so that you indeed harm yourself beyond the immediate term.

To create a tortured metaphor: You have to be carefull that in the quest to establish a lean business, you don’t end up becoming an anorexic one.

Steve, it all depends on what kind of company you want to be.

Re: signatures: thanks for clarifying, Jason - as in all things, balance and common sense should rule. I agree that overly granular signatures and contract inflexibility can slow an agile team down.

Blake Scarbrough 24 Mar 05

What are you thoughts on timeline’s with clients? Do you set timelines and due dates without showing a client a document spec? That seems to be one area of mass that clients need. Is it better to tell a client the project will be launched in about 6 months or it will be launched on this specific date?

Fred, the real Fred 24 Mar 05

� You have to be careful that in the quest to establish a lean business, you don�t end up becoming an anorexic one.

Totally agree. Completely. 100%.

Before everyone starts drinking the Less-Is-More Cool-Aid let’s look at reality

I feel that most web apps today are developed for specific niche markets and are not for mass consumption. The company I work for has successfully taken on some huge and complex web applications; Huge $$$, big teams (20-30 developers), numerous technical writers and a long development cycle (18-36 mos.). Our client is a Fortune 50 company and I bet our budget could buy 2 or 3 Flickr.com�s. The final result was better then the client expected. The apps I�ve been involved in developing solve very complex problems in the simplest methodology possible. The design doc comes down to �Solve this� and there is no Less-Is-More.

Yeah it would be nice is everything could be handled by small teams and be reduce 6 lines of Ruby code, but many logistic problems require bigger, more complex solutions. And it also means bigger paychecks for the development team.

We in the developer community get overly absorbed in ourselves when in reality software helps people/businesses run more efficiently. We are a small cog in a big system.

I think this quote is fairly analogous to the discussion at hand.

“Vigorous writing is concise. A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts. This requires not that the writer make all sentences short or avoid all detail and treat subjects only in outline, but that every word tell.”

— The Elements of Style by William Strunk Jr. 1959.

In this context “less” does not coincide with an inability to tackle complex problems, rather the term addresses the need for efficacy.

The company I work for has successfully taken on some huge and complex web applications; Huge $$$, big teams (20-30 developers), numerous technical writers and a long development cycle (18-36 mos.). Our client is a Fortune 50 company and I bet our budget could buy 2 or 3 Flickr.com�s. The final result was better then the client expected. The apps I�ve been involved in developing solve very complex problems in the simplest methodology possible. The design doc comes down to �Solve this� and there is no Less-Is-More.

I have no doubt that someone could have tried to build Basecamp with “Huge $$$, big teams (20-30 developers), numerous technical writers and a long development cycle (18-36 mos.).” In fact, many people have tried and have brought bloated, slow, changeless applications to market.

We chose another path. Simplicity is always a choice. The assumption that software for the high and mighty Fortune 50 needs to be complex and require an army of developers to build and support it is a dangerous (and costly) assumption.

Simplicity is always a choice

This is exactly my point. Simplicity is not ALWAYS a choice. The high and mighty Fortune 50 needed an application that the end user’s life depends on. To account and code for all possible outcomes and variances without people dying during QA required an army of developers.

I’m not trying to get into a pissing match. 37Signals does some great things with a small team, but my point is that there are problems demanding solutions and those solutions are not simple and never will become simple.

The first video game I play was Pong and now we have Half-Life. Is �Less-is-More� applicable? How about avionics - �Less-is-More?� Missile guidance systems?

The list is endless. 37Signals is an excellent example of an successful small team, however my point again is that not all software can be simple.

37Signals is an excellent example of an successful small team, however my point again is that not all software can be simple.

I’m not saying that everything should be simple and you aren’t saying that everything should be complex. So please drop the “all” argument you introduced.

What I’m saying is strive for simplicity, strive for less mass. You’ll be surprised how simple things can be, and how much of a benefit “less” is if you respect simplicity. Simple HELPS the complex.

There are plenty of things that are complex because we’ve made them complex — not because they are inherently complex.

Simple HELPS the complex

You are correct, all solutions can be simplified. My background is in mathematics and I hae painfully learned that yes, we do make things far more complex then need be. This is why I use Basecamp.

Jason, more then anything, I just like challenging you on your theories as you challenge mine. If we’re correct we’ll be passing each other some day in DB9s.

sloan 24 Mar 05

Large or small, there are opportunities for both. In some cases larger scale is more profitable, especially in manufacturing. If you are focused on process and problem solving, there is a reason the best “firms” are also small. How big is IDEO, Frog Design? Not very big at all. The problem you will face though when working with a Fortune 500 company is that they are only familiar with what works for them. Convincing someone that their process and approach will not work for everything is a tough battle and one that you really don’t want to fight.

Why fight? Not to be condescending, but when dealing with people and their set ways, it is best to recognize that they are set in a particular pattern and to work with it instead of against it and slowly teach them the better way. Taking the attitude of a partnership working together to solve a problem goes a lot farther than trying to convince your client that their methodology is wrong. Come to the table with a way of communicating how your methodology “covers all the bases” and work within their process, forms and procedures. It is not necessarily that their way is wrong, period, but simply not well suited for the given task.

There always needs to be a balance when “designing” though between process and “free thinking”. Our brains do run off in many directions and come up with some amazing ideas, but it is also a problem because we can often miss little things that are detrimental. Process, checklists, sign-offs, check-points are all tools for acheiving a goal. It is important to make sure that these do not become goals though, instead of just tools. But without the tools to help guide you, you are hit and miss or just plain lucky.

When we were contracted by the high and mighty Fortune 50

When we were contracted by the high and mighty Fortune 50 it was entirely up to us how staffed our team. We were given requirements and a timeline; in return we submitted a bid. There was absolutely no influence by the client to the number of developers we used. We were contracted to develop an app, how we developed it was up to us.

James Archer 24 Mar 05

So when are you guys coming out with the inevitable business book about all this? (If you need a writer to help out, let me know!)

Mike 24 Mar 05

“Everything should be made as simple as possible — but no simpler… .” — Albert Einstein

pb 24 Mar 05

Our client is a Fortune 50 company and I bet our budget could buy 2 or 3 Flickr.com�s.

And this is why big companies get blind-sided by upstarts.

nathan 24 Mar 05

I bet most Fortune 50 companies could fire half their white collar workers at random and be twice as productive.

That’s why we were hired. Their internal developers could get the job done.

cboone 24 Mar 05

Just for the record, Pong is way better than Half-Life.

Simpler is better, even in video games…

OK, bad example….

AC 24 Mar 05

� Long term contracts � tell this to a start-up that gets it first long term contract
� Excess staff � sure, that�s easy
� Permanent decisions � as apposed to wishy washy decision making, but I understand?
� Sign-offs and signatures � protecting yourself from legal issues?
� Thick process � buzz word
� Big teams � no poorly managed teams, Fred has a point some apps require bigger teams
� Inventory (physical or mental) � I bet the airlines wish they had locked in more long-term fuel contracts
� Hardware, software, technology lock-ins � Like Apple�s closed hardware?
� Proprietary data formats � sure, I�ll buy that
� Formalized press releases - agreed
� Excessive hubris � agreed, but does that include big ego blogs?
� Too much middle/muddle � middle management or middle-ware?
� The past ruling the future - agreed
� Long-term roadmaps � you better have one or you�re a fool or you�ll be writing a shit-load of code
� Excessive paperwork - agreed
� Office politics - agreed
� Playing catch up � it can happen to anyone. How you recover counts
� Me-too mentality - agreed
� Just-in-time thinking � sure, but within you company�s scope
� Multi-tasking team members � what new
� Embracing constraints, not trying to lift them � do both
� Less software, less code � how about just enough code to solve the problem. Sound like someone failed their CS 101 class.
� Open-source products � never seen a code snippet on SvN. People have asked for yellow fade, but no luck. Basecamp open-source? I bet not.
� Open data formats � in some situations
� Humility - sure
� Admitting mistakes early � a balancing act at best.
� Having customers evangelize your product - cheap marketing
� Enjoying what you are doing � if you don�t what�s the point
� Passion for your product � if you don�t what�s the point
� Using what you�re building � if you don�t what�s the point

Michal Migurski 25 Mar 05

Are you guys ever going to get into specifics?

“One of several Steves” has already hit some major points, to which I’ll add that 37S do a great job of sloganeering about this stuff, but a not-so-great (less “massy”?) job of explaining what you mean through examples. It’s one thing to say “don’t do X (except when you have to)”, and quite another to evaluate the cutoff point. The former is easy, not least because you can often say the opposite and *still* be right. The latter is hard, because it requires domain knowledge, experience, and good sense of design smell. To put it in William Strunk terms, good writing is rare because knowing what to omit is *difficult*.

Not any the Steves 25 Mar 05

In general, I agree that the agility which comes with a small workgroup is useful. An initial reaction, however, is that I prefer my company being small and my vendors being large. That is, in our company, we have a small central workgroup that then contracts out volume pieces of work to people around the globe. (We localize software and documentation.) When I have two or three projects that are approved simultaneously, it is often with little notice. I want the reassurance that my vendors are big enough to handle the larger, instantaneous volume. Hunting for new resources should not be part of every project.

Here’s another example: Apple is a small and agile company in the regard that they can make isolated design decisions without being held accountable to their user base. Prime example is the display with ADC. I’ve got one and it’s usefulness expired prematurely because my neither my PowerBook nor my Mini have an ADC port. I’m at the losing end of an agile decision. So, what’s to stop 37Signals from changing their strategy? What if they don’t want to be in the software business next year? Feel free to convince me that you’ll always do software, but it doesn’t change the fact that only 2 people have to change their minds to improve or eradicate the business plan altogether.

The point is, it’s a matter of perspective. 37Signals has the luxury of saying, ‘be small and agile,” because it suits them well. However, with the number of exceptions we can draw to this rule, perhaps that advice has so many qualifications that its effectiveness ends at 37’s doorstep.

Michael Ritchie 25 Mar 05

Nathan: “I bet most Fortune 50 companies could fire half their white collar workers at random and be twice as productive.”

Yes, but not a random.

Janos Erdelyi 25 Mar 05

Sounds like business management OOP. not that i’m complaining.

Anonymous Coward 26 Mar 05

The reliance on specifications documents imposes a “wall” between users and developers.

— Interactive Systems: Bridging the Gaps Between Developers and Users (1991)

Andrew 17 Apr 05

Those who are looking for more specifics along these lines might want to check out John Thackara’s great new book “In the Bubble”. He dedicates a chapter (and has in the past an entire design conference) to “Lightness” which in many ways is what Jason’s talking about here.

Frank Johnson 21 Sep 05

Good service

Mike Mindel 11 Feb 06

These ideas are beautifully illustrated in The Goal: A Process of Ongoing Improvement by Eliyahu M. Goldratt, Jeff Cox. A fantastic read.