The Berkun Blog

Management, design, and the making of good things.

Archive for April, 2006

This week in ux-clinic: Leading the design skunkworks

April 24th, 2006

This week in the ux-clinic discussion forum - Leading the design skunkworks:

My UX team is convinced that to achieve their goals they need to go underground - go off and build a prototype, on their own, and show it to th team only when they have something amazing. They don’t want to partner or negotiate: they want to create their blue sky vision and return, so to speak, from the mountain.

Historically i’ve been a politician between UX and the rest of the org, but I would like to try a skunkworks approach, however I’ve never done this sort of thing before. If we go too far on our own, why will anyone listen? How do we keep the project underground? I’m looking for a primer on leading the secret design effort.

- Leading design skunkworks

This week in pm-clinic: Managing the middle talent

April 24th, 2006

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

(Note: please remember that just because I post these situations, I’m not their author: these things aren’t happening to me, but folks on the pm-clinic list. I get mail now and then that assumes all of these situations are *mine* which I find quite entertaining, but worth clarifying).

How do you keep the middle talent on your team motivated? I manage a team of 10 and I find the stars and the low performers easy to manage: it’s clear what i should do and how to do it. But the middle third is tough: i can’t reward them as well the top, and I’m not inclined to manage their performance like I would a low performer: the result is they get less attention from me. I’d like to push them to compete with the top, but I’m not sure I want my team competing with each other too much - so how do you manage for a happy middle talent pool on your team?

- Managing the middle

Writing for Seattlest on design & architecture

April 18th, 2006

SkyspaceAs part of the Gothamist empire of city blogs, Seattlest covers all that’s happening in the greater Seattle area. I’m psyched to report I’ll be writing short pieces for them on local design and architecture.

First up: the amazing Skyspace, one of Seattle’s hidden gems.

Review: 37signal’s Getting real, the book

April 17th, 2006

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

April 17th, 2006

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

April 17th, 2006

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)

April 13th, 2006

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 VPs never say

April 12th, 2006

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 VPs never say.

  1. It’s my fault. Many leaders fear admiting 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 work and not blame deflection. “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. 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 overal goals, and team B wants the org to suceed, 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.
  3. The CEO and I disagree about… In rhyme: Leaders fear showing dissention, 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.
  4. 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.
  5. I’m ending project X and here’s why. One of the roles of a VP is to protect the people who work for them. When projects are killed, the people who worked on them need to move on. If the VP openly blames them or focuses on their failures, those folks lose face. The VP has to find a way to do the right thing (end the project) but not end the careers or reputations of good people who worked on 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).
  6. I’m firing Y and here is why. See above.
  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 necesarily bad: being in the press brings attention to the company, which is an asset if handled right.
  8. If we ship on time, we’ll party at my house. I know many VPs who have had work related parties at their homes. But I’ve never been invited to any of them, so I can claim I’ve never heard a VP say this to me :) Part of this is focus: even if a VP were wealthy enough to throw a party for the entire organization, should they? Wouldn’t it be better for middle managers and smaller teams to throw parties in their own ways? Much of what we claim to want from VPs is in truth best delivered from our direct managers. The VPs job is to create an environment for them to do it in.
  9. 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 similiar hours and make similiar 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.
  10. 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”).

What did I miss? What are other things VPs never (but should) say? And why?

The next book: an invitation

April 10th, 2006

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

April 10th, 2006

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

April 10th, 2006

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?

Seattle: MindCamp 2.0 registration open

April 7th, 2006

Mindcamp is back - Saturday April 29th /30th. A choose-your-own-adventure conference based on popular foo and bar camps.

Info from the organizers and direct to Seattle Mindcamp 2.0 registration.


You're reading scottberkun.com, home of tasty essays. All rights reserved unless noted. You can subscribe here (RSS ).
If you're not sure how to feel now that you're at the footer, joy is free and recommended.