One question that’s coming up in in writing the innovation book is this: when has an innovation taken away something from your life that you valued?
For example: I used to love making funny answering machine messages. But now my wife and I have cell-phones. Few people call our home number anymore. The joy of having a shared message, a shared way to greet people, and the fun of making silly messages together, is gone.
Cell-phones are good – but just because they’ve progressed us in some ways doesn’t mean they haven’t left some good things behind.
I’m looking for examples of how innovations have eliminated things you miss, for any reason (I mean, I still miss rotary phones for some strange reason, so nostalgia counts).
Reasons you might miss something:
It was actually better than “the innovation”
It had some good qualities the innovation doesnt have
The older style appeals to you
The older thing is more reliable or durable
It reminds you of good things (memories, times, people) the innovation doesn’t
Have any examples? I’d love to hear ’em. Please name the new thing, the old thing, and why you miss it. thx.
So far more than 40 of you have taken a few minutes to add your thoughts to mine for the innovation book I’m working on. You guys rock! But… but I need more of you.
You see, in a writerly stupor, I placed a rather large bet with some dangerous people that I could get at least 50 people to fill out my crazy interview form by Friday – and I’m getting nervous. And there is nothing less useful to the universe than a nervous writer.
Our team has a monthly process called add/cuts, where all the head honchos get in a room, look at the feature lists, and decide what features to add and which to cut. These things are usually quite bloody, carnage heavy affairs – typically 80% cuts and 20% adds. It’s an ad-hoc meeting where we review goals, run the work item lists, and try to make things fit the schedule. Unfortunately it often falls into ritual feature killings, where each head honcho cuts things to prove to the others how hard core they are.
The result is that the meeting functions best to motivate people to finish work before these meetings (perhaps good), but also to skunk work, hiding work items, to avoid having them discussed in these meetings (which is bad).
I’m influential enough that I can propose a different way to run these feature level add/cut meetings. What should I propose?
I’m on young team that has finally admitted to itself that a much-hyped feature of the last release (2.0) is actually quite bad. As in, on one can even figure it out to fully realize how bad it is bad. The problem is, everyone is all thumbs when it comes to what to do about it. The business folks want us to leave it in (the evil feature is still part of the marketing literature), but us UI folks are all for tearing it out – the problem is, how?How do you make the argument to throw away weeks/months of work? How do you message this to customers when something that was there disappears? I need the playbook for how to cut a bad, previously shipped, feature.
Slate has a nice slide show by the famed architecture critic Witold_Rybczynski about major works of architecture that were big failures. It’s a good runthrough of some large scale works, with Cliff’s notes like commentary from Rybczynski on where things went wrong.
I don’t agree with his opinions on some (I’ve been to half of them): EMP is ugly, but still breathtaking. The Montreal stadium is a functional failure, but has amazing aesthetics, and the Getty museum rocks a free escape from the USA, a magic otherworldly garden up on a huge hill, looking down on LA.
I wonder what a slide show of greatest software duds might include? And what would we say about each one?
This is #7 on the list of questions I get asked most often ($10 if you can guess #1). It’s hard to find good people, period. Everyone complains about this in every industry everwhere so get used to it.
The challenge is that seeking talent has an inverse polarity: The louder you broadcast your job openings, the smaller the ratio of good candidates you’ll get (You may have 10k resumes, but a tiny percentage of good ones). If you want to avoid the misery of long coffee amped nights of resume skimming, put some energy into targeting your efforts.
Here’s some thoughts:
Ask the best PM you know. They have the highest odds of knowing people like them, or being aware of any mailing lists or social circles with like minded people.
Ask the socialites in your org. People who socialize more, especially within the tech-sector (dork-bot, biznik, linked-in, etc.) have more names in their mental roladex than you do. This is an asset: use it.
Use your own network. Recruiting is precisely why team leaders need networks: you need to have a list of people you can call on to help you get the word out. The better your network, the more good relationships you have, the higher the odds your network will deliver good candidates to you.
Host a job fair / social at your company. If your network sucks, build your own. Throw a kick-ass social event at your digs, and let it be known that you’re looking. Social events work to your advantage on so many levels: it makes you look cool and friendly (well, if you’re good at it), it draws people you don’t know to you, and opens backchannels with people who fit #1 & #2 above.
Grow your own. I’m a believer in underdogs. I like people who might not have pedigrees, but have the right attitude, potential and passion. If you can’t find good PMs, then make them – it takes time, but possibly less than hiring and firing medicore people year after year. Start an internship program: one intern a summer. If you do it right they’ll return to college with great things to say about you, recruit on your behalf, and have high odds of wanting to return full-time when they graduate. Also look inside your organization: who is ripe to move out of a specialized role into being a pm or team lead? I’d set it up a role for new/junior level pms to take on smaller projects and learn as they go. They’ll be willing to learn whatever your culture of PM is, unlike most of the hardened 10 year veterans you might think to hire.
Make smart, fun job postings. People forget how much the job posting itself does to filter good people away. Don’t write a corporate HR filtered broom-up-your-ass description if you want fun, dynamic, entrepreneurial, self-driven creative team leaders: that’s oil and water, you’ll turn them all off. If you want people with a sense of humor, put some humor in there. etc. Don’t mislead people (e.g. “you will be paid millions to manage naked playboy model programmers”) but do make the posting a reflection of your environment: use the right kind of bait for the kind of person you’re hoping to catch. If you have a high intelligence bar, write the posting in a way that demands some intelligence just to apply (A puzzle, a game, awareness of particular concepts/books/films, be creative).
But in the end, most people chose to make broadcast job postings because it’s easy, and you never know. Here’s a short list of places to try:
For UI PMs. This is the project management flavor for user experience or UI work. I’d post to the chi-jobs list, or look for IA, UX, usability and design job lists, and post there. (For some reason I’d bet on a pm who lurks on those lists, over a hard core pm on a hard core pm-list, who claims to be a UI god).
General PMs. There are various project management sites that list jobs. Be careful. Some PMs fit the NASA, big methedology, big bureaucracy model. Others are the ninja, agile, weby, small team, small schedules, types. Know what you want and post or write postings accordingly. Try allpm.com, ittoolbox.com, or check out this mega-list of pm job boards.
Have a tip for finding good people? PMs or otherwise? Please comment.
One common pattern I’ve seen with small tech companies is how their initial success by focusing on self-driven engineering talent creates problems they are completely unequipped to solve. I call this the start-up management inflection point.
The premise:
Small engineering start-up is born, does well, hires like mad.
Heavy hiring bias for self-driven solo programmer prodigies.
Company grows; scores of engineers are productive, but conflicts and miscommunications rise.
No matter how self-directed programmers are, eventually their utility declines as ambiguities in direction, conflicts in direction and ownership increase.
When a certain size is reached, likely 100 to 200, the company changes because of scale effects. But scale effects are hard to recognize, predict or compensate for. Hiring more brilliant engineers won’t solve this problem.
The trap:
The organization has history of success without management talent.
The staff has biases against depending on management to solve problems (that’s why they joined a startup).
Organizational leaders are engineers first, managers second (or fifth). This may include the founders and CEO, who’s only sanity check on management philosophy is themselves.
Even if leaders want better management, it’s not a strength. Worse, they’re trying to improve management in an environment resistant to it.
Dozens of tech-sector companies are stuck in this trap and have been for years. They have manager to programmer ratios of 15 to 1, bad user experiences (a common result of different programmers designing things differently) and consensus driven decision making models that squander programmer brilliance.
For awhile the fast pace of changes hides these problems, but soon those with more experience realize the effectiveness of individuals has dropped dramatically.
So what’s the solution?
The answers come fast if everyone has shared goals. Someone has to call out this new kind of problem: the meta problem of scaling up #s of people, and make managing it a top goal. Talent and passion alone are not the solution to this new kind of problem.
Good questions include:
What are the symptoms? The pain points?
Which teams have been best at overcoming them? worst?
What can be copied or emulated from the good teams, or from other similarly sized startups?
With those questions fresh in everyones mind overcoming the inflection point is possible.
Goals start-ups need at the inflection point:
We want everyone to be as productive and happy as possible
We want programmers to be as autonomous as possible, without diminishing #1
We are a different company and need to actively ensure those things are still true
With pain points + goals, the magic happens. People can see why surgical addition of management structure, or smarter ways to work when you have teams of teams, are logically necessary. It’s the same smart, no-frills behavior that’s gotten the company to where it is, just applied to a different dimension.
Tactics to use to get past the inflection point:
The pain points of any growing start-up vary. But here’s a starter list of common tactics that should be considered.
Create an empowered team lead role, for people talented at leading, communicating and organizing. This is a different skill from writing great code: recognize your best leads won’t necessarily be your best coders. Invest in rewarding, hiring and training for this role. Don’t default to making your best programmers leads, as that is classic Peter Principle behavior. If you create the role, don’t create rules or procedures. The leads will self-create with their teams as needed.
Clarify who has tie-breaking authority to end consensus-madness, break political deadlocks, and over-ride virtual team Catch-22s. This gives people a stupidity extinguisher to handle flare-ups in communication bottlenecks. Reward folks who use their authority appropriately.
Make every VP or senior manager say the word Delegate, 5 times a day, and at least once before every meeting. As start-ups scale, founder types often become bottlenecks: they have to learn to get out of the way.
Have every VP or senior manager wear a t-shirt that says “Hit me if I Micromanage you” every Wednesday: call it Micromanagement recovery day. Serve beer, pizza and smash magnifying glasses with hammers. (See An Open Letter To Micromanagers)
Use a simple process for planning work. XP, lightweight specs, something – it’s unavoidable, but it doesn’t have to suck and you do need to have one. More people means more dependencies, and eventually retroactively handling dependencies costs you more than catching them before you write code. Let teams experiment with methods until ones that work best are discovered.
Whatever you do, clarify the reasons/goals before you do it. Then check in with all the impacted parties in 2 weeks after the change, and see if the pain is gone. If it’s not, stop or change what you did, and try again.
[1] – Most start-up literature I’ve read focuses heavily on getting off the ground. I’ve found little about the difficult transition from start-up to small company, especially from a management perspective. If I’ve missed a good resource, leave a comment.
I lead a small team of 6 – we’re paired with 3 other small teams, all reporting into the same group manager.
Problem #1: the group manager doesn’t have a vision. He’s vague and tends towards disinterest in leadership matters.
Problem #2: All of us leads have visions, but they’re different.
Problem #3: Leaders and founders seem content to let us fight out our respective visions in code.
I’ve run up this hill before – it’s not fun. I want to find another way to deal with the situation and I’m hoping pmc can help.
Recently, I switched from working on consumer websites, to the more staid, practical, button-down world of accounting software. As in, accounting software for accountants. In reviewing all the usability classics, I’ve noticed how focused on the pick-up-and-play side of things most of it is.Aside from the odd mention of Fitts Law and the number of clicks required to perform a task, there’s little coverage given to designing for efficiency, especially expert efficiency, in interface design.Anyone have experience with designing for performance, not ease of learning, as job #1? What tips and/or references can the list offer that might help me adjust my mindset to this new set of demands? Is it even possible to make such data entry software a pleasure to use?
I’ve done nearly 20 interviews so far for my next book, and I need more. To quicken the pace I’m being innovative and going digital.
Call for all innovators
If you have a good story of innovation, or have thoughts on how innovation happens, I want to hear from you.
What do you get:
Opportunity to contribute to a book about how good ideas come to be
A thought exercise in what innovation means, as my unusual and well honed questions will make you think
Chance to win a $150 amazon gift certificate, and possibly other prizes
Recognition on great work you or your organization have done that others don’t know about
The survey is a scant 15 questions long, and should take less than 10 minutes. If you give high quality answers, odds are high I’ll want to chat with you 1-on-1 over e-mail or phone, and may use your material in the book.
Beta 1 releases are tricky strategically: you wan’t to hold back on some big features so competitors have less time to recover, but you do want mileage and feedback on big changes. As beta releases go, this one is conceptually conservative. Especially since IE7 is late in the game, with a recent beta 3 release.
Highlights
Easy install. Three screens and you’re in. Smoother than many final release installs.
Auto spell checking in text boxes! A feature I tried to get into IE for years – stupid reasons prevented it, so I’m happy to see it now. (But it does hyperventilate on HTML editing (e.g. blogs) – and needs to get smarter, or have an optional toolbar button for toggling it off).
Edge case experience improvements. FF remembers your session set up, tabs and all, on crash, and can recover. A sweet safety net.
Beta Stable. You never know what beta means, but its held up ok. A crash an hour or so in most sessions.
Lowlights
It’s a low profile release. Most of the work appears to be infrastructure: phishing protection, Javascript 1.7, new installer, etc. It’s good they’re striking at the root of the tree, but it’s not a user experience release.
Microsummaries are weak. The idea is odd but interesting – but its current design demands custom, browser specific work by content providers, so the feature ships in beta 1 in a functional coma (IE4/NSCP4 had dozens of good features die soon after this exact kind of birth). The docs suggest autosummaries, but doesn’t provide any. The big question is how dynamic titles impacts recall when looking at a list of bookmarks: will they re-alphabatize? Will they stop updating if I rename them? Questions abound. This seems like a solution in search of a problem and the spec is without a screenshot: a UI design red flag.
Hard to discover what’s new. Any beta should offer a fun walkthrough of screenshots showing me what’s new and what i’m getting for rolling the dice with my computer. I looked for ten minutes, and the best approximation I found was over at Lifehacker. A checklist of unlinked features is lame -help me, as a beta tester, or blog reviewer, feel the love.
Not much to play with. After twenty minutes I felt I’d seen what I needed to see. There just isn’t much to explore or tinker with (as a non FF-developer). So I’ll unistall and wait for Beta 2.
Some reviews I’ve read highlight the new History menu (replacing the idiotic Go menu – yay!) and its list of closed tabs. It’s a thoughtful gesture, but it’s a hacky, Microsoft-esque UI design, in that the real solution is a better tab close model, rather than a greasetrap that captures things after they’ve fallen.
But there are other UI problems with the history menu: it still colides the history tree with the back tree. Take a look:
These two snapshots show two different histories: one for the back tree, one for the history list? Why two? Not sure – probably because back/forward follows a pruning algorithm and the history list doesn’t. But now that there’s a history menu, the conflict is more obvious (or then again, perhaps only browser UI weenies like myself catch these things). The back button is king here, so I’d rationalize in it favor of whatever it’s behavior is.
Here’s waiting for beta 2. Working on trying to get IE 7 Beta 3 installed, so stay tuned.
The good folks at step two designs are taking me on tour in Australia next month – If you or anyone you know lives in the only country that doubles as a continent, please help spread the word.
Where: Sydney, Canberra, Melbourne – Sept. 1,6,8 What: An interactive fast paced class for folks who lead or work on projects, particularly UX or design intensive work.
Topics include:
How to diagnose and resolve common project challenges
Techniques for building credibility and earning influence
Tactics for setting goals, tracking work and delivering on time
How to prevent a crisis (and how to survive it when it happens)
An understanding of how managers view the role of user experience specialists (and how to use it to your advantage)
Through interactive discussion and fun exercises, you’ll explore why so many web and software projects fail, how to influence decisions you don’t control and how to successfully plan and schedule your own projects.
Who should attend:
Project managers for web and software projects
Folks who work on project teams
People who have survived tough projects or are on one now
User experience professionals, including usability specialists and information architects who want more influence
People who like to learn through humor, stories, real situations and discussion
Tons of interactive learning, fun exercises, comical war stories, answers to your toughest questions (including post-class e-mails), the meaning of life, two kitchen sinks, plus a copy of the bestselling artofpm book (Which I’ll sign, spill beer on, or do other activities of your choice with) with every registration.
Biznik is a fun Seattle business networking group – they host local events and meetups for people looking to trade skills and meet interesting folks. Every member I’ve met so far seems smart and cool, so it’s time to get involved.
So, this month UX expert Ario and I are running a Biznik event:
When: August 23, 6pm Where: 1730 Minor Ave Suite 1100, Seattle WA Cost: $25 (Pays for the room/overhead)
The session is unusal in that it’s BYOW – everyone brings something they want critiqued, and we use that to teach lessons, explain concepts and offer alternatives. No lectures or big theories: just real websites and good advice.
To attend you have to be a biznik member – but becoming one is free and takes about 20 seconds (Ok, maybe 30 if you type slow).
The history of innovation has many crazy tales – the patent office is involved in many. In 1836 the first U.S. patent office burned to the ground: despite all the great ideas in the building, they didn’t get around to fireproofing the building itself (An ivory tower lesson if ever there was one).
Anyway, the fist 10,000 or so U.S. Patents were lost in the fire – about 2000 were recovered but the rest were lost.
After the fire the Patent office began its numerical numbering system (giving up on the prior name and date system) – U.S. Patent #1 was granted to Senator John Ruggle of Maine.
The invention? Comically enough, a reinvention of the wheel. Ruggle designed a new train wheel that yielded more traction and prevented sliding.
The true first U.S. patent was for pot ash (no, not that kind) and granted in 1790. However patents in Europe date back hundreds of years earlier – but that’s another story.
We’re a pair of UX folks (a designer and a usability engineer). We’ve teamed up to turn our team around, but despite our awesome talent combo, we’re spinning our wheels. The team had the good sense to hire both of us, but is fixated on tiny, short term, miniature UI developments. Big architecture work is added to the schedule easily, but all the UI bits are “tweak this”, “improve that”, or “provide a basic UI for new feature blah”.
Our team is smart and leaders are good – but they’ve never taken, or witnessed, a big bet on UI, despite the customer centric project goals. How do we use our powers, design or usability, to change our leadership psychology so that sizable UI/UX investments are part of the game?
I’m a project leader in a research organization – as in a hard core blue sky R&D future thinking lab. We loosely organize around projects but our goals are the inverse of typical software: it’s the IP and the concepts we invent that people pay us for, not feature sets or code quality. Our releases to clients are vehicles for our concepts and research, but nothing more.
What I’m looking for are ways to apply project management skills to blue-sky, big think, projects. Can we improve the quality of our process and scheduling, or get more mileage out of the concepts we invent, but with a minimum impact on our ability to experiment, change directions, and go after big powerful ideas? What do things like specs, exit criteria and status meetings mean for a 100% proof of concept project?
– Flying in the blue sky
Back at the Emerging technology conference I presented a quick and dirty makeover of several popular web 2.0 sites and UI idioms (See slides for my talk: data vs. design). The fun and much loved Del.icio.us was one and here’s a makeover recap.
Step 1. The popular page
Del.icio.us is a social bookmarking site, and the /popular page shows which bookmarks in the del.icio.us system are most popular – but the layout uses open flow, blue on pink text (eek), and sloppy columns which all contribute to making the page hard to scan.
Step 2. Make a grid
The most basic layout trick in the world is the grid – throw down some columns and check how the stuff in the design lines up. The more things that don’t line up, the more work people’s eyes have to do. In this first photo, look at how the del.icio.us design compares against a simple 3 column layout. Not well.
In the next screen I’ve marked every visual column that the existing layout creates – each one of these lines is a point in horizontal space people’s eyes are forced to track to each time they try to read the next line – that’s a lot of wasted energy (and time).
Step 3. First pass
As a first pass, I’ve aligned all text into 3 columns. I killed the blue on pink, switching to black. I’ve also trimmed all the extra text from the pink brick, trimming its size by half.
Step 4. Second pass
After 15 minutes of experimentation, I was able to pull the data down into two complete, easily scannable columns. I brough back slim color bricks, but forced them into three buckets (light pink = low, pink = medium, intense pink= high) as that’s enough to indicate how popular they are, but keeping them easily distinguishable (And yes, there are better color choices to go with blue/black but I’m lazy in no-frills makeovers).
Step 5. Side by side comparison
Here are the two designs side by side, original on left and my quick makeover on right. My makeover fits more data into the same space, is faster to scan, easier to read, and slightly more attractive. It’s both easier to scan titles and which items are most popular.
Summary
If you’re a data centric site, be fast, clean and lean.
Use a grid or basic columns to frame the layout, and speed user eye movement.
Trim extra text – especially if you’re repeating things every line.
Use colors to signify and speed understanding, grouping data together (high / medium / low) to speed comprehension.
(And yes I cheated in some screenshots as the examples don’t match perfectly – but you got the idea, didn’t you?)
What’s next?
Have a popular site you’d like me to throw some design mojo at? Name it.
And athough the post is a top ten list, it doesn’t list top ten lists among its suggestions, giving you a bonus 11th tip. How nice. And if you count the “..that work” ending, that’s #12. Lucky day.
Purely for entertainment purposes, here is a blog title I made based on applying all 12 suggestions to a single title:
The top ten surefire things everyone ought to know about how you can discover who else wants the secrets of little known quick methods that work for getting rid of something so you can be proud of yourself like a rock star.
One question that’s coming up in in writing the innovation book is this: when has an innovation taken away something from your life that you valued?
Dozens of tech-sector companies are stuck in this trap and have been for years. They have manager to programmer ratios of 15 to 1, bad user experiences (a common result of different programmers designing things differently) and consensus driven decision making models that squander programmer brilliance.
It’s been months since I’ve commented on 
The history of innovation has many crazy tales – the patent office is involved in many. In 1836 the first U.S. patent office burned to the ground: despite all the great ideas in the building, they didn’t get around to fireproofing the building itself (An ivory tower lesson if ever there was one).
