Management lessons from ultimate frisbee
Posted: May 19, 2008 at 7:59 am in management, ultimate ~ Permalink

As those of you who follow my other feeds know, I’ve taken up playing ultimate frisbee again with the Manhattan Ultimate league. While the main benefit is getting back into shape after two years of class-induced neglect, I also really enjoy playing ultimate because of the philosophy baked into the rules of the game.

If you’re not familiar with ultimate, the rules are pretty simple. On a field with two end zones, two teams of seven line up, one on each end line. One team starts the point by throwing the disc to the other. The disc can only be advanced by throwing to a teammate - once you catch the disc, you can’t continue running, and must hold a pivot foot stationary. If a pass is not completed, the other team takes over going the other way. Score by catching a pass in the end zone.

These rules make ultimate a truly team-oriented sport. An individual player can’t take over the game single-handedly, the way they do in basketball or football or baseball, because every pass involves two players. The way for an individual player to excel is to make their teammates better. When they don’t have the disc, they can help their teammates by getting wide open, or by rescuing poorly thrown passes with great catches. Once they catch the disc, their teammates don’t have to get as open because a good thrower will put it right into their hands away from the defender.

The best teams use everybody on the field, creating spacing with different people going in different directions. For instance, because I’m tall and relatively fast, I often run downfield routes, where my teammates can just put the disc up high and expect me to either out-run or out-jump my defender. Other teammates who have more agility dart in and out with underneath routes. Players who have good throwing skills hang back to give their teammates an easy throw when they get in trouble. You need a good mix of skills on the field working together to achieve success.

What’s interesting to me is the management lessons that can be learned from ultimate frisbee. Different sports lend themselves to different management practices. Football is a typical hierarchy, with a coach and a quarterback leading the troops in precision maneuvers. Basketball is like a design firm, with individual superstars able to freelance their way to excellence. I think ultimate frisbee is a great model for understanding the distributed management style necessary for knowledge workers, where everybody has their own expertise to contribute.

Like the good ultimate player, good managers of knowledge workers make their employees and coworkers look good by setting things up to be easy for them. They know their coworkers’ strengths and weaknesses and find ways to accentuate the strengths and minimize the weaknesses (like me running deep in ultimate where I can use my height and speed, without worrying as much about my weaker throwing skills). They don’t need to take credit for themselves, because they know that the team being more successful is credit enough. Returning to my current non-zero-sum theme, they realize that “growing the pie” of success will reward them far more than trying to grab a bigger share of credit for the existing “pie”.

Bad managers, on the other hand, are playing the zero-sum game, trying to make themselves look good at the expense of their employees. They are the ones who take personal credit for anything their group does, but makes sure to blame mistakes on their employees. The ultimate frisbee equivalent would be prima donnas who, while having superior skills, yell at their teammates about making mistakes, and making them miserable. Soon enough, their teammates stop caring and stop running as hard, and the prima donna has created a self-fulfilling prophecy of bad teammates.

Another interesting parallel between ultimate and management is that it takes time for teams to jell. While it’s fun to play pickup games in ultimate where you choose sides and go, teams improve immeasurably by playing together and learning each other’s tendencies. You learn which routes people like to run, which throws your teammates have (which influences which routes you run when they have the disc), how to cover for each other on defense, etc. And each team and each combination of players is different - in this league, our team has actually been suffering from having too many subs for each game, as the team can’t quite settle into a rhythm because each point has a different combination of players.

A good manager needs the same sort of time to make their team most efficient. It takes time to learn how different team members think, how best to work with them and persuade them. Building a team is a long process, as each person needs to develop trust and respect for their teammates, and find a role for themselves within the team, a place where they can specialize in a way that plays to their strengths. Following Katzenbach’s formula, they must also develop a common group purpose and accountability, such that they believe in the team and will do what is necessary to make the team successful, rather than looking out for themselves in a zero-sum way.

As an aside, I just re-read the Katzenbach post and realized that good ultimate frisbee teams match up perfectly with his criteria for teams: small number (7 on the field), complementary skills (handlers, mids, and deeps), common purpose and performance goals (scoring and winning), common approach (teams that are successful work together in a coherent fashion), and mutual accountability (it’s almost funny how many people on an ultimate team try to take the blame after a close loss - everybody focuses on the mistakes they made that cost the team a couple points).

I’m not saying all managers should go out and take up ultimate frisbee (okay, that’d actually be kind of cool), but I did find it interesting that this mindset of non-zero-sum thinking about management had me seeing the same lessons so clearly on the ultimate frisbee field. This may just be another example of me taking a single perspective and seeing it everywhere, but I think that ultimate frisbee may be a good exemplar for truly distributed management techniques, the sort that would be appropriate in a knowledge worker economy.

~ 2 Comments ~

The Art of Innovation, by Tom Kelley
Posted: May 17, 2008 at 4:23 pm in management, nonfiction ~ Permalink

Amazon link

I’ve heard great things about Ideo, often called the leading product design firm in the world. Last year, in my “Managing Innovation” class, we watched a Nightline special called the Deep Dive, where Nightline gave Ideo one week to re-design the shopping cart. It was a great look inside the company’s innovation process, and it left me wanting to learn more. So I bought The Art of Innovation, a book describing that process by one of their general managers, and finally got a chance to read it last week once classes were done.

The book starts their redesign of the shopping cart for the Nightline special as an illustration of their innovation process:

  1. Observation: Go to local supermarkets to see how people were using shopping carts and the problems shoppers faced. The book calls this “a form of instant anthropology”. From this, extract the goals of the re-design (in this case, making it more child-friendly, safer, and more efficient)
  2. Brainstorming: Generate hundreds of ideas and sketches, from the silly to the sublime. After brainstorming is done, winnow those ideas down to a few promising candidates.
  3. Prototyping: Build mock-ups to see how those candidates will work and feel.
  4. Iteration: Evaluate and refine the prototypes, using the best ideas and what you have learned to generate the next round of prototypes.
  5. Implementation: Take the best of the prototypes and prepare it for commercialization.

I’m a big fan of this process, as might be expected since I advocate rapid prototyping whenever possible. The knowledge gained by letting users interact with prototypes lets you hone in on what’s important and what’s not.

The rest of the book is a collection of a whole variety of techniques that Ideo uses to spur innovative thinking, and how it has created a culture conducive to such thinking. So there are chapters on each of the steps above (observation, brainstorming, prototyping, etc.), but there are other chapters on culture concepts like “Expect the Unexpected”, “Barrier Jumping”, and “Coloring Outside the Lines”.

One of my favorite ideas of the book was to create the advertisement before you create the product. Take the time to make a print ad or a 30-second video that extols the benefits of the product you are creating. This focuses the team on what they are trying to accomplish with the design. I can think of a few projects I’ve been on where asking these sorts of questions at the beginning would have saved us lots of time and effort later.

I think the book may actually work better as a reference than as a narrative. While it was well-written and easy to read, the density of ideas was overwhelming - there were too many good ideas to keep track of, so I only remember a few. I’ll definitely keep this book on my bookshelf at work and flip through it whenever I’m feeling stuck and need some inspiration. I highly recommend it.


what’s important and what’s not: One favorite story I have from my days at Signature was when our instrument prototype was generating tons of data that nobody knew how to analyze. The “real” software team came and asked the biologists what software they needed to do the analysis, and the biologists told them that since they didn’t know what the data meant, they’d need to be able to graph every axis against every other axis and do all sorts of other crazy mathematical analysis. The programmers went off to go design and implement a solution to do what the biologists had asked, which was going to take months since they had asked for so much.

I knew the biologists better, though, and said “Here’s a tool to dump the data to Excel, where you can graph it yourself and play with the data directly”. They started playing around, figured out the two or three critical pieces of data for what they were observing, and then I built them an analysis tool that graphed only those pieces of data. We had a working solution before the “real” software team had even completed their design of the singing, dancing, do-everything software that had been requested in their naive requirements gathering process.

~ 0 Comments ~

Defending generalists
Posted: May 14, 2008 at 7:00 am in generalist, management ~ Permalink

Seth Godin is one of my favorite writers, but I have to take exception to his latest post called We specialize in everything:

When choice is limited, I want a generalist. When selection is difficult, a jack of all trades is just fine.

But whenever possible, please bring me a brilliant specialist.

If you’re shaking your head in agreement with this obvious point, then the question is: tell me again why you’re a generalist?

He later added a coda suggesting the idea of specializing in being a generalist, but sticks to his guns that “My point is that you never call on these people [generalists] when there’s a better specialist available.”

As somebody who has branded himself as an unrepentant generalist, I have to respond from my admittedly biased viewpoint.

I actually agree to some extent with Godin’s point. As The Only Sustainable Edge points out, specialization drives greater achievement in a given field, as monomaniacs achieve a level of focus that dabblers can not. Specialization also implies that only those who are truly passionate about a field will commit to the field and become the best in the world at what they do.

I think the flaw in Godin’s argument is revealed in his second paragraph: “If I need an animator, I can find the world’s best animator.” Here’s the subtle point: how do you know that you need an animator? That seems like a trivial question, but it gets to the heart of why generalists matter. Once you have defined the problem, and scoped it, and figured out exactly what skill set you need to solve your problem, then of course you’d hire the best person you can find with that skill set.

Specialists only know how to attack problems in one way - that’s part of specializing. To be the best at what they do, they have to ignore other ways of approaching the world and shut out other perspectives. A specialist is the proverbial hammer treating every problem as a nail.

So when you have a problem, how do you determine which specialist to use? Each specialist will tell you their skill set is the right one to solve the problem, because if they didn’t believe in the power of their specialization, they wouldn’t be a specialist. You need a generalist, somebody who can evaluate the problem from multiple perspectives. and who can ensure that the specialists picked will fix the real problem rather than a symptom.

The other absolutely vital role for generalists is in communication. Specialists see the world from their perspective, so for them to communicate with other specialists requires a generalist who knows enough of each specialization and its jargon to be able to translate between the worlds. This is a role that I have been very successful in filling at all of my different companies, especially on the interdisciplinary team of CellKey, where we had physicists, biologists, engineers and software developers all working together on the same product. Without a generalist, you have specialists talking past each other, and their effort is wasted because you can’t get them all working together and speaking the same language.

Maybe this is what Godin meant when he suggested one could specialize as a generalist, but I think that his post overestimates the value of skill alone, and underestimates the social difficulties of selecting and aligning specialists. The problems of language alignment and of picking the right team of specialists are where generalists provide value in a way that specialists can’t, precisely because they’re specialists.

~ 6 Comments ~

Executive Master’s in Technology Management at Columbia
Posted: May 7, 2008 at 7:15 am in management, nyc ~ Permalink

As I’m finishing up my master’s program at Columbia, it’s time to reflect back on my experiences of the past two years. I wrote up an email to Frank Giardini from the comments on yesterday’s post, who asked about comparing the program to getting an MBA, and realized I might as well post my thoughts in public.

I have not pursued an MBA myself, so my perspective is admittedly biased. I’m also biased by the book Managers not MBAs, which points out how artificial the skills learned in an MBA program are when compared to the skills needed to be a manager. That being said, let me extol the benefits of the Technology Management program.

The Technology Management program has a very specific goal - it is designed to give experienced technologists the business tools they need in order to take their technology domain expertise and become successful technology executives. So we took classes in corporate finance, innovation, technology and the law, operations, knowledge management, marketing, etc. These are all standard classes that might be taken in an MBA program, but each class is taught with a technology focus so the examples and the assignments involve challenges relating the subject to a technology organization.

It’s designed for experienced professionals - most students in the program have 8-15 years experience, so the class discussions are grounded in that experience. Instead of theoretical musings, most discussions come back to “When I was in that situation, this is what I did”, which is far more useful in my opinion. For instance, in the innovation class, when we were discussing the phase-gate method of
managing innovation, I was able to offer my perceptions from having gone through a project run with that method.

The other students are definitely a highlight of the program. I have really enjoyed working with and learning from my classmates over the past two years. I also look forward to continuing to benefit from their knowledge and expertise in the future, as we plan to stay in contact via our Google Group and other social networking tools like LinkedIn.

The centerpiece class of the program, in my opinion, is Alan Morley’s class, “Behavioral Challenges in Technology Management”, or Becoming a CIO, as I like to call it. The class covers the financial and strategic tools necessary to become an effective executive and teaches how to synthesize those tools into a coherent plan. See my linked post for more details.

The master’s project itself is developing a business plan and pitch for a technology venture. Some people do an internal project at their company, while others pursue an idea for a startup. At the end of each term, each student has to present their master’s project to a panel of three mentors. They have ten minutes to give their project pitch with another ten minutes to take questions, and they are graded on whether the panel would fund the project based on that presentation. It’s a terrifying but educational experience, as these presentations (whether to boards of directors or venture/angel boards) are what executives face when getting projects funded.

The program also finds each student an industry mentor as a guide, somebody who offers feedback on the project from the perspective of somebody who is already a successful executive. My mentor was Jon Williams, who was CTO of Kaplan Test, and is now the CTO of iVillage. Other mentors are similarly distinguished, generally CIOs and CTOs from different industries in New York. I am extremely fortunate to have worked with Jon over the past two years, as he has been unstinting in sharing his advice and knowledge with me.

I highly recommend the Technology Management program, and think I learned more from it than I would have from an equivalent MBA program. It’s not right for everybody as it definitely has a technology focus, and may be a little light on general management techniques. But it succeeded in giving me new perspectives and new ways of looking at the world, which can only help me as I continue to move up in the management hierarchy.

~ 3 Comments ~

The Wisdom of Teams, by Jon Katzenbach and Douglas Smith
Posted: March 19, 2008 at 8:59 pm in management, nonfiction ~ Permalink

Amazon link

I love being part of teams. When I’m on a good team, I work harder, I get more done, and I enjoy the activity more. My biggest career achievement thus far was achieved as part of a tight interdisciplinary team. And yet I’ve often been part of teams that never jell, and are ultimately more frustrating than inspiring. What are the qualities that make a team work, and what can prevent good teams from forming? That’s what Katzenbach (whose work I previously enjoyed in Real Change Leaders) and Smith investigate in The Wisdom of Teams.

The book is filled with inspiring stories of teams that came together under dire circumstances and achieved amazing things. Katzenbach and Smith use these stories as a way of organizing their observations about how to create high-performance teams, from details of how to get people to exchange an individual focus for a team focus, to the characteristics of good team leaders, to how to get a team unstuck from obstacles. But let’s start with determining what a team is.

The authors define a team as “a small number of people with complementary skills who are committed to a common purpose, performance goals, and approach for which they hold themselves mutually accountable.” These are the key components to creating what they call a “real” team, as opposed to a group of individuals who are working together. They studied teams in dozens of organizations and determined these were the common elements among the teams that were highly successful. So let’s take a closer look at these characteristics.

  • Small number - Smaller groups have fewer logistical issues with meeting often enough for them to form a real team. In a small group, each person’s contributions and responsibilities are clear, whereas larger groups have a more difficult time organically determining those responsibilities.
  • Complementary skills - The members of the team have to have all of the necessary skills for them to achieve their goal. This requirement is somewhat less important than the others, as the authors observe that real teams give their members the incentive to go learn the skills they need for the team to be successful.
  • Common purpose - Everybody on the team has to believe in a common goal. Teams in the process formation often require a great deal of communication and negotiation to agree on their common goal, but until the overall purpose is clear, the team can not move forward.
  • Performance goals - The team must translate the common purpose into specific and measurable short-term goals. These goals give the team a chance to bind together in the pursuit of the goals, and create situations where all team members must contribute in order to achieve the goals. The goals also provide chances to celebrate small wins along the way towards the larger purpose.
  • Common approach - How does the team accomplish its goals? Who takes care of necessary logistics? The answers to these questions must be articulated for the team to continue moving towards its larger purpose, and not get mired in process and procedure.
  • Mutual accountability - This is the big one in my opinion. Teams have to feel accountable for their results as a team, not as a group of individuals. The idea that the team can fail but that an individual team member has succeeded is incompatible with a real team. But when a team really believes in its purpose and performance goals, it will often hold itself to standards far beyond what the organization is expecting of it.

The CellKey team which I enjoyed so much had all of the characteristics of a “real team”. We were 12 people, each with different skills, who were trying to build this completely new instrument. MDS Sciex gave us short-term performance goals in the form of “phase-gates” where we had to prove the viability of our research in order to continue moving forward with product development, but we held ourselves mutually accountable to a higher standard than Sciex did. And we achieved more than I would ever have thought possible when we originally started experimenting with cells in a back room at Signature.

One surprising lesson from this book is that an emphasis on teams does not create teams. No amount of team-building exercises or team initiatives will create teams… unless there is a focus on strong performance. The first “uncommonsense finding” in the prologue states that “Companies with strong performance standards seem to spawn more “real teams” than companies that promote teams per se”. When the stakes are high and things absolutely have to get done, the normal way of doing things breaks down as being too slow to change and react, so teams emerge as the method to reach those performance goals.

This observation reminds me of a paper on innovation that Scott Berkun recommended, which said that the way to spur innovation was to set a goal that was impossible to achieve by normal methods. People don’t think of new ways of doing things unless they are forced to by circumstance - why take the risk of trying something new when the old way will work? Similarly, organizations will cling to hierarchy and bureaucracy unless they absolutely have to achieve more than they have been; teams emerge to save the day.

I have to admit that I’m not entirely convinced that teams can be manufactured by applying the principles described in this book. As the Peopleware authors observe, team building is more about removing the obstacles to the team forming. I think that the observations of Katzenbach and Smith fall into a similar category - these are necessary but not sufficient conditions for a team to emerge. I suspect that you could do everything mentioned in this book and still not have a team form because of a personality conflict or some other detail.

I recommend the book as a good way to reflect on how high-performance teams can be cultivated within an organization. It’s also fun to read about teams that conquer all the obstacles before them - the epilogue tells the story of the “Killer Bees”, a basketball team in Bridgehampton that competes for the state championship every year despite a male student body of less than 20. But they work hard, they play as a team, and with an entire town rooting for them, they somehow overcome the odds to succeed. Stories like that continue to inspire long after the book is done (which isn’t surprising, since it fits all of the Made to Stick rules of being simple, unexpected, concrete, credible, emotional and in the form of a story) and only add to the enjoyment of the book. Thumbs up.


higher standard than Sciex: At the end of one phase-gate, we were asked to rate ourselves on how we were doing, and we all rated ourselves poorly. Our project manager was surprised by this as we had achieved all the goals for that particular phase-gate, but we were comparing ourselves to where we needed to be to launch the product. I discussed this before as a symptom of big vs. small companies, but it’s not surprising that it’s relevant to team building as teams are essential to small company performance.

~ 6 Comments ~

The 4-Hour Work Week, by Timothy Ferriss
Posted: February 12, 2008 at 10:24 pm in management, nonfiction ~ Permalink

Amazon link

The idea that we can work less and free up time to pursue our own dreams is highly attractive for most people and this book is a guidebook on how to do it. The methods that Ferriss recommends to achieve that lifestyle provoked both admiration and disgust from people I know who read it, and I’ll get more into that below. Let’s start with what Ferriss says before getting into reactions.

Ferriss recommends a four step process to changing your life, which he abbreviates DEAL:

  • Define - Figure out what you want to do. Honestly answer the question of what you would do if you had unlimited money and time. Travel the world? Learn a new language? Become a world-class expert in tango? Then sit down and figure out what it would take to actually do those dreams - Ferriss points out that it’s not as much as you think. For instance, he spent approximately $1500 a month to stay in Argentina and take private Spanish lessons and private tango lessons for several months before entering a tango competition - most of us spend more than that on our mortgages and/or rent. Don’t delay your dreams for a long-off retirement - start doing them today.
  • Eliminate - Eliminate anything from your life that doesn’t contribute to you achieving your dreams. Ruthlessly apply the Pareto Principle that 80% of the benefits come from 20% of the work. If you’re an entrepreneur, concentrate on your cash cow clients, and get rid of the small clients and the complainers. Deal with all the important things that you are avoiding doing by engaging in time-wasting activities like meetings and email and surfing the web. Get rid of stuff that you own that ties you down and keeps you from being mobile.
  • Automate - Start a business that you can reap the benefits of without being in the critical path (he calls these muses). He recommends selling things like training CDs or DVDs in an area where you are perceived as an expert (see below for how to achieve that). Hire a virtual assistant from India at $10/hour to do paperwork and answer email. Set up the purchasing system on the web so it automatically forwards orders to the warehouse which ships the materials. Take yourself out of the equation completely.
  • Liberate - Adopt a completely mobile lifestyle. Once the business has been automated, you should only need to check in once a week via email to make a few decisions. Only pick up the phone for a few hours each week, and train all your people that you are only reachable during that time - they’ll start to take initiative and solve problems themselves. At that point, you’re ready to embrace the lifestyle defined in step 1 and pursue your dreams.

The process makes sense. And I think it would work if followed. So why not follow it?

Ferriss is exploiting the existing system, something he takes great glee in doing. He brags about winning a world championship in a martial art by figuring out that weigh-ins were the day before, so he dropped 20 pounds of water weight for the weigh-in, rehydrated before the match, and took advantage of a loophole in the rules that awarded a TKO for pushing his opponents out of the ring by using his longer reach. For selling a training CD, he describes the process of becoming perceived as an expert:

  • Join the industry association of the field
  • Read the top three books in the field, as recommended by that association
  • Summarize the books into one page of talking points each
  • Contact a local university, and offer to give a talk, leveraging your association membership.
  • Contact two local companies, and offer to give a talk, leveraging your association membership and the fact that you’ve spoken at “University X”.
  • Put yourself on a media expert website and cite your association, the talk at “University X”, and talks at “Company X” and “Company Y”.
  • Total time to achieve media experthood in your chosen field: Four weeks

I admire his chutzpah and his ingenuity in figuring out how to live life on his terms, but I still don’t completely subscribe to his ideas.

Everything he’s doing is within the rules as they currently exist, but that just perpetuates the system. He’s playing the game as it’s given, rather than trying to improve the game (it reminds me of the difference between finite and infinite games). Maybe changing the system isn’t possible and the best we can do is to exploit it to our advantage. I’m not ready to do that yet, and I will continue trying to live my life “as if” things could be different. Maybe in a couple more years I’ll be ready to concede and I’ll just want to cash out as he did.

I still recommend reading the book, although I’d borrow it from a friend or the library. It’s a quick read, and it’s definitely a strong meme going around my generation, so it’s good to be able to participate in the conversation. There are several good lifestyle suggestions in the book, especially in clearly defining one’s own goals, and eliminating behaviors that are not contributing to achieving those goals (tasks that would be valuable in one’s professional life as well as one’s personal life). I need to commit to some more specific goals, and start hacking my way towards them, and we’ll see if the ideas from the book can help me with that.

~ 7 Comments ~

Learning from Rock Band
Posted: February 9, 2008 at 7:52 pm in management, people, socialsoftware ~ Permalink

Rock Band is a video game phenomenon. One enthusiast I know calls it the greatest in-person multiplayer game ever. Over the holidays, I played it three times in a week at three different apartments, and played it some more at our company retreat last month. So what makes Rock Band a great game?

First of all, it’s just fun. Almost everybody wants to pretend they’re a rock star, so being able to rock out with friends is a great experience. Everybody gets a prop (guitar, bass, drum set or microphone for vocals) and if you play the game on a big screen and hooked up to a stereo, it’s like starring in your own rock concert. They’ve done a good job of selecting songs with catchy tunes that most people know (who of my generation doesn’t enjoy rocking out to Bon Jovi?). But I think the design of the game is exemplary in other ways.

Rock Band enables people of different skill levels to enjoy playing with each other. This sounds minor, but imagine the experience of a novice playing a first-person shooter game such as Quake 3 with somebody that’s an expert. The expert kills the novice repeatedly, and it’s not fun for either player as the expert is bored and the novice gets no chance to improve. Compare that to Rock Band, where one player can select Easy and the other Expert, and both will be presented with game material challenging for their skill level. Everybody has fun, and when they make it through a song, they can celebrate together.

Rock Band also does a great job of continually challenging players. When playing Rock Band for the first time, you choose the Easy skill level of an easy song. As you get more comfortable, you can try harder songs at the Easy level. Once you can master the hardest songs on Easy, you realize that you can handle the easier songs at the Medium level, and start working your way through the songs at that skill level. The game offers a well-designed continuum of challenges so that there is always a next step just out of reach, so that if you try that song one more time, you might get through it. This continuous incremental achievement is gratifying and I think it is why many of my friends are so addicted to the game.

The game keeps players working towards improvement by offering excellent feedback. At the end of each song, each player is given a percentage grade showing how well they did at matching the patterns given to them. The grading is dependent on the skill level; the game is much more forgiving of being a split second off (or of being out of tune when singing) at the Easy level than at the Expert level. With the numerical grade, one can chart one’s improvement even when playing the same song repeatedly, and when combined with the range of game material discussed in the last paragraph, that offers players the challenge of always improving themselves.

The one area in which Rock Band could improve is in offering direct competition with others. While we were on the company retreat, we split up into two teams of four with roughly comparable skill levels, and took turns playing the same song to compare our scores (although we spent all of dinner arguing over what the proper way to compare scores would be). This turned out to be remarkably fun and each of us probably played our best when we were doing our battle of the bands because we were so focused. I imagine something like this is possible with XBox Live, but I’ll defer to others who would know better.

The interesting thing to me is that all of the design choices that make Rock Band excellent can be applied to management.

  • Having fun is important. It may be difficult to quantify, but I believe that employees that are happy at work are more productive.
  • People want to feel like they’re contributing regardless of their skill level - they don’t want to be on a team where the expert does everything and everybody else watches.
  • Jobs should be designed so that they are always stretching employees’ capabilities. When they master one set of skills, introduce some new element that challenges them to continue learning.
  • Consistent feedback is vital to employee satisfaction and improvement. When they know how they are doing, they have a target which they can aim to exceed moving forward.
  • Competition is good. It gets people to push themselves harder than they would otherwise, and achieve results they would not achieve by themselves.

P.S. I’ve been meaning to write this post for a month, but life has been crazy. This is only the second weekend I’ve spent in New York since mid-December, and the other one was when I had class from 9 to 5 on Saturday and six hours of reading to do on Sunday. I have several posts I want to write, including catching up on my backlog of book reviews, so please nudge me if I don’t start writing more often.

~ 1 Comment ~

Randy Pausch lecture and feedback
Posted: January 23, 2008 at 7:30 am in links, management ~ Permalink

Wax Banks pointed me at this lecture which you can see on Google Video by a CMU professor named Randy Pausch.

Dr. Pausch has lived an incredible life, and this lecture is about achieving your childhood dreams - he talks about his dreams, from being in zero gravity to being an Imagineer for Disney to being Captain Kirk, and how he achieved them (he didn’t get to be Captain Kirk, but he did land a walk-on role in the new Star Trek movie). He goes on to talk about helping other people achieve their dreams, and the satisfaction that comes from that. It’s a great lecture - I meant to only watch the beginning, but I ended up staying up late and watching the entire hour and a half.

One thought-provoking moment from early in the lecture is his experience as a high school football player. He had a bad day, and the coach was yelling at him throughout the practice. At the end of practice, an assistant coach sidled up to him and said “Coach was riding you pretty hard today”, and he glumly said “Yeah.” The assistant coach said, “That’s a good thing. When you’re screwing up and nobody’s saying anything to you any more, that means they gave up.”

I love that one line summary of the importance of criticism and feedback. I’ve written about the importance of feedback and the feedback sessions. I’ve also written about the value of harshness where I say “I want to be criticized. I want to find out what I’m doing wrong. How am I going to get better otherwise?” And I agree with that unnamed assistant coach - if you’re not getting feedback, that means that people have given up on you.

That sentiment also reminds me of my time at Signature. Signature BioScience had many young folks in their first or second jobs, and we were complaining about everything, sometimes legitimately and sometimes not. One of the older and wiser engineers told me at one point “You don’t understand this now, but it’s a good thing when people are complaining. When they stop complaining, that means they no longer care.” Same sentiment from the opposite direction - if I’m a manager and I’m not hearing anything from my employees, they are either still complaining and I don’t know about it (bad) or they have mentally checked out of the company and are looking for other jobs (worse). Complaining can be a sign of a healthy company where debates are happening between people passionate about trying to make the company successful.

There were lots of other great moments in the lecture, like when he described brick walls as an obstacle to help one figure out how to get past them. It was inspiring to hear about all of his accomplishments and I’ll have to see if I can figure out what my dreams are and how to move forward on achieving those dreams.

~ 1 Comment ~

Finishing a product
Posted: January 19, 2008 at 10:32 am in management, tech ~ Permalink

I used to think that the hard part of creating a product was developing the technology. That’s not a surprising attitude for an MIT graduate, steeped in the lore of plucky inventor heroes who toil in their labs for years before making scientific breakthroughs that bestow great benefits on mankind. I scorned all that “MBA crap” of marketing and sales and believed that the best technical solution was the one that would win (”If you build it, they will come”). I worked as a consultant and as a research prototype developer, and in both cases, once I delivered software that worked for that one person in that one situation, I was done. Getting the technology right was my only task so I thought it was the only thing that mattered.

I have since been involved in launching a couple products into the world (CellKey and the latest version of FogBugz) and have realized that getting the technology right is only a small part of releasing a product. Once the technology is “done”, finishing the product involves:

  • Making sure that customers want to buy the product (”Did we build the right thing?”)
  • Testing it in all possible situations that might be encountered in the world (”Wait, somebody’s trying to run FogBugz on a linux distro and MySql version that are both four years out of date?”)
  • Fixing all the bugs that arise in such unanticipated field environments.
  • Making sure that customers can actually buy the product (”Oops, we need to re-design the website“).
  • Publicizing the product so that potential customers who might benefit from the product know about it and proving to those potential customers that your solution solves their problem. This was a particular issue with CellKey since it was a new technology so nobody had any idea how to incorporate it into their process. It comes up with FogBugz as well; despite the name, it’s a full-featured project management system, but doesn’t work like Microsoft Project, so customers aren’t quite sure what to make of it.

To do all of these other tasks, companies have to create what Joel Spolsky calls the development abstraction layer. As a technologist at small companies doing mostly consulting-type work, I didn’t really understand what most people did at larger companies. But those people are doing all of the support work necessary for the development abstraction layer, from QA to support to sales and marketing.

The first priority is making sure that the technologists build something of value to the customer. Technologists have an unfortunate tendency to believe that everybody else values the same things that they do. Back in 1996, I couldn’t understand why anybody wouldn’t run Linux on their home computer as I did, because it was clearly more stable than Windows, and had far more power via the command line than the Macintosh froofy graphical interface. It took me years of working directly with end-users to learn that powerful software was not defined by technology metrics, but by whether the software enabled the end-user to do what they want. Delivering a product means understanding the customer well enough to anticipate their needs and designing a solution to meet or exceed those needs.

Once a potential product is developed, it needs to be released. Big successful companies are built around having the infrastructure and machinery necessary to consistently release products. MDS Sciex had “phase gates” for the CellKey project every few months, and I didn’t understand the point of the gates until a more experienced colleague explained to me that each gate answered one of the questions from the development abstraction layer above. Early gates were about confirming the market need and that we were building something that customers would want, while later gates confirmed that we had built something that would work consistently in the field. A good company works to answer those questions about a potential product, so that once a new technology is developed, the company has the resources in place to successfully bring it to market.

Getting this infrastructure right is easier said than done. Sciex had a process in place, but it was too rigid, so we had culture clashes trying to adapt their process to the completely new product that CellKey was for them. Startups have not had the time to develop a process, so everything is done haphazardly and releases can drag on for months as people say “Oops, we forgot to do the documentation” and “Oops, we need to fix the product in this environment”. Unfortunately, customers don’t really want to wait while a company gets all these details right, so they get frustrated watching the company screw up. I’m not sure there’s a real model for getting all aspects of this infrastructure right, although a company like GE might be a candidate.

The world was a much simpler black-and-white place when I first entered industry as a software developer. New products developed by forward-thinking technologists were released into the world where customers made buying decisions based on technical brilliance. Alas, the world is more complicated than my naive perspective, and technology is not the only metric used to make decisions. There is an enormous amount of work necessary to take a promising technology and turn it into a product, work that is outside the scope of the technologist. Understanding that puts me in a powerful position where I can connect the technologist’s perspective to the larger context necessary for companies to consistently release successful products.

~ 1 Comment ~

Becoming a CIO
Posted: January 2, 2008 at 1:40 pm in journal, management ~ Permalink

I took a great class this fall in the Technology Management program at Columbia. The official title of the class is “Behavioral Challenges in Technology Management”, but it should really be called “How to become a Chief Information Officer (CIO)”. The class is taught by Alan Morley, and is a class he designed to take technologists and get them thinking like the executives we aspire to be.

On the first night of class, he pointed at one of my classmates, and said “Come up to the board and explain to the class how a company’s balance sheet works”. My classmate, like myself, had taken the Corporate Finance class a year ago, but, also like myself, had forgotten most of the information from that class. He struggled, and got excoriated by Morley. What was Morley’s point in doing so? Well, we each showed up to every class well prepared the rest of the semester - we knew that we could be publicly humiliated if we didn’t know our stuff.

But more importantly, his point was that an executive has to understand the financials of the company. If you’re not involved with increasing shareholder value as represented by the financial statements, you’re a flunky, not an executive. So one of the things we did was read How to Read a Financial Report, by John Tracy, to make sure we understood every nuance of the balance sheet and income statement, so that we could trace the cash moving around the company that way.

Another key skill that an executive must have is understanding the strategic position of a company. Technologists often believe that technology has inherent value, but it doesn’t - it only has value insofar as it contributes to the strategic goals of the company. The technologist is happy to have somebody else figure out the strategy and tell him what projects to work on - the executive must be involved in the formulation of the strategy. So we spent a few weeks going through different strategic frameworks like the SWOT analysis, Michael Porter’s Five Forces analysis, PEST analysis, and the value chain analysis. And we applied these frameworks - one week, he split the class up into groups and each group had to do a different analysis on Pfizer. The next week, we were split up into different groups and had to prepare a presentation on a company involving these analyses (my group was given ABB and covered the threats and opportunities of building generators for developing countries like India and China).

Being an executive also involves being effective at communication, so every class incorporated presentations. We had to present in group exercises as described in the previous paragraph, we had “volunteers” summarize and annotate the reading each week, and a couple people were selected each week to present an article to the class that was relevant to the week’s reading. The class was designed to get us more comfortable on our feet explaining strategic concepts in front of a room of people, as well as to function more effectively in groups. Morley also found ways to make us more succinct in our communication - we often had a time limit on our presentations so we had to figure out what the highest value information was and present that first.

The final exam tied all of the class goals together. Two nights before the final, he sent us a case study describing an agricultural chemical company. On the night of the exam, he split us into arbitrary groups and gave us the question: “You are an advisory group to the CIO - identify the strategic, technology and personnel issues facing this company, and a way to address those issues with technology.” We had two hours to prepare a ten minute presentation, using the strategic analyses to help frame the issues facing the company, and then presenting an appropriate response. Our group came up with a plan to use the web to eliminate the middleman distributors so as to increase the margin on each sale (we described it as the “Dell of Agribusiness” plan), and our ten minute presentation covered a dizzying array of topics, including a value chain analysis, an overview of the technology solution, a new plan for marketing, and the financials of how our plan would benefit the bottom line and could be funded.

The class changed how I view the world. I’m thinking more strategically, I’m poking at the numbers more, I’m looking for ways to make an impression on others both inside and outside my company. As Morley emphasized throughout the class, he’s giving us the tools necessary to be an effective executive, but it’s up to us to seize the opportunity. I may not ever be a CIO, but after this class, it will be because I did not have the will, not because I didn’t have the tools.

~ 2 Comments ~