Review: 37signal’s Getting real, the book

The folks at 37 signals have well earned their reputation for making great web applications. They’ve established a strong identity for with a line of web tools for project management (Basecamp), To-do lists (Backpack) and simple collaboration (Whiteboard).

They recently published a short book called “Getting real” about how to build web apps – and here’s my review.

The book is short – 170 pages with lots of whitespace and heavy quoting. If you’ve used any of their apps you’ll feel right at home as they do a fine job maintaining the same voice and style.

The highlight is their passion for making good things. They are most effective when they boldly express their ideals, using them to slash through common assumptions about features, big planning, organization and customers. It’s a brisk and optomistic read. At turns clever and confident, but ocassionally nieve, this book will generate strong opinions and can spark healthy debate even if you don’t like or agree with what they say.

The lowlights are the how – While I’m philosophically aligned with these guys, this book is more mantra than guidance or instruction. I imagine it working as a boost for people who believed some of these things prior to reading the book who, now reaffirmed, can point others to it as an external and respected source. There are obvious counter examples to some mantras, but they’re beyond the point, as the questions raised are worthwhile.

But for those in old-school organizations or with dysfunctional teams, this book doesn’t give the tools needed to turn things around nor provide individual readers with “Real” practices they can employ on their own. Most of “Getting real” is about approach and attitude, and it requires your co-workers to share it with you to work.

The book’s strength and weakness is the experience of the authors: they started 37 signals on their own, and advise largely from that context. While they don’t try to direct readers for how to convert older, larger, slower, less talented teams of people into “Real” teams, there is the vibe througout the book that the world would be a better place if everyone did.

Summary: I recommend this book – it’s a fast and opinionated read. It’s most valuable to small self directed teams, as a reference for how one small, talented, self directed team has successfully built quality software or as a hand grenade for teams that have been doing things the same way for too long. However it doesn’t quite justify the $19 price: there are tragically no references and no links to other sources, something I hope they’ll remidy in a 1.1 book update. (For reference: McConnell’s Rapid Development, with a 5 star average over 100 reviews at amazon, covers similiar ground with near opposite highlights/lowlights, for $22, with thorough links to other sources to go deeper than the text. These two books make a fine pairing).

The Book: Getting real by 37 signals ($19, online PDF only)
Free Excerpts: Scale later, Meetings are toxic, and more

This week in ux-clinic: Blog-‘O-rama

This week in the ux-clinic discussion forum – Blog-‘O-Rama:

We’re a tragically hip start-up and recently we’ve gone blog-mad. There’s pressure to reframe much of our website into blog style designs, most notably, by designing pages in blog chronology style. This makes sense some of the time, like for press releases, but for other parts of the site it makes no sense at all (page about our executive team that isn’t updated often). What’s are some good guideliens for going blog/chronology centric, but also for staying away?

-Blog-‘O-rama

This week in pm-clinic: The softer side

This week in the pm-clinic discussion forum – The softer side:

Most of our PMs have some type of technical or business background, and the area of growth most pressing for us is softer skills – things like collaboration, leadership, negotiation, conflict resolution. My question for the clinic is: how are these skills best obtained? How do your organizations value/reward/grow these types of skills (or are they not valued much at all)?

The top 100 most innovative companies (BW)

BusinessWeek Online has just posted their top 100 list.

The rankings were determined by votes from 1000 executives from large corporations: probably not the the best folks to make rankings like this, but it is the audience of the magazine, so there you go.

The top 5 are:

  1. Apple
  2. Google
  3. 3M
  4. Toyota
  5. Microsoft

More curious is their abuse of the word innovation:

Today, innovation is about much more than new products. It is about reinventing business processes and building entirely new markets that meet untapped customer needs. Most important, as the Internet and globalization widen the pool of new ideas, it’s about selecting and executing the right ideas and bringing them to market in record time.

Since when does selecting ideas and bringing them to market on time have anything to do with innovation? Don’t these things apply to running any kind of bussiness at any time?

Specific to their list, Google is in the search engine and advertising business (at least that’s their largest current revenue) – which are entirely old markets: at least a decade old. Apple’s ipod was not even close to being the first digital music player – and the market, personal music players, is also years old. Shouldn’t the first search engine and the first digital music player get the lions share of innovation credit?

Or perhaps a better question: is there a way to seperate out innovation, which should be hinged on development of new ideas, from execution, which is delivering a good, timely product to market? Lists like this one entirely confuse the difference between these two concepts.

Ten things Bad VPs never say

Being an executive is a tough job, no doubt. However there are a set of things any rational person has to believe about executives, that don’t match their behavior. Sometimes there are good reasons for this, sometimes not.

So for fun, here’s my top ten list of things Bad VPs never say.

  1. It’s my fault. Many leaders fear admitting failure for their projects, much less taking personal responsibility for them. But if a VP says this and means it, they absorb blame, freeing their orgs to focus on learning from failure, rather than pointing fingers. “It’s my fault” or “I’m accountable for that” are power building phrases. You bring power to you when you re-establish responsibility for things you’re responsible for, especially in failure.
  2. I’m ending project X and here’s why. It can easy to let misguided or inefficient projects live are far too long. One of the roles of a VP is to be decisive, and make clear decisions, including the decision to end efforts that aren’t working to free up resources for other projects. The VP has to find a way to do the right thing (end the project) but not whitewash it. The failure however is that if too much face is saved, the lessons from the failed project are not learned by others (and those failures will be repeated).
  3. I’m firing Y and here is why. See above.
  4. Team A is more important than Team B. Like parents, most VPs tend to project equality over things that are not equal (“You’re all my favorite children” – Sure we are). In reality every VP knows which teams matter more to his organization and in private treats them as such. The fear is that people on team B will be upset if they learn their status – but I’ve seen the opposite. If team A is clearly more important towards the overall goals, and team B wants the org to succeed, it’s in their interest to prioritize around team A when appropriate. There’s no shame in playing a strong supporting role. Every team sport in history teaches that some roles, at some times, are more important. You win or lose based on how well everyone plays their role at the right time.
  5. The CEO and I disagree about… In rhyme: Leaders fear showing dissension, despite signs for those paying attention. Hearing a VP politely discuss a disagreement with his superior makes it acceptable for his reports to acknowledge their disagreements with him. But if instead he pretends everything is great, there’s a mismatch between what’s said and what’s believed. People know instinctively when something is wrong: decisions that don’t line up. E-mails that hint at contradiction. it’s a relief to hear it articulated, even if only in passing, especially if how that disagreement is being resolved is made clear.
  6. My morale is low. What happens when the leader, the figurehead, doesn’t believe? I want to argue that there are ways to communicate this to a team without killing their morale, but this may be something best held in confidence. Many of the things we wish VPs would say may be based on to only those in their confidence: a handful of people in their organizations. However, there is every way for a VP to communicate his/her concerns. A short list of top concerns every month or quarter, presented with the right vibe, can go a long way towards surfacing solutions to them.
  7. No, I don’t want to be on the cover of Time. To want to be a VP requires an ego. No person in the history of the corporation has been forced, at gunpoint, into executive status. All VPs are highly visible and either enjoy it or think that they deserve it: to decline attention would contradict much of their sense of value. Having an ego isn’t necessarily bad: being in the press brings attention to the company, which is an asset if handled right. But some executives confuse media attention for themselves with the job of running a healthy organization whose products and services are worthy of media attention.
  8. I will work as many hours as you do. While it’s true that executives often have intense schedules, it’s rare to see them point to line level employees and say “I will match your average week hour for hour.” I’ve never seen it. Especially during crunch time when overtime is common, seeing a VP put in similar hours and make similar commitments as the org is a tremendous morale boost. I have seen senior managers stay around and do near all-nighters on crunch night, and the effect it always had, if done without fanfare, was powerful. It’s something everyone talks about the next day.
  9. Here’s exactly how much I earn and what my bonus structure is. I’ve often wondered what would happen if corporations had transparent pay scales – public jobs often do (teachers, senators, police officers). No law prevents an employee from posting their paychecks on their office door. In specific to executives, knowing how they’re rewarded explains tons to their organization. Good VPs do communicate what their personal goals are, but knowing even the non-financial elements of their rewards (what are they rewarded on?) might be more useful to the organization that what’s in the project vision. (Of course, this would require that CEOs define the rewards. Begging for a list of “ten things CEOs never say”).
  10. What did I miss? What are other things VPs never (but should) say? And why?

The next book: an invitation

The next book I’m writing is about innovation: how and why new ideas develop the way they do. I’ve signed a deal with O’Reilly, publishers of my first book and work is well underway.

I’ve chosen innovation because it’s central to everything many of us want: for things to get better. But it’s also a misunderstood and violently misused term. It’s commonly abused in the tech sector, where you see it used as a filler word in naming and describing things: Innovation is the lorem ipsum of current bussiness and technology marketing filling in when people are too lazy to say what the mean.

The word even surfaces now in marketing literature for ball point pens and pizza, begging the questions:

  • Have we forgotten what innovation is?
  • How is innovation different from ‘good’ or ‘new’?
  • What are the common misconceptions about how innovation happens?
  • Can anyone innovate or just those born to do it?
  • What can we learn from innovations of the past, if anything?
  • Is the internet age that different in how innovations are found, developed and promoted than the work of Newton, Edison and Ford?

This is just the tip of the iceberg, and my aim is to explore these kinds of questions and answer them.

This blog post serves to invite all of you to participate in the development of the book. I’ll be discussing my ideas on this blog, linking and commenting to related findings along the way. I’m hoping you’ll chime in, give feedback and participate in the writing of a good book.

For starters:

  • I’m looking for nominations for people to interview. Who is the most innovative person you know? Have worked with? Have ever heard of? Give me a link or an e-mail address and I’ll put them on my list.
  • Are there other books, references or websites I should know about? What’s the best story of innovation you’ve read?
  • Or just say “Go Scott! Looking forward to the book!” :)

(Update: get interviewed for the book online and share your innovation stories.)

This week in uxclinic: Death by comparison

This week in the ux-clinic discussion forum – Death by comparison:

I’m a usability engineer on a major web site. Our senior managers are addicted to data. Hard core data. They make all decisions based on metrics and what the call “the metric function” – the equation that best determines what success is.

So when it comes to usability, the only studies they’re interested in are comparative ones, where I do A/B testing, or in some cases A/B/C testing. Even when we prototype or experiment, they always want the data housed in comparative data.

How do I get them out of this data rut and recognize that usability engineering involves more than generating numbers to put in charts? Or is this how most of the tech sector sees usability: a number factory?

This week in pmclinic: Mutiny

This week in the pm-clinic discussion forum– Mutiny:

Mutiny

This is one for the history books – I have quite the situation on my hands. I’m the PM for a 15 person team. My peer is the lead developer, who manages 6 programmers (of the 15). We disagreed on a major project decision, brought it to the VP, and he went my way. But since then, the lead developer has stopped talking to me. I mean, he won’t even answer my questions.

Whenever possible he tries to backfill the decision, directing his team towards the outcome he wanted, despite the VP directive. At first this was just frustrating (for me and the team), but now it makes me look incompetent and puts the project at risk. Morale is dropping, as we’re like a family where the parents have stopped talking to each other and programmers are taking sides.

Help?

The victimization ratio

Interesting, if cynical, post over at next-microsoft. He mentions part of his criteria for chosing a job is how much power he would have to solve problems that impact him.

Basically the idea is this (a now corrected paraphrase of his post):

A = Number of problems you see
B = Number of problems you don’t have the power to solve
B / A = Victimization ratio.

So if you work in an environment where you can point out 10 problems, but are only capable/empowered to solve 4 of them (you are powerless for 6), your victimization ratio is 6 / 10 = 60%

I think this should be modified to include C) problems you can get someone else to solve for you. If you have a good manager, or even a good team of peers or reports, they may have the power to solve problems that you can’t.

I’d argue that a good manager solves problems for their team all the time that the team doesn’t have the power to solve on their own (e.g. poltical/upper management issues).

Then of course there’s D – Problems that initially you don’t have the power to solve, but can obtain if you ask for it, fight for it, or prove you’re worthy of. There’s going to be a trend line for D – how easy is it to demonstrate you’re worthy of more, and how fast is it granted to you? I think that’s more important than how much you start with.

I’d invert the value and call it The empowerment ratio. And call D the rate of empowerment.

Full article – The victimization ratio

A year in the life of a book: a summary

My first book was published almost a year ago – While no one can predict book sales, that hasn’t stopped people, especially writers, from trying.

Below you’ll find a year’s worth of amazon.com sales data for The art of project management (provided by rankforest.com) with notes on my activities (This starts 4 weeks after the book was in stores because I didn’t know about rankforest until then). There are problems with amazon rankings, but they’re an easy indicator to track.

Here is the promotion rundown from 5/1/2005 to today:

Who knows if these efforts help – plenty of books do well without things like this, and many with big promotion budgets do poorly. It’s complex and a topic for another post.

However it happened, the book has been a big success. Thanks to all of you for visiting, reading, buying and spreading the word about the book. Every sale motivates me to work that much harder and write that much more.

The pairing of writing books and being for hire as a trainer/consultant feeds off each other: people who like the book often hire me and people who hire me often buy the book. So for any would-be writers out there, this is a great approach for a first book.

I’m doing well and have signed to write a second book for O’Reilly – I’m on track to put another dent in that shelf.

For fun, comparative data is listed for Malcom Gladwell’s book “Blink”. Not sure what happened to him on 10/16, but it looks like he survived his largest rank-drop: from the teens down to 57.


booksales.jpg

Pms vs. Programmers (This week in pmclinic)

This week in the pm-clinic discussion forum– PMs vs. Programmers:

Welcome to April (If you’re in the USA, time to get your taxes done).

Here’s this week’s situation: The raging debate in my corner of the world is PMs vs. programmers. Our management just agreed to hire another two PMs for our organization, instead of hiring another two programmers.

Most of us (the other programmers) think it’s a mistake: our biggest needs are team bandwidth and productivity, not planning, client management or crisis management. We’re afraid of the ratio of PM to programmers spiraling us down into unproductive misery. Most of the PMs around here are non-technical and can’t help much in technical decision making.

Two part question:

  1. How do you know the right ratio of PMs to programmers for a team?
  2. What level of technical skill should PMs have? CS degree? former programmer? C++ for dummies? Or none at all?

This week in ux-clinic: Being the UX hero

This week in the ux-clinic discussion forum– Being the UX hero:

Our group is in the process of launching a new version of our external website, but the solo developer left before it was finished. He claims it’s 90% done. No UX priniciples were used up to this point (we were busy on actual products). None of us have time to take it over, but we have a budget to bring in someone else.

I have two fears / opportunities:

1) There’s an opportunity to teach my org a few things about how UX should be done. If we bring someone in, will they be seen as the heroic talent, saving the day, and not my UX team?

2) If the day is saved, by us or by a contractor, I don’ t want the wrong lesson to be learned. I want to make sure that everyone understands this is not the right way to go about designing things (apply design magic dust in the last stretch). So how do I get design involved without teaching management and the org the wrong lesson?

– Being the UX hero

The GEL Conference (May 4/5) – Why you should go

Gel 2006 The early registration deadline for GEL 2006 ends next week, so it’s a good time to make a pitch for why you should go.

Good Experience live is the only conference I’ve been to that is self-reflective: many of the principles of design and good user experience espoused during the day can be found in the way the conference itself is run. Day one of the conference is out in the field, spending time with experts in their domain: an inside tour of the experience design of NYC landmarks like Natural history museum, MoMa and the Hall of Science. Participate in an improv experiment on the midtown streets or a learn how to apply tmusic techniques to your work. There’s also a food experience tour of my home burrough of Queens, NYC.

Day 2 are talks from Craig Newmark (Craigslist), Jason Fried (37 Signals), Seth Godin, Douglas Rushkoff, Photographers, Urban pranksters, Game designers and other interesting perspectives on making great things for people. There’s no formalized boundries here – instead you get great cross-discipline stimulation that will stay with you long after you leave.

The conference rates are still discounted Before April 5th, it’$1200 for both days, and $1500 afterwards. (Price was $900 before December 1st, but that’s behind us now).

I’ll be running a Day one tour on NYC’s sacred places. We’ll be walking around the city and exploring magical and special places, discussing how they were designed to have the effects they have. You can sign up for this or other Day 1 tours when you register.

Hope to see you there.

The Vista saga: an opinion

The announcement of the Vista delays has sparked a new round of debates about what’s going on at Microsoft. The mailbox has been full of questions for me on the subject – so here’s some insights from a former employee (’94-2003) and manager in the Windows division.

For sanity – I’m an independent and this is not an apology, rant nor inside scoup. Instead it’s commentary from a management author on what’s been said and what’s going on.

  • Centralized authority and MSFT culture. The most comical misperception about Microsoft is the management style – everyone think’s it’s a rigid hierarchy, when it’s mostly a consensus driven place. Everyone gets an opinion and senior managers are often more skilled at consensus management than leading teams. If there’s any one thing I’d point to for large failing projects is lack of successful central authority – With a project in trouble I’d move to centralize power in a smaller number of people and free them to run with the ball. The rub is that the culture doesn’t support this well – people still want a consensus mentality (something born of small team and start-up culture), they want to own their slice, even when it’s contributing to driving projects into the ground (or at least mediocrity). It’s in the fiber of the company and it’s hard to change.
  • Talk is cheap. Every time I read rants about gutting Windows, firing all the VPs or making Windows open source I have one comment: I don’t believe you’d do it if it were your job to manage Windows. As easy as it is to yell orders from off the boat, I doubt most people, if given the helm, would put an $8 billion machine at risk. Certainly not now, as it would mean another 2 years of development. Besides, no one wants to be the one that tanked one of the greatest franchises in technological history (regardless of how that franchise was built). Even if big, bold moves are in order – I doubt most of us would have the guts to take those risks if we were personally accountable for the results. It’s a classic innovator’s dilemma situation. A better gripe is how the franchise hasn’t been managed on a steady progressive course, given how many possibilites there are for making things better without taking radical moves.
  • It’s never just one thing. It’s fun and convenient to chalk up project problems to one issue. “The VPs are idiots – fire them all!” or “they were too ambitous” but there’s rarely one reason (Nothing drives faith in the easy answer more than frustration). Most of the time there are several factors that conspire together, especially if it’s a large project with large goals. There are often successful sub-teams working inside most large, problematic projects (And some are speaking out over at mini-microsoft). As a consultant, understanding (and fixing) projects involves finding the factors and accouting for them without tanking the parts that work well. There’s rarely a single move that saves the day and any problem that took months to develop is not going to be solved in a hour.
  • A slip is infinitely better than a panned product. With a slip, even 6 months, people will cry and scream but the world will not end. However, with a bad release, like Windows 98ME, Bob or Netscape 5, the world just might fall on you. So while a series of slips shouldn’t inspire confidence, it does mean there is a sane person somwhere in the organization with their hands at the controls. The Vista news has been mostly negative, and no competitor has tried to capitalize on it, meaning a slip has little competitive risk.
  • However, the door is open for competitors . The bad Vista PR over the last year has made a window – Linux, Firefox and Red Hat should be doing something: a viral ad, a marketing campaign, anything. But they’ve been awfully quiet and I don’t understand why. I think this is the more interesting story than what’s going on in Redmond. The MSFT Windows multi-slip ship cycle is an old (perhaps sad) story, but the silence on the battlefront deserves more attention.
  • Microsoft’s PR and public management of the Vista project has been reactive and weak. I’ve never thought PR and marketing were well directed by executives (well funded, yes, but well managed or empowered, no). Many announcements and launches were messaged in the blandest, most generic ways possible (Win95 and X-box the most notable exceptions). Microsoft is inherently a conservative company (in strategy not tactics) and its always shown in its advertisements and approach to PR. For all the stereotyping of Microsoft as a great marketing company, I never saw it: Nike, Intel and Apple are all dramatically better and amplify the value of their product lines. Vista’s failures to date are more dramatic from a PR and messaging perspective than anything else. They’ve failed to articluate a value proposition (even if invented), and to bring a positive meme around the release to match or compensate for the litany of negative announcements and setbacks. The greatest failure of the project to date isn’t technological or managerial – it’s PR and messaging. A private train wreck is one thing, a public one is another.
  • Windows is a bear. Much of the franchise has been based on backward compatibility and some things that should be improved in the abstract can hurt the product line – it’s a trap any successful platform faces eventually (Just look at HTML or javascript). People write code to your bugs or inconsistencies, and when you come back to fix them you realize you’ll do more damage to them than good – a quality inversion. I don’t justify how the product got where it is – but here it is. Deciding what to do in any direction is strategically and technically complicated – this shouldn’t mute the complaints of unhappy customers, but it should be noted by anyone confident they can do a better job. Quality inversions surface in any project successful enough to see a version 5, or in Window’s case, version 8 (Win 1-3, Win95, Win 98, Win 2000, Win XP, Vista).
  • Sinofsky is an inspired move. The MSFT culture, historically, is heavily polarized between Windows and Office. In my day Windows were the smart-ass cowboys who liked risks and breaking rules – not surprisingly Windows had a history of confused early projects that came together only on the home stretch. Office (again, in my day) were stereotypically smart, reliable, consistent A students, who won through plans more than passion. Sinofsky (formerly the Senior VP of Office, now VP of Windows) is the first major attempt I know of to bridge those philosophical and management differences: there’s something to be learned in both directions.

Surviving the blue sky project (This week in ux-clinic)

This week in the ux-clinic discussion forum– Lost in the tag cloud:

Here’s this week’s situation:

We finally got buy in to fund a future thinking blue sky design exploration for future releases of our software and websites. Problem is: we can’t decide if we should have internal designers do the work, or hire out a fancy firm. The debate is raging and I’m on the fence (and it’s my call & budget).

What’s the best way to do the following:
1) Manage an intentionally future thinking design project with few constraints
2) Decide on internal vs. out-source staff
3) Deliver something that doesn’t seem like a waste of time.

– Captain blue sky