How do you organize your Scrum board?

Like many Agile teams, here at FillZ we use a big whiteboard to help organize ourselves. We still have Jira/GreenHopper to track the details, but we use a whiteboard to focus our daily stand-ups and give us a place to get some tactile feedback from moving stickies around.

We have organized our Scrum board into Four columns: Story, To-Do, In Progress, Done. We also have multiple rows, or “swimlanes” that we use to organize our tasks by theme (usually a theme is a single story).

The Story column contains the title for each group of work in the sprint. Something like “Add support for new import format”. The To-Do column is the task-breakdown for this work. Each day we move tasks (on individual stickies) from the To-Do column to In-Progress to Done.

Nothing really new here.

However, this sprint we’ve added additional swim-lanes for each developer on the team. These rows are where each developer will place the tasks they are doing in addition to the work in the other lanes. This might include professional-development projects (try using R to analyze our metrics), non-story tasks like tuning the build-system, or even DevOps issues (reduce the number of pages from system X).

We realized that we were all doing tasks like this in each sprint, but we were never accounting for them or sharing them with each other. The plan is that developers will bring their list of personal tasks to each sprint-planning session and we’ll start estimating and including them officially in each sprint plan.

Experiment in progress. I’ll let you know how it goes.

Using IAM Roles with EC2 in AWS Console

[UPDATED – 21June2012] Amazon has corrected the problem in the AWS Console. You can now view IAM Roles in the EC2 “Advanced Details” tab so long as you follow these instructions in the AWS blog.

The rest of this blog post is now unnecessary. Just follow the blog instructions above.


DEPRECATED – do not follow these instructions. I have left the blog post here for historical purposes only. On June 11th, Amazon announced the addition of Roles to AWS. This feature allows you to automatically assign IAM permissions to a specific “Role”, assign an EC2 instance to that roles, and have the appropriate AWS keys automatically distributed to the instances. No more key management in EC2!!! This makes secure deployments in EC2 much, much easier.

You can read more about using this feature on the AWS Blog. To make it easier to get started, the AWS Docs include an article on the permission to grant users on the AWS Console. That article is helpful, but unfortunately incomplete. If you follow it as described, and try to create a new EC2 instance, you’ll discover that you cannot select a new Role from the “Advanced Details” tab: instead of giving a list of roles, the popup will say “Loading failed”.

You might try to fix this problem by granting some other combination of IAM permissions. Sadly, nothing will work, including granting all 70 permissions that currently show in the policy editor. The only thing that does work is to use a wide-open IAM policy:

{
  "Statement": [
    {
      "Sid": "Stmt1",
      "Action": [
        "iam:*",
      ],
      "Effect": "Allow",
      "Resource": [
        "*"
      ]
    }
  ]
}

But of course, that grants permissions for users to do anything in IAM. Obviously not what you want.

It turns out there is a problem in the AWS Console at the time of this blog post. As you might have guessed from the above example, there is either a bug somewhere, or a permission you need that is not listed in the Policy Generator. To get Roles working in the AWS console, you need to add a short wildcard to your IAM policy. Here is the policy I am using:

** sample code removed - no longer necessary **

The key is on line 10. There appears to be an undocumented ListInstance permission required by the AWS console. The wildcard “ListInstance*” grants it. Once you add this permission, listing Roles in the AWS console will begin to work.

Hope this helps, and have fun with the new feature.

Is Scala (or whatever else) the Right Choice For Your Team?

In my last post I described the process my team went through to identify a new language (and associated frameworks) for a project we are beginning. The results of that effort was a ranking that placed Scala first, with Python in a pretty close second. That conclusion was reached back in November, but other projects prevented us from making much headway with our decision.

Between November and Christmas we did invest a few dev-days letting members of the team try out Scala and its associated bits and pieces. I gave the team a couple of hours of Scala tutorials, provided a few great “getting started” links, offered help installing the Typesafe Stack and SBT, and provided some pointers about getting ScalaIDE (a plug-in for Eclipse) running smoothly. In short, I blasted the team with the collected knowledge of my reading and working in Scala over the last ten months.

(I should say here that I am not a Scala expert. I can properly use for-comprehensions. I understand the right way to use Option. I really, really love Pattern-matching. I have written about a half-dozen simple applications in pure-Scala. And I have read four terrific Scala books cover-to-cover and browsed dozens of web-sites. I know enough to mentor new Scala users, but I am far from considering myself an expert.)

We dedicated about five half-days for various team members to play with simple Scala, along with Spray, Scalatra and Lift. The results weren’t positive, with most everyone ending up more frustrated than effective.

I knew from my own experience this wasn’t enough time to switch into the Scala frame of mind. In fact, five half-days is just enough time for new users to realize that learning Scala will require a lot more than five half-days. But, due to other projects, that’s where we had to leave Scala until the Christmas break arrived. The goal was to start fresh on Scala first thing in the new year.

As I read and playing around over the Christmas break I started to have some doubts. Our initial experiments showed that my team of really smart engineers, after each investing a non-trivial amount of time, had all gotten approximately nowhere. As manager for the team, I had to answer one simple question: how much time did I honestly think it would take for the team to become productive in Scala, and how long until that investment delivered payback as we began serious Scala development?

This is a question every team must consider before they choose a new technology, method or architecture. How long will it take to learn? Once learned, how long will it take to pay dividends? At the risk of geeking-out, the analysis looks something like this.

oldT = timeToCompleteWorkInOldTech();
learnT = timeToBeEffectiveAtNewTech();
benefitFactor = improvementFactorFromNewTech();

if (oldT > (learnT + (oldT * benefitFactor)))
    // Use new Tech
else
    // Use old Tech

When I ran this equation through my mind, I wasn’t convinced Scala was the right choice. On my return to the office at the start of January, I let the team know that I was worried Scala wouldn’t deliver in our situation. I asked them how they felt about investing the same amount of time experimenting with Python. While they expressed frustration at having to change direction, they remembered the experience they had with Scala and figured it was worth the effort to give Python a shot.

I’ll share the results of our Python tests in my next post.

Prologue

I’ve read enough Scala blogs to know that its devotees are particularly quick to defend the language. I want to be particularly clear that I like Scala, and if I was pursuing an independent project, there’s every likelihood Scala would be my language of choice. However, as a manager I need to consider broader goals than just using what I think is cool.

I am sure there are teams and projects where Scala is a great solution – but those teams need more time and freedom than we have. Every team has a certain “budget” they can invest in learning new tools. Unfortunately, I believe that the learning curve for Scala and its ecosystem is too expensive for many teams. Only the future can say whether Scala will overcome this inherent challenge and gain broad popularity.

Trying on a new language

How do you evaluate a new language for use in a given project or team? Sometimes you have a particular framework or platform that dictates your choices. If you are developing an application for iOS you probably want to learn Objective-C (I know there are other options, but you get the point). If you really want to try Django, you’re going to learn Python. In those cases things are really simple.

But what if they’re not? What if you want to try out a new language or framework just because you believe, like me, that regular change creates new insights, relieves boredom, and helps a team learn important new methods and skills. Or what if you are finding it difficult to hire people who want to use Delphi, or PL/1 or whatever, and you need to switch to something new before all your old programmers retire? How do you decide then?

This is the situation I found myself in. We have a number of new projects coming up in the next 24 months and I wanted to get some new ideas and methods flowing through the team. In addition, we have a lot of legacy code written in Perl, and regardless of how you feel about Perl as a language, one thing is absolutely true: finding people in Victoria who want to program in Perl is extremely difficult.

I have done a lot of reading and experimenting with Scala and have come to like it. I thought it might be a good choice for our team. But I didn’t want to dictate something as personal as programming-religion (aka. language choice). So I thought we’d try something a little more data-driven.

About three months ago I had everyone on the team suggest the languages they’d like us to evaluate. Fortunately, the resulting list had only ten choices, which felt like a reasonable upper-limit. We created a spreadsheet with a set of evaluation criteria and assigned team members to research and score one or two languages in each category.

Probably your first question is: what languages did we evaluate?

To start, we included Perl as a baseline, since we already have a lot of Perl code and know it well. To that we added (in no particular order): Clojure, Scala, Python, Groovy, Java, Ruby, Go, Erlang and Javascript.

For each language we gave it a score from 1 to 5 (higher is better) in the following categories:

  • License (would it work for our business?)
  • Build Tools
  • Documentation Automation tools
  • Patch/Fix techniques (do you have to redeploy everything, or just individual files?)
  • Dependency Management Tools
  • Performance
  • Scalability / Cluster support (anything special here?)
  • Developer productivity (based on whatever metrics we could find online)
  • Test frameworks
  • WebUI Development frameworks
  • REST development frameworks
  • Cool language features
  • Easy support for Multicore machines
  • Ease of learning
  • SQL, NoSQL, and ORM support
  • AWS Support (existing libraries?)
  • Ease of recruitment
  • Size and health of the surrounding community

We did our best to score each language and add everything up. Obviously this exercise is not free from bias. The scores depended on the person doing the research, which resources they used, how they felt about type systems and language flavours, etc. However, once all the scores were in, we sat down as a team and evaluated the evaluations. Some marks were adjusted, but many were not.

In the end, we ranked the languages from highest to lowest as follows: Scala, Python, Ruby, Groovy, Clojure, Java, Erlang, Go, Perl, Javascript.

I think it’s pretty easy to say that any other team, even if the followed the same methods, would almost certainly end up with different results. A concept like Developer Productivity, or Ease of Learning, is heavily influenced by your team’s background and preferences.

Despite all the areas where our methods could be questioned, the activity was useful and the results had value for us. The winner, Scala, is where we decided to start. Details of how that worked out will be in my next post.

It’s been a long time…

My last post on this blog was an announcement that I had started a new job as the Software Engineering Manager for FillZ.com, a subsidiary of AbeBooks.com (itself a subsidiary of Amazon.com). The last seven months has been a terrific whirlwind of activity, learning, and adjustment to the new role, and I’m happy to report that I’m loving it.

One of the most interesting activities over the past few months has been the evaluation of a new tool set (languages, frameworks, deployment tools, etc) for our upcoming projects. I’ve decided to write a series of posts about the evaluation, our decision, and how that choice is working out for us.

First up: the evaluation process.

New Job and New Challenges

On Monday, May 30th, I started a new job with Abe Books (a wholly owned subsidiary of Amazon.com). I am now the Software Engineering Manager of the Fillz team (a wholly owned subsidiary of Abe Books – simple right), and I am really excited about the opportunity.

The Fillz team is a small group that makes a terrific product to assist vendors with inventory and pricing management across multiple on-line store-fronts (Amazon, Abe Books, eBay, etc).

This position is a big change from my role as Director of Software Engineering at GenoLogics. Because Fillz is a true dev-ops group, it is responsible not only for writing the code, but also the deployment and operations of the service. This combination is a lot of fun, and I am eager to begin tackling many of the challenges it presents.

I’ll undoubtedly have lots to share as I begin the process of learning about everyone on the new team, understanding the product, and getting to know the challenges and opportunities we are facing.

Favorite Books of 2010

This seems like a good time to review my favorite books from 2010. I read a lot of stuff this year and most of it was very good. However, there are a few specific titles that I’d really recommend. Since I have no particular way to organize this, I’ll just work backwards from the items I’ve read most recently. Hopefully you’ll find at least one thing here that is interesting.

The Emperor of All Maladies: A Biography of Cancer – Siddhartha Mukherjee

Since I work at a company that makes software to assist researchers in the life sciences, I hear a lot about cancer research. While Mukherjee’s book is sometimes dark and often left me feeling frustrated at the medicine behind the disease, it was a terrific read. I learned more about cancer and its history than I ever imagined. If you know anyone who has suffered through this disease, you may find some solace and comfort in the message shared in this book.

Rework – Jason Fried

Jason Fried is the CEO and founder of 37-Signals, a highly successful Web 2.0 software business. Jason discusses his perspective on what it wrong with “traditional” business and how small startups should organize themselves. It is written as dozens of very short “chapters” – each one focusing on a single precise idea. I don’t always agree with Jason, and I even got in a brief debate with him at the Business of Software conference a few years ago, but his insights are profound and every business should pay attention.

At Home: A Short History of Private Life – Bill Bryson

Bill Bryson is one of my favorite authors. His history and travel books are always surprising, educating, and often hilarious. His book “At Home” is a history of the social and technological changes that have lead to the modern house, and many of the surprising items within it. This is a quick read, and if you love technology or history, I highly recommend it.

The Way of Kings (The Stormlight Archive) – Brandon Sanderson

This is the only non-fiction book in my list and I cannot leave it unmentioned. The first book of Brandon Sanderson’s new epic is HUGE, but absolutely worth all the time. If you love fantasy, this is a new world that you will love learning about.

Euclid’s Window – Leonard Mlodinow

Mlodinow is one of the great science-popularizers of our age. In this book he discusses the five great revolutions in geometry, from parallel lines to hyperspace. Even if you aren’t excited by math, there is a lot to like here.

Priceless: How I Went Undercover to Rescue the World’s Stolen Treasures – Robert Wittman

Robert Wittman’s spent his FBI career focused entirely on art and history crimes. At times he seemed to be the only person in the entire agency who would care if a priceless Rembrandt was stolen. This is the true story of his career and the surprising underworld of art crime and art-crime dealers.

DIY U: Edupunks, Edupreneurs, and the Coming Transformation of Higher Education – Anya Kamenetz

The educational establishment is being rocked by the forces of the Internet. Traditional, in-person university courses are losing their grip on the world’s psyche, and their dollars. Ten years from now, post-high-school education will look very, very different from what it does today. In this book Anya discusses some of the forces driving this change and highlights some of the greatest experiments being conducted in this arena. Highly recommended if you have kids that will be going to secondary-education in the next few years.

Return: Four Phases of Our Mortal Journey Home – Robert D. Hales

Elder Robert D. Hales is an apostle in the Church of Jesus-Christ of Latter-Day Saints (the Mormons). As a Mormon myself, I was interested in reading from Elder Hales. He hasn’t published many books that I recall, and this one gave me a good sense of his personality and character. He discusses the four great phases of our life here on earth: preparation, decision, doing, and enduring. I need to read a book like this every once in a while to help me keep my perspective.

Switch: How to Change Things When Change Is Hard – Chip and Dan Heath

I loved Chip and Dan’s last book: Make it Stick. This one is even better. They outline the challenges that any person or organization faces if they are trying to undertake big change. They provide a framework for thinking about change and a plan for helping organize your efforts when moving forward. I suspect this book may prove the most useful to me in the coming years.

The Innovation Secrets of Steve Jobs – Carmine Gallo

I hesitated to read anything that looked like an homage to Steve Jobs. However, I put my prejudices aside and just started reading. I was pleasantly surprised. In this book, Gallo highlights at least a dozen important concepts that have helped make Steve Jobs such an influential innovator. Even if you hate Jobs and/or Apple, you can’t deny the incredible impact he has made on the world, and it’s worth understanding why he has been so effective.

Drive: The Surprising Truth About What Motivates Us – Daniel Pink

This book really made me think. In fact, I wrote a blog post about those thoughts. If you haven’t read this book, or something similar, you should.

The Drunkard’s Walk: How Randomness Rules Our Lives – Leonard Mlodinow

Another great book by Mlodinow. How does randomness affect our lives? How badly do we predict its effects and how badly do we react to randomness when we see it? The answers are surprising. If everyone read this book and understood it, a lot of terrible decisions, science, politics, and reporting would disappear completely. Wouldn’t that be nice.

The Edge of Physics: A Journey to Earth’s Extremes to Unlock the Secrets of the Universe – Anil Ananthaswamy

There are some pretty crazy physicists out there, conducting some pretty crazy experiments. This is a story about one man’s quest to visit some of the most far-flung locations to understand what physicists are doing to learn about our universe. From a trip to Siberia, to the LHC, to the high deserts of Argentina, to 1-km cubes of ice in Antarctica. Can’t decide if I’m jealous of their jobs or grateful for mine.

Country Driving: A Journey Through China from Farm to Factory – Peter Hessler

An American journalist, who has spent years living in China, takes a cross-country drive through China in multiple rental cars. The amazing people, crazy places, bizarre situations, and unusual cities are things that could only exist inside China. I learned a great appreciation for that country while also realizing that there’s so much about it I may never truly understand.

What the Dog Saw: And Other Adventures – Malcolm Gladwell

I never read Gladwell’s last book, but this one looked really interesting to me. It is a collection of some of Gladwell’s best material pulled from his years of articles in the New Yorker magazine. This is a quick read, and possesses Gladwell’s classic insights. Plenty of fun to read.

 

2010 Blog-Stats in review

The stats helper monkeys at WordPress.com mulled over how this blog did in 2010, and here’s a high level summary of its overall blog health:

Healthy blog!

The Blog-Health-o-Meter™ reads Wow.

Crunchy numbers

Featured image

A Boeing 747-400 passenger jet can hold 416 passengers. This blog was viewed about 2,300 times in 2010. That’s about 6 full 747s.

In 2010, there were 24 new posts, not bad for the first year! There were 7 pictures uploaded, taking up a total of 158kb.

The busiest day of the year was March 4th with 98 views. The most popular post that day was A Walk Through the Past – Google Style.

Where did they come from?

The top referring sites in 2010 were facebook.com, forums.pragprog.com, twitter.com, blog.cliffmccollum.com, and linkedin.com.

Some visitors came searching, mostly for this meeting has 22 minutes, leading software, genologics financial performance, “jochen stier”, and michael artemiw.

Attractions in 2010

These are the posts and pages that got the most views in 2010.

1

A Walk Through the Past – Google Style March 2010
4 comments

2

This Meeting has 22-Minutes (or does it) March 2010
6 comments

3

About Me January 2010

4

Boredom – know thy enemy March 2010
5 comments

5

Share Shamelessly April 2010
8 comments

Slides from past presentations

Back in April and May of 2010 I gave two presentations to the VIATeC Software Development Managers’ Roundtable. The April presentation covered many of the topics from this blog prior to that date, and the May presentation focused on planning good meetings and holding great retrospectives.

I finally got around to posting the slides from those presentations online. You can now view the April and May presentations at Slideshare.

Creating Universal iOS Applications

Last night (September 29, 2010) I gave a presentation to the Vancouver Island iOS Developers’ Group. The topic was Creating Universal iOS Applications (iPhone + iPad). While attendance was intimate with only seven people there, it was a great discussion. I have posted the slides from my presentation online. Check out the slides at Slideshare.

It was also a terrific way to see what other iOS developers are doing around town. I was blown away by Sound’s quick demo of a new game he is working on for Cedar Hill Games. It’s a 3D RPG-style title they hope to release around year-end. My prediction is that it will get rave reviews.

This was only the second meeting for the group. I know there is an increasing amount of iOS development activity in Victoria, so I expect the group to grow significantly in the coming year. If you’d like to check it out, learn more about the event schedule on Facebook.

Sometimes it’s just about the fun

Our QA Lead took it upon himself to organize a Scooter-day for this afternoon. We hoped to get most of the team involved, but in the end we had to settle for the few people brave enough to race scooters around downtown Victoria with the die-hard motorcycle riders in the group.

The new riders were a bit nervous in the first hour, but it was great to see them relax and really get into the goofy mode that is scooter riding. Nobody crashed, nobody dropped their machine, and everybody had a great time.

So what crazy activity can we plan next?

Check out some photos from the ride – especially the last one. It’s truly epic!

Push versus Pull

PointCast was launched in February of 1996 to much fanfare. The premise was simple: create a service that let people receive customized news and information pushed directly to their desktops. Sounds like a good idea. Too bad it failed and the PointCast network was shutdown in 2000.

There are lots of business reasons why PointCast might have failed. For the purposes of this post, I am interested in why PointCast, as a technology, was unsuccessful. I think the answer lies in Push versus Pull.

The primary problem with PointCast was that it was constantly pushing new information to users’ machines. That information was consuming huge amounts of bandwidth (for the time) and actually resulted in PointCast being banned in many corporate environments. However, the bandwidth usage might have been accepted if PointCast created an indispensable service. The problem PointCast encountered was that people were rarely able to consume content when PointCast decided to make it available.

This highlights a simple design principle that is as true in writing code as it is in public life: when the amount of information that is available is larger than the ability to consume it, push begins to fail. This is why RSS feeds and pull based systems like Google Reader have become so popular. When I have a limited amount of time to consume content, I want to be in complete control over what I consume, when I consume it, and how much time I give to each item.

There is an analog to this situation in the work place.

One of the greatest challenges in a corporate environment is to make sure everyone has the correct information they need to make their decisions. We often create elaborate processes to make sure documentation is correct, that materials are published on our corporate Wikis, and that people are alerted when important information has changed. This is all about the “push”. You think we’d have learned the lesson from PointCast by now. Teams need to put at least as much focus on Pull as they do on Push.

When was the last time your team put a focus on training people to consume documents instead of just creating them? When was the last time you heard someone admit that the information they needed was readily available but they just didn’t read it? Too much focus is placed on the need to create content but not on the need to consume it.

How can you get your team working harder at the pull?

Putting Intrinsic Rewards to Work

In my last post I talked about the Type-I personality. This personality trait is shared by most technical workers and especially by software developers. If you want software people to be happy, productive, and generate great ideas you need to tap into their intrinsic motivation.

So what have I done to put these ideas into action at GenoLogics?

Tech Lunch
About three weeks ago I introduced our team to Tech-Lunch. Every two weeks we book the two largest meeting rooms in the office for a full two hours. One room is for the “Tech Lunch” and the other is for the “Less-Tech Lunch”. One volunteer per room selects an hour’s worth of videos or presentations from TED, InfoQ, Google Tech Talks, or something similar and plays them for the rest of the attendees. When the videos are over, the remaining hour is used for a BoF style discussion about the topic and how it affects our profession, our jobs, and our products. We’ve had two iterations so far and discussed UI design with Don Norman, heard about 3-D spacial interfaces from TED, and learned about the Good Parts of Javascript from Douglas Crockford.

While it isn’t quite the same as attending a real conference, it’s far more convenient, less expensive, and more diverse. Oh, and the company pays for lunch.

Intrinsic motivation requires an opportunity to experience continuous learning. This is part of our solution.

Project Improvement Projects (PIPs)
Unless your software projects are vastly different from everything else out there, you have dozens of great ideas you’d like to see added to your product but you are never given the time or permission to make it happen. If this happens for too long it starts to affect your sense of independence and destroys your intrinsic motivation.

Two weeks ago we introduced PIPs to GenoLogics. For half a day every Wednesday, everyone on the development team (both coders and testers) work together on small, high-value projects and product enhancements that they think are important. Working as a team, they select one or two small, but great, ideas that have been burning in their minds and get them done. If their ideas will affect the customer experience must have them vetted by the Product Manager, but PM has no say into what items the team chooses to work. In short, developers have 10% of their week to focus on anything that they think will improve their efficiency or the experience of our customers.

We’ve only been at it for a few weeks, but we’ve already seen great things happening. Intrinsic motivation requires autonomy. This is another part of our solution.

Ground Breaking
GenoLogics has a long history with something we called “Hack Day”. This was a full day, once per quarter, when everyone at the company was encouraged to spend an entire day working on anything they found interesting. Telephones are turned off. Email is ignored. Everyone focuses.

Starting in 2010 we re-branded our day as “Ground-Breaking” in an attempt to encourage more people from outside development who might not be comfortable “hacking” for a day.

Yesterday was our second Ground-Breaking of the year and it was a huge success. People came in at 8am for a company provided breakfast and kick-off meeting at 8:30. Lunch was served at noon. The hacking, ground-breaking, and learning continued until 3:30pm when everyone met in the large board-room downstairs. For the next 90 minutes each person or team took four minutes to present the results of their one-day work marathon. We saw some truly innovative web-based UIs built on our new APIs, a custom iPad interface to our LIMS, a great tool to help automate the migration of configurations in our products, and over a dozen other terrific idea.

Type-I personalities require the chance to work on Mastery: the act of working at the very edge of your skill-set. Ground-Breaking is another part of our solution.

Summary
GenoLogics has made a great start, but there is still more we can do. We’ll keep working at it and I’ll share our experiences here.

What are you doing to help encourage Intrinsic motivation among your teams?

Type-I Personality

I just finished reading “Drive” by Daniel Pink. It has changed how I think about motivation and morale in the workplace.

In his book, Pink introduces what he calls Type-X and Type-I personalities. A Type-X person is externally motivated and responds well to things like performance bonuses, sales quotas, gold-stars on their report card, and carrots dangling on sticks. A Type-I person is intrinsically motived and responds well to things like meaning, purpose, doing-something-cool, building things people love, and making the world a better place.

In my experience, most developers are Type-I personalities.

So what does Pink’s book tell us about motivating developers?

The Not Surprising Things

  • Developers like to work on software that people actually use.
  • A development team will work harder on something that they believe will improve the world.
  • Learning new things and a chance to stretch their technical skills makes Type-I people happy.
  • Using cool technology makes the job more rewarding.
  • When Type-I people are encouraged in a Type-X manner, their work is of lower quality.
  • Poor salary can cause you to lose employees (Type-I people like money too), but a high salary is not sufficient to retain a Type-I person.

The Surprising Things

  • Focusing on Type-X things (sales this quarter, lines of code written) is not harmless. It can actually drain the intrinsic value out of an activity. In short, these things are de-motivating for Type-I people, even if the messages are constantly positive.
  • Type-X behavior is natural. Type-I behavior is learned.
  • Type-I motivation results in far more powerful and long-lasting effects than Type-X.
  • There is a right time for carrot and stick motivation, but it is pretty narrow.
  • Common motivation techniques often have the opposite effect.

One of the strong focus points we’ve had at GenoLogics lately has been on our quarterly bookings numbers. Keeping a close eye on bookings is critical for a growing company. However, by shining a bright light on our financial performance Pink argues that many Type-I employees will begin to lose sight of the intrinsic reasons they work for GenoLogics (such as the desire to help cure disease and improve the standard of health worldwide). In short, by trying to motivate people by showing how their work will help increase our numbers, we may be achieving the exact opposite: turning things into a Type-X activity and draining our Type-I employees of their desire to work.

That’s a pretty sobering thought.

If you manage people who fall into the Type-I category (nearly all knowledge workers and creative types) I urge you to give Pink’s book a read. It just may change the way you think about motivation.

Correct Problems Quickly

Not too long ago, I had an interesting conversation with some friends about parenting. One of the topics we discussed was our experiences correcting children. Lots of good ideas were shared, but one in particular made me think about managing software.

I know, it doesn’t sound good to say that a conversation about correcting children reminded me of software developers. However, before anyone gets upset, let me say that the conversation also reminded me about managing friendships, my siblings, and just about anyone else I interact with.

The idea is wonderfully simple: when someone is doing something unacceptable, you should correct them quickly and then follow-up with an increased show of concern for the individual.

How many times has someone on your team done something inappropriate and everyone ignored it because they hoped it would go away, but it didn’t? The longer you wait to say something the more uncomfortable it gets and the harder it becomes to do anything at all. It’s far better to speak up immediately, when the problem has just happened. This shows respect for the person and respect for the people they are affecting.

But this is only half of the advice. For some people it’s way too easy to walk around correcting everyone all the time. If you stopped there, you’d make the problem worse. Correction is only part of what you should do. You also need to promptly follow-up to let the offender know that you still appreciate them and that they continue to be a valuable team member.

If you always catch problems quickly and correct them before they become habits or established behaviors, you can prevent the buildup of those slow-burning negative feelings that can destroy your team. Don’t let your fear of speaking up, or your inability to show an increased appreciation afterwards, be the reason your team becomes dysfunctional.