Category Archives: innovation

Posted on
by

This was a great talk by Kathy Sierra this year at SXSW 2009.

She spoke about how to achieve breakthroughs. Basically, when it came to improvement, whether that was personal improvement, product improvement, or company improvement, there is a “big f***ing wall” that stands between you and your goal. At a certain point, incremental  movement will not suffice to get you through the wall.
She spoke about certain kinds of goals. For example, to become an expert, you first have to get through a certain “suck” threshold. But then you are in the land of mediocracy. Experts are the people who just keep on pushing and pushing to improve. She cited a book or study showing that it takes 10,000 hours to become an expert. (Sorry, I didn’t get the citation. If anyone knows, please post a comment.) But not everyone has 10,000 hours – so how can they achieve it in vastly fewer, like say, 1,000 hours.
Here are her roughly 15 ideas for achieving breakthroughs:
  1. Play the Superhero Game. Imagine you had to pick a superpower: either flight or invisibility. Which would you pick, and why? What argument could you make for the other superpower? Now that you are thinking about superpowers, imagine giving a superpower to your users. What superpower would you pick, and what would be a credible case for that super power. She had some good examples: “Photoshop Channels Guy”: this is a credible superpower, because once you have mastered channels, you can do powerful things in Photoshop. “Pivot Table Man” is the equivalent for spreadsheet. But some bad examples are: “Spelling auto-correct man”: it’s just lame. And “Productivity Man” is good for you, but boring as brocolli.
  2. Play the Superset Game. Don’t just take on your competitor. What is the bigger, cooler thing that you can take on? If you blog about your company, that’s not the coolest thing from the perspective of your reader. Imagine you are a cooking appliance company: your readers are passionate about cooking, not the manufacture of cooking appliances.
  3. Deliberate practice. You can use several techniques to really practice, and achieve expertise in <>
  4. Make the right things easy and the wrong things hard. Do you have treadmill equipment gathering cobwebs in the corner? It’s not in the corner because you don’t use it, you don’t use it because it’s in the corner. Take the couch and everthing you sit on out of the media room, and put in exercise balls and exercise equipment.
  5. Get better gear (and/or offer it to your customers). It’s more expensive because it is better. A touchscreen Wacom tablet is just way better than any alternative. A $4,000 horseback riding sadle offers immediate improvement in riding, even for a mediocre rider. Be on the lookout for difficulties justifying the expense: You want more monitors, but your boss things you’ll just be playing games.
  6. Ignore standard limitations. Challenge the assumptions. Don’t let the traditional limitations apply to you. 
  7. Jams. 16 hours over two days is way more effective than 16 hours over time months. Kathy cited several examples, including the Ad Lib Game Development Society: They develop a complete computer game over the course of a single weekend, and have to ship by Sunday night. Also, at the 24 hours film shootout, they plan, script, shoot, and edit a whole movie within 24 hours. Less talk, more do.
  8. Change your perspective. don’t make a better [X], make a better [user of X]. Kathy spoke about this earlier in the day as well. The example was an author who is writing a book on programming. If the focus is on writing a better book, they make emphasis more pages, more content, better quality printing. If the emphasis is on making the reader a better programmer, then you are forced to answer the question of what will make the reader a better programmer. 
  9. Play the movie game. What movie are your users in? Script out the whole movie. For example, if they are in “the hero’s journey”, then script out the call to action, refusal, entering a special world, allies and mentors, etc. As an example, what role you do play in your user’s lives? Who are their mentors and allies? Furhtermore, what movie do your users want to be in?
  10. Be Brave. Great ideas get killed by risk aversion. A fantastic idea encounters fear, which turns into the actual product. A concept car meets fear by management and turns into a production car. But love is good, and hate is good. Mediocrity is bad, and that’s what fear and playing safe gets you. 
  11. Revive the dead (idea) pool. The recreational horse industry is now a $40B annual industry in the United States, one hundred years after horses were obsolete.
  12. Play the EQ game. Within any industry, competitors differentiate from each other based on different dimensions. “A specializes in luxury, B in low-end, C, in the middle”. For the book industry, some of these sliders might be “topic depth”, “number of topics”, and “technical quality”. Incremental improvements come from moving the sliders. But breakthrough improvements come from adding new sliders or replacing old ones. For the book industry, these might be “meta-data”, “online access”, and “discussion forums”. These online sliders can be used to help go through the process.
  13. Be Amazed. Kathy shared this funny video by comedian Louis CK about remembering to be amazed.  
I know I missed a few keys points (Where did being funny, like the blog of unnecessary quotation marks fit in?), so if you have any comments, please leave them below.

Posted on
by

In an article on Web 2.0 adoption, Ann All cites a few pieces of evidence that Web 2.0 adoption is slowing or even falling into disfavor:

In my post about a slowdown in IT hiring, I cited an InfoWorld item that quotes M. Victor Janulaitis, CEO at IT staffing research company Janco Associates, as saying that the sluggish economy has halted Web 2.0 investments. Demand for Web 2.0 technologies has “atrophied,” says Janulaitis, after “a slight increase in demand” earlier this year.
Indeed, Web 2.0 deployments likely fall under the discretionary spending column at most companies, and thus are prone to elimination as tech execs look to cut IT spending. As a Goldman Sachs analyst put it, execs are “searching for solutions with a high and fast ROI,” a criteria mostly lacking in Web 2.0 technologies.

Ann also writes:

But check out the Robert Half numbers of CIOs taking a pass on technologies: tagging software (67 percent), blogs (72 percent),wikis (74 percent) and virtual worlds (84 percent). ZDNet’s Dignan expresses surprise at the lack of love for wikis and speculates that maybe they are popular among in-the-trenches types such as software developers and project managers but not among CIOs.

I think that Ann and the sources she quotes are missing the elephant in the room: employees are adopting these technologies whether the CIO wants them to or not. Professional blogs and professional social networking tools are still on the rise, and don’t depend on internal IT resources. Likewise, wikis and community tools are available from hosted providers, usually for free. All it takes is one enterprising person from marketing to start a customer community, or an enterprising developer to start a wiki. 

When social media tools are hosted internally, I’ve witnessed over and over that they start as skunk works projects, below the radar of official IT. So the CIO may not endorse Web 2.0 tools, but company employees will adopting them both inside and outside the company firewall. In fact, the biggest risk that a CIO may cause by not adopting Web 2.0 technology in an appropriate and timely fashion is the exodus of implicit and explicit company confidential information outside the firewall.
And regardless of what the company may officially do, and what employees may unofficially do, of course a company’s customers can and will adopt Web 2.0 technology on their own.

Posted on
by

I posted about the nine practices of high performance teams. None of the practices are particularly difficult, so why do so many companies seem to stifle the kinds of productive behaviors they want?

I believe that corporate environments suffer from productivity killing practices that seem minor when viewed individually, but which have a multiplicative effect when combined. When I say a multiplicative effect, I mean that if you have three items, each of which halve productivity, the result is 0.5*0.5*0.5 or just 12.5% of the original productivity. What this means is that if you have many items which adversely impact productivity, the multiplicative effect is really what matters most, not the individual effect of each item. For example, if you have 5 items, each of which reduces productivity by a relatively small 20%, the cumulative, multiplicative effect is still quite large: 0.8*0.8*0.8*0.8*0.8 = 32% productivity.

Given just how important productivity is to the health of a business, it is sad just how many productivity killers corporate environments suffer from. Here’s the list:

  1. Failing to identify and take action on most important objectives: (50%)
  2. Excessive effort and time to get commitment to needed projects: Classic under-capitalization (50%)
  3. Failing to capitalize on expertise, interest, and capabilities that exist: (25%)
  4. Failure to rapidly iterate: having long cycles of planning, production and then release. (25%)
  5. Information silos: Being unable to easily find the right people, information, documentation to get done what you need. (10%)
  6. Cancelled projects due to overcommitment of resources: (10%)

Posted on
by

There’s a tremendous amount that’s been written about high performance teams. I’ve studied high performance teams as part of my graduate work, read about them as part of my professional career, and had several experiences with high performance teams in the workplace. Reading and studying about high performance teams has the unfortunate effect of making them seem quite complicated, when in reality, there are just a few practices that go a long way towards creating a high performance team.

My experiences have been in the realm of software development, but these practices should apply to other areas as well.

  1. End the day with a debrief meeting: At the end of your workday, take the time to meet and recap what’s happened. Who has accomplished what? Who ran into problems? What were those problems and what can be done with them? The end of the day is typically a time when everyone’s brain is tired, so it usually isn’t a time of great creativity. But it is a time of getting it all out of the table. Part of getting it out on the table is to share problems and successes to that people can sleep on those ideas.
  2. Start the day with a planning meeting: After a good night’s sleep, and with a clear understanding of where everyone is, the morning planning meeting serves to plan out the events of the day. Who will work on what? What coordination will be needed? Who will pair program together? What novel solutions to current problems came to people while they were in the shower? What are the critical few objectives that should be accomplished today? The morning planning meeting is typically upbeat, high energy, and quick: 20 minutes to 40 minutes (max) will serve to plan out the day in great detail.
  3. Start the week with a high level planning meeting, and end the week with a high level debrief: Just as the daily meetings serve to highlight the critical objectives for the day and develop a plan to meet those objectives, the weekly meeting serves the same function, but at a macro level. What are the business objectives to work on this week? What is the plan to accomplish those objectives? What problems meeting business objectives did you run into? This can take as little as an hour on Monday morning if objectives and a path forward are very clear, and as much as four hours if they are not. (But this is time well spent, as it ensures that the rest of the week is highly productive.)
  4. Have a simple, shared system of documentation: It might be a wiki, a Google group, a whiteboard, or a Sharepoint (make sign to ward off evil empire), but almost every high performance team will have a simple system of documentation that ensures the most important information is easily accessible and up to date. This will typically encompass at least the business objectives, the daily plan, the build environment, the architecture plan, and integration points documentation. Too much documentation is overwhelming and a time sink, too little documentation and people are repeatedly searching for the same stuff or wandering aimlessly. Personally, I highly favor wikis if you can get one in your environment. Tips for wiki adoption.
  5. Create a culture of personal responsibility: In a high performance team, everyone should feel comfortable doing whatever is necessary for the success of the team regardless of what the official scope of their job is. In fact, they should feel not only empowered to do whatever is necessary, but ethically compelled to do whatever is necessary. One day, the most helpful thing I might do is stay heads down developing my code. Another day, the most helpful thing I might do is go get lunch or coffee so that someone else can stay heads their developing their code. One day I might be developing a high level architecture, and another day I might be hand-editing every row of a 3,000 row Excel spreadsheet. (Yes, I did that.) The point is that regardless of skills, code ownership, or perceived importance, what is important on any given day and on any given part of the project varies, and flexibly adapting to this is critically important.
  6. Be social: The team that laughs together and plays together shares a bond that goes beyond mere workplace acquaintance. Those weekly and daily meetings are a time for people to bring all of who they are to the table. Getting lunch together is a great way to be social and create pockets of more innovation: what work lunch doesn’t at some point come back around to work topics? One of my teams had a practice of taking off every other Friday during the winter to go snowboarding. It was our motivation to kick butt Monday through Thursday so that we could go enjoy a day of snowboarding with a clear conscience. (Oh, and what did we spend hours talking about while snowboarding? Work, of course.) An actual conversation with our manager when we decided to do this:
    Us to Manager: “We’re all going to take Fridays off to go snowboarding.”
    Manager to Us: “You can’t all go snowboarding on Fridays, there will be nobody here to handle things.”
    Us To Manager: “You’ll be here to handle things.”
  7. Optimize decisions for fun: Obviously snowboarding, team lunches, and coffee together are both social and fun. But other decisions that take place can also incorporate fun into them. Silly as it may seem, but choosing the operating system, programming language, development environment, build tools, database engine are all technical decisions that have implications for how interesting and fun team members find their work to be. Sadly, in large companies these are decisions that are most often made either on the basis of perceived technical merit, or more often, based on existing corporate strategic alliances. A team that is excited to use a new language or development tool can, as a function of that excitement and passion, be ten times more productive than they would otherwise. Whereas, the technical differences in productivity are often quite small. So optimize those decisions for fun and interest, and you’ll get more productive and passionate teams.
  8. Avoid negativity: Few things can be more destructive to a team than negativity. Complaining and trying to place blame are huge time and energy sinks. If there is an issue, then the focus should be on fixing the issue. Not detailing the issue out, not trying to figure out who caused the issue, not belabouring the pain that it has caused. Only on trying to figure out what to about it. In fact, if you have a chronic complainer on your team, one of the best things to stop the complaining is simply to ask the person, when they bring a complaint to you, “What are you going to do about it?”
  9. Have at least one person who likes to work nights and weekends: Every high performance team I’ve been a part of has had one person who works nights and weekends. They just can’t seem to help themselves from staying up half the night to work. This isn’t a choice I would make myself, and I wouldn’t ask people to make that kind of a sacrifice. But if you just happen to end up with one person like this on your team, it will make all the difference. While everyone else is resting and getting their creative juices refilled, that one night person will have: fixed that build problem, solved the defect no one could find, figured out how to use the new GUI library, optimized the performance of the database, found a cool new IDE, and brought the build documentation up to date. And the next day everyone will “oooh” and “aaah” over what they accomplished. Be very nice to this person and buy them lots of coffee and chocolate.

Posted on
by
In 2000, I was part of a team developing web applications. We favored open source software for the foundation of our web services, such as Apache and Linux, and widely used software such as BEA Weblogic, and the Java programming language.
Using these tools, when we ran into a problem, we could count on being able to Google the problem, and find an answer – usually within a few minutes. Sometimes the solution would be posted by another user like us who encountered the same problem and worked out a solution. On other occasions, the solution would be posted by someone from Weblogic or Apache, who would be monitoring public forums for problems posed by users, and would answer with the expertise of someone intimately familiar with the product. On the rare occasion when we couldn’t find an answer, one of us might post our problem to a relevant Usenet newsgroup. Within a few hours, we’d get a helpful response from someone else who ran into the same problem and figured out how to solve it.
Our team worked at web speeds, we were passionate and dedicated, and we loved our work. Being “in the flow” was a big part of it: you get going, you are productive, you feel productive, and it makes you even more productive.
Then, in 2001, for reasons quite unconnected to anything our little team was doing, our company forced all Java web application teams to move to a single proprietary J2EE platform. The support model changed to a typical enterprise support model. We funneled our support requests to a single support contact, they funneled our requests to the support team for the priorietary software, then the requests would get funneled to the right support or technical experience.
The pace of everything slowed dramatically. The questions we used to research and answer ourselves via a simple Google search in five minutes now took at least 24 hours to turn around. And the more technical stuff that we use to get answered via a Usenet newsgroup or web forum now could take a week or more before we got a response.
Meanwhile, productive work would grind to a halt. For engineers who were used to working on Internet time, and getting an answer commonly within 10 minutes, and in the worst case within several hours, this was the ultimate frustration. The team grew dissatisfied, productivity plummeted, and we were no longer “in the flow”. Even when their customer support finally did get around to answering our questions, no one else could benefit from it, because the problem and solution were never posted in a public forum.
The worst part of all this is that the “support” of the proprietary J2EE software was considered one of the benefits of using it by the management folks who made the decision to use it. But free, open support is far superior to paid, closed support. This is something that open source developers and users have known for years, and it is a big part of the reason why open source software has such a passionate and loyal following.
There are several lessons to take from this story:
  1. Knowledge capture and public sharing improves the support experience and decreases the work required by paid support staff.
  2. Customers inherently have a customer perspective on issues, which paid support staff lack.
  3. For a popular product, there are likely to be more customers available for helping other customers than there are support agents available.
  4. In most cases, the speed and access advantages associated with abundant information on the web far outweigh any minor benefit to be gained from one on one paid support.