Confidence in people, process, and purpose - Signal vs. Noise (by 37signals)

Confidence in people, process, and purpose Matt 18 Sep 2006

40 comments Latest by mj

Confidence is key. Without confidence, it’s tough to build anything that’s strong. If you go in weak, what comes out is weak.

Some companies try to manufacture confidence. They use specs, documents, and process as things to lean on. These crutches give them a false confidence that nothing will go terribly wrong.

The problem is when you build confidence with documents and all that, you are nailing yourself down to assumptions that are probably wrong (assumptions always seem to fall by the wayside once things get real). Yeah, you may feel better that you have a recipe written down. But if it’s a recipe for failure, what’s the point?

Still, some people don’t get it when we argue “don’t worry about all these specs and documents” and instead “dive in and build stuff.” Maybe they’re confused because there’s something implied, but not usually overtly stated, in these ideas: confidence.

You have to start with confidence in your own people. We believe in the ability of our team members. We believe they are smart. We believe they can get it done without handholding. We believe they will design effective UIs, write efficient code, author clear copy, and communicate well with each other.

Confidence in the process itself is also important. You have to believe that the way you work produces results. For us, that means believing in Getting Real. We believe in the process of doing the interface first, iterating often, revising based on feedback, etc. because it works.

You also have to have confidence in the purpose of the product. You need to know that what you’re building is actually useful. When something is truly useful, it gives you wiggle room. A product that is fulfilling a real need doesn’t have to be perfect right out of the gate. Even if every corner isn’t perfectly rounded or every surface polished, it will still make life better because it, in some way, solves a tractable and relevant problem.

If you trust the people, the process, and the goal, you don’t need all the bullshit trust-builders like specs, documents, and promises to make you feel secure. You can just make something good.

40 comments so far (Jump to latest)

Mike Wadhera 18 Sep 06

Well said Matt. Confidence within small teams is key to success these days.

James Bielefeldt 18 Sep 06

I hear you Matt. And I understand the whole 37 Signals philosophy. I’ve been a follower for several years, but what about the Cover Your Ass, credibility and professional factors that clients welcome and are happy to pay for. What about comfort? What about risk?

Prudent planning and documentation help with all these things. I agree, often there is far more time spent in documentation than is really needed, but you’re billing the client for that time and THEY WANT IT. It also helps with process improvement for the next time.

The Seat-of-your-pants (agile) methodology 37 signals preaches is great, but is it practical when working with most clients on most projects? No. And I’d say most web developers (hacks and script monkeys) need more disapline that planning and documenting requires.

Confidence, blind faith, or arrogance, whatever you call it may be the quickest way to build an app, but it’s not the best way to do business.

ML 18 Sep 06

what about the Cover Your Ass, credibility and professional factors that clients welcome and are happy to pay for.

James, I know where you’re coming from. But that POV sounds a lot like “We know there’s a better way to do this…but clients expect it to be done this way so we give them what they want.” That’s depressing. You shouldn’t be afraid to say “no” to a client. A smart client wants to hear pushback. They’re paying for your expertise after all.

It might require some educating on your part. You might have to explain: Here’s how we’d like to do it. It’s different than you might be used to. But it’s really effective. Here are some other people who are doing it. You’ll see something real right away instead of having to wait months. Show them Getting Real. Etc.

The Seat-of-your-pants (agile) methodology 37 signals preaches is great, but is it practical when working with most clients on most projects? No. And I�d say most web developers (hacks and script monkeys) need more disapline that planning and documenting requires.

This view seems to be saying that most clients are idiots and most developers are lazy schmucks. Again, that seems like a pretty dismal outlook. Of course that assessment may be true some times. But you’ll never raise the bar if you assume everyone’s a lazy moron and treat them that way.

Showing confidence and expecting the best out of people can yield surprising results. I know it sounds like vague pep talk stuff but it’s still a lot better than assuming everyone’s an idiot and churning out mediocre work because it’s “the best way to do business.”

Joe Van Dyk 18 Sep 06

Most people are dumb though. It would be great to work at a place where everyone’s a super genius, but that can’t always be the case.

Brad Fults 18 Sep 06

These are fine points for the small team and I’m glad that someone has put true agile development to good use, but it doesn’t hold for the general case.

True agile development as you’ve described only works when your products/tasks are sufficiently small, your wiggle room is sufficiently large, and your developers are sufficiently inspired; none of which are commonly found in corporate environments. Maybe the deduction from this observation should be that corporations simply aren’t the best machinery for the output of quality products, but that’s a different argument for a different day.

Confidence is critical to the success of all-star developers and small teams of all-star developers because they can wholly own the processes and the products. Still, it requires a gifted developer to run with an idea and implement an extensible, helpful, and working product. No amount of confidence will give the hack developer the skills necessary to undertake such a task.

Also, it’s “tractable,” not “tractible.”

True agile development as you�ve described only works when your products/tasks are sufficiently small, your wiggle room is sufficiently large, and your developers are sufficiently inspired; none of which are commonly found in corporate environments.

If products/tasks are too big, shrink them down. When you work in iterations, you automatically get more wiggle room because you show something real sooner rather than later. And maybe these developers are uninspired because they’re forced to stick to fossilized documents instead of being allowed to innovate and evolve.

Maybe the deduction from this observation should be that corporations simply aren�t the best machinery for the output of quality products.

Well, that seems like a call to arms for corporations to change the way they work. More of the same doesn’t sound like much of a solution.

Chuck 18 Sep 06

While I agree that confidence is key, far too often the case seems to be overconfidence on the part of developers. Likewise, the lack of specifications/requirements/design are fatal for large systems. The CONFIRM project had (at best) very loose specs (which unfortunately continues to be the norm for the industry) and just had the developers jump in and start coding. The result was a 9-figure failed project that nearly got everyone fired.

While I agree that waiting for perfect requirements / design ensures that nothing gets delivered, jumping in to coding with little or no requirements / design (caveat: the prototyping development model uses this approach when requirements cannot be clearly defined and looks a great deal like agile approaches) is equally devastating.

I concur with an earlier poster that Agile methodologies work well with small teams and can be applied to large projects so long as the work can be broken down to a sufficient level of granularity for agile techniques to be applied. However, simply advocating Agile uber alles is, at best, irresponsible. The fatal fallacy of no requirements is that there is no measure of quality, i.e., has the system met all of the expectations of the customer or have those expectations merely been managed out of existence.

Andy Kant 18 Sep 06

I agree with Brad, this is unrealistic in corporate environments. Its not necessarily that the products are too big, but rather the amount of people involved. Documentation is about saving time, thereby saving money. It costs some time up front but saves much more time in the long run because no one will have to rediscover how something works by reading all of the source or receive the production version of an app only to see that an important piece of functionality they require is missing.

Lack of proper documentation assumes that you have a stateless team where nothing changes. No one comes, no one leaves, no one forgets.

Eric Tapley 18 Sep 06

Implicit in some of the earlier comments is the value specs and documents offer in terms of communication. Most significantly communication among team members and with clients, who may not share the vision you do - or may not be able to. After all, their business is usually something other than ours, which is why they come for our expertise. We need to clearly describe to them what is being done, why, and how they will benefit.

There is value in confidence, no doubt. But it helps to get everyone on the same page and inspire that confidence if you have a map to show where you’re going and how to get there, especially when that means you’re all headed in the same direction and people aren’t caught up in sidetracks or missed directions.

Specs, documents, and process aren’t inherently evil. They can be misused (and are often overused) but they are valid tools and, when used properly, can be very effective.

In the trenches 18 Sep 06

Corporations aren’t the best machinery for creating quality. They’re all about predictability and interchangeability: the idea behind the whole specification process is that once you have the specification, any team of code monkeys can create the software. The upper-level managers and directors set the agenda and goals, and the lower-level workers make it happen as directed. In large enough organizations (or organizations that aspire to that culture), lower-level workers who show initiative and take responsibility are often punished politically.

So new developers start out being innovative and enthusiastic and confident, and corporate culture beats it out of them. (Us?) After a while, the only confidence remaining is of the “nobody ever got fired for following the spec that the vice president approved” sort; then those developers get promoted, and the cycle begins over again.

Jim Jones 18 Sep 06

Well said. It’s almost as if confidence is a function of direction and motion instead of current position. It’s the energy behind the product that brings the attention.

Jim RunFatBoy.net

Mark Gallagher 18 Sep 06

I think a lot of what Matt says is relevant to big projects at big companies.

The typical process of developing new web apps at big companies is crazy. The elaborate “requirements gathering” process forced on the business people, long drafts of functional and technical specs, reviews by architecture committees, and all this needs to be 100% complete (for the entire app) before a developer starts to write a line code. This makes no fricken sense.

This document-heavy process does not save time or money in the short term or the long term.

Even in a big company, you can start with the UI, build prototypes quickly, kick the tires on live prototypes with customers, build part of the app first, innovate, get things out the door.

It is possible (not easy) in a big company. You need management that gets it - process is bad, getting it done is good.

Specs, documents, and process aren�t inherently evil. They can be misused (and are often overused) but they are valid tools and, when used properly, can be very effective.

Fair enough Eric. The usual caveats apply here: If what you’re doing is working out well, then perhaps you don’t need to change…Mileage may vary but this is what works for us…etc.

Amen Mark.

Josh 18 Sep 06

Yes, some companies use process as crutches, but many companies use process as the only viable method for getting their goals accomplished.

There is merit to getting a large compnay to compy with CMMI (or, ISO 9000).

In fact, for some comanies (and a large number of them) confidence is counterproductive. There are businesses that are built entirely around pessimism. NASA (and equivalents elsewhere). Insurance companies. Police. Stunt people. Airlines.

I guess my point is, most things that you guys mention in your blog here have duality to them. Confidence sometimes works, sometimes doesnt. Simplicity sometimes works, sometimes doesnt. Small sometimes works and sometimes doesnt.

You (the 37s) probably dont mean it, in fact Jason once specifically stated that you dont, but it usually comes across as though you mean that methods that you suggest always work for every purpose every time. And thats just not the case.

it usually comes across as though you mean that methods that you suggest always work for every purpose every time.

We just get tired of issuing caveats all the time. From page 10 of Getting Real:

—-
“If our tone seems too know-it-allish, bear with us. We think it�s better to present ideas in bold strokes then to be wishy-washy about it. If that comes off as cocky or arrogant, so be it. We�d rather be provocative than water everything down with ‘it depends…’ Of course there will be times when these rules need to be stretched or broken. And some of these tactics may not apply to your situation. Use your judgement and imagination.”
—-

Joe Sheehan 18 Sep 06

I agree with Andy, and need to stress the importance of documentation for dynamic teams.

In a corporation, often the best developers/workers (this isn’t software specific by any means) move around to the most projects, as the corporation tries to maximize (exploit?) their talents. But as long as the worker is happy with that, there’s no problem. But that requires that documentation that the worker did be kept on that project. And then if you’re on that project, you sometimes look at that work thinking “what was that guy thinking when he did it this way?”. This isn’t the case in small companies b/c there is so much interconnection. 37S employs a more pure product development model, but one which doesn’t scale well.

I love these writings - as they give us in corporate america something to learn from as we try to stay lean and simple. However, I can’t help but think that alot of the Getting Real ideas will be seriously tested the day that 37Signals either loses a team member or stops growing as a company. I hope that day doesn’t come for a while, but thats when Getting Real becomes Way Too Real.

elv 18 Sep 06

Andy Kant : “It costs some time up front but saves much more time in the long run because no one will have to rediscover how something works by reading all of the source
No, specs cost all the way till the project is done. In the real world there are bugs, changes, and specs have to document them. The bigger they are, the more difficult it is to be up to date and take all the changes into account.
I remember some 200 or more pages specs when I worked at a big web agency, there was a new version every 2 or 3 days. The only guy who really got the big picture was the one who wrote them :) Everyone else was lost.

Gary R Boodhoo 18 Sep 06

All too often I run into the term “scales well”, and what’s really meant is that individual accountability == 0.

Joshua Blount 18 Sep 06

I completely agree with the “confidence is key” mentality.

In another life I trained Customer Service for a large wireless provider. While the trainer period really wasn’t long enough and the tools provided were less than sufficient, I told every single employee that if they instilled confidence in the customer in the agents ability to resolve their issue, every single call or customer facing interaction would be succesful.

Sometimes believing in your team means letting the fake it untill they make it.

David Maister 18 Sep 06

Confidence, like trust, can come in many flavors. I can be confident in your abilities, but not confident about your motives (i.e. that you will put looking after me ahead of doing what you like to do.)

The good news is that not only do we as providers want confidence placed in us, but the users actually do want to be able to palce their conficence in us - it’s a pain to have to micromanage everything and everyone.

However, confidence (and trust) must be earned - they can’t be “claimed” as a matter of right. The question is: do you know how to get someone to trust you? Or perhaps a better question: do you know how to be trustworthy?

Ryan 19 Sep 06

“Documents? We don’t need no stinking documents!”

David James Nicol 19 Sep 06

Confidence is key.

I agree. Confidence is hugely important.

Personally, doing documentation at the start of a project gives me confidence. Confidence that I know what the project is all about; confidence that I have thought about what we are going to do any why; confidence that I have a proper starting point; confidence that I can communicate all this knowledge swiftly and effectively to the people who will be working with me; confidence that this stuff is written down and I don’t have to keep on thinking about it.

You have to start with confidence in your own people. We believe in the ability of our team members. We believe they are smart. We believe they can get it done without handholding.

Luckily, I do have confidence in my team, and I believe in their ability.

If there is something in the documentation that my team don’t agree with, or that they think they can improve on, I trust them to over-ride the documentation. If it makes the end result better, I’m happy for them to do whatever they think is best.

I do entirely agree that it is wasteful and counter-productuve to do too much documentation, and it is entirely pointless to spend time creating the wrong documentation. Slavishly following documentation is not sensible either.

However, for me and my team, documentation provides a solid starting point and we build from there.

Daniel 19 Sep 06

Didn’t 37 Signals shift from a webdesign company to a software company? You guys are making bold statements about how to manage processes with clients when you have quit working for clients. You develop products internally for yourself and then market them. Yes you have a budget and set deadline, but no contracts and client expectations, which is quite different.

Isn’t it too easy for you guys to make statements when you yourself are not in the field day by day?

Btw, I love Getting Real, and we are having mixed success in introducing it in big companies because of the “Cover your ass”
mentality that is so pervasive. And yes you can try to persuade the project leader, but in the end the company culture is the product of the people in charge, the CEO’s and other CxO’s. They monitor their managers below them based on documents, who then need documents from the people working for them etc.

One major influence I believe is supporting the “Cover Your Ass” mentatility are the SOX (Sarbanes Oxley) regulations. Everything needs to be on paper, big documents bla bla.
It sucks.

Patrick 19 Sep 06

Matt, your article is excellent. A lack of traditional specs can be made up for in a shared vision. This puts more pressure on leadership to know what they want up front. A skill many leaders lack. They want lower level staff to build specs and then start ripping them apart as the project commences. More IID methods force a visioning session up front with more “informal” documentation (on the walls/wpe boards and such) and then allow the team to break it into itterations that make sense. I can’t tell you how many things I’ve built using the traditional mindset (and it is a shift in mindset) that never get used.

Graham 19 Sep 06

The biggest benefit to writing exact specifications is that you eliminate hearing the dreaded “that’s not what I MEANT for the page to do” from the client after you’ve developed the site/app. I’ve had that happen many times when I worked for a very small shop that didn’t write exact page-by-page specs, and it was a nightmare.

If you’re building sites/apps for non-technology businesses, then you have to be extremely careful in managing expectations. And in our case, we were building small sites and billing them out by the hour, so an extra 3-4 days spend on a project to add a new feature that the client assumed they were getting could increase the price of the entire project by 20-30% above what was quoted. So either the company ate the time, or the client was billed extra and got pissed.

This situation could have been headed off at the pass if we had been writing page-level specifications at that time. Yes, agile development is probably a much more efficient way of working for a team of developers, but only when the developers themselves are the “client” (ie, they’re making an app or widget to market and sell).

Josh 19 Sep 06

Here’s a more spiritual take on confidence, and belief in people:

http://skdesigns.com/internet/articles/quotes/williamson/our_deepest_fear/

Geoff 19 Sep 06

So how does _Getting Real_ apply if you are, say, building a house? Or a neighborhood? Or a 40-story office building?

I like (and try to practice) the agile development philosophy in our tech company. But I’m also a real estate developer, and I am struggling to understand how one can apply these principles in the construction of the built environment.

I’m referring to the agility/design-part. The confidence-in-your-people-part is a no-brainer.

JF 19 Sep 06

We don’t know because we don’t build houses, neighborhoods, or office buildings. The book is about building web apps.

However, you may want to read up on Christopher Alexander. Some of our thinking and some of his thinking is similar in scope and approach.

He even sometimes builds the “UI” first by making cardboard mockups of his structures on sight to see if they feel right in the space. If he doesn’t like the view out of the cardboard window here he’ll patch it up and cut a new hole. It’s a very UI-first approach to a space.

ML 19 Sep 06

In the end the company culture is the product of the people in charge, the CEO�s and other CxO�s. They monitor their managers below them based on documents, who then need documents from the people working for them etc.

Sure. We’re describing the process that works for us. We think these ideas can also be used for client work or inside large companies if people push for them (it may require some educating/convincing upfront). But we understand it’s not gonna fly all the time either.

a scientist 19 Sep 06

my wife and i have been talking about building a house. i’d say we’re “getting real” with it. but i think this also applies to web apps, consumer electronics, writing, etc.

so here’s my insight so far.

build the kitchen first. make the kitchen great. the function of the rest of the house is to compliment the kitchen.

i also build apps. i’ve realized that the app i’ve been working on also has a kitchen. i know it’s the kitchen because it’s what i started working on first. it’s the part that allows users to do the most stuff. later i built the front door, the hallways, the windows, etc., but getting the kitchen right is the most important part.

Andy Burns 19 Sep 06

Hmm. Spec’s aren’t about manufacturing confidence - they’re about establishing a common language and a common set of ideas with the customer. They should allow everyone to understand what’s going to be built, and when it’s done they should explain how the thing works (and why it works that way). Hell, they need to define an end condition or some customers will have you making changes until the end of time.

Anyone who believes that that is a ‘cost’ that can be skipped has obviously never returned to a large system they wrote many years and many projects ago.

I have a project where, 2 years later, we don’t know why part of it was built the way it was. The stakeholder involved at the customer has left, and our spec, although defining the ‘how’, fails to say ‘why’. I don’t think this is uncommon.

That’s not to say what the specs are can’t vary. Sometimes you’ll have leeway, or a simple objective, or a shared vision - then they don’t need to be very complicated. But at the very least, you need to define what your final goal is, and at the end have enough documentation that if you got hit by a truck, someone else could understand what you were doing.

Daniel Higginbotham 19 Sep 06

Does 37signals create apps for outside clients anymore?

No. We’re entirely focused on our own products/projects.

Alex Bunardzic 19 Sep 06

Wow, you guys have managed to water down this issue to an incredible level of whiter shade of pale! What really worries me is that our hosts seem quite willing and happy to play the ‘water down’ game along with you.

Time to step back and reacquaint yourselves with the fundamentals. The first fundamental:

- Centralized vs. distributed

I believe that agile is all about distributed. Which is where the confidence factor comes in. Meaning, we’re confident that only by decentralizing could we ever hope of achieving quality. Let the people bring that quality forth. Screw the centralized policies and procedures!

The second fundamental:

- Exploratory vs. assumed

I also believe that agile is all about exploratory. The non-agile is all about pre-fabricated assumptions. Sort of like covering your ears with your hands and going ‘la-la-la-la-la!’

Effective exploratory behavior can only occur if there’s enough confidence in it. That’s what the original poster was talking about.

The third fundamental:

- This stuff is across the board!

I’m surprised that Jason et al are so sheepish. Yes, they’ve discovered their lesson through building web sites, but they should realize that this applies to any human activity. If you want crap — go with the centralized.

It has always worked that way.

Alex

matt 19 Sep 06

Graham:
“The biggest benefit to writing exact specifications is that you eliminate hearing the dreaded �that�s not what I MEANT for the page to do� from the client after you�ve developed the site/app.”

Then you wrote the wrong specifications. Simple. I grow weary of people being anti-spec and anti-requirements gathering. Unfortunately some people are weary of them because they are often done like shit.

graham:
heh…nvm i’m an idiot…i can’t even read your post properly.

James Kieffer 19 Sep 06

Confidence is earned from feedback. The bottom line is good products as well as design is judged for it’s functionality, and less overtly, for the design itself. If one continously designs for the user and continously receives good feedback… confidence will grow. I agree completely, confidence is key. But I really love what you say about “just make something good.” You’ll know from the feedback, right away, if something is good or bad, indifferent, great, boring or awesome.

Dave 19 Sep 06

Guys.

Don’t you think that the getting real approach you took with the html of basecamp is now getting even with you regarding IE7? And, isn’t writing beautiful, validated html a part of the agenda?

Now regarding client work. If there’s something I hate then it is paperwork but as said earlier - top clients expect that - they want to feel they paiid for a delivereable. Getting Real is great for small companies working on product, not for service companies.

One last thing, please change the IE7 messages in basecamp - it really sounds arrogant and I heard from many people.

mj 20 Sep 06

If you trust the people, the process, and the goal, you don�t need all the bullshit trust-builders like specs, documents, and promises to make you feel secure. You can just make something good.

Um, you’re saying essentially that with good people, a known goal and a solid process, you don’t need “specs, documents and promises”, right?

Hey, I agree.

But in many cases without a spec, there is no goal. Without documents, there is no process. Promises are endemic to “both” ways of doing things.

You’re attacking the language here more than the situation. And because the new language is hip and trendy and buzzword compliant (“agile”) there’s a lot of ‘Whoah yeah!” from the guys in the front row.

Ironically, People (your greatest asset) will always prove to be your greatest liability. I was musing on this subject yesterday - it’s great to be in a cool software company where you can hire by the maxim of only pulling in people smarter than you. It’s a great way to work. you ensure you have smart, motivated people who you ostensibly can trust.

Not every industry and not every company is as lucky.

Building a product where you are the first customer and where your close knit team designs the spec is a luxury. Building a product (software, corporate video, packed lunches) for a third party requires a spec, a cast-iron spec at that.