I recently became aware of Daniel Pink and some of his theories on motivation. His TED talk on The surprising science of motivation, where he introduces the Results Only Work Environment concept is quite thought-provoking, and well worth a watch.

At my workplace, I have responsibility for a number of small software development teams. Each of these teams tends to work with a different technology. We have a Java team, a Ruby/Rails team, a Python/Django team, and a smattering of C/C#/C++/Perl guys. Over the past 12-18 months, we've been slowly switching our development methodology away from the waterfall model towards a more agile approach.

One of the catalysts that helped get me started on promoting and adopting agile was the following quote from a Joel Spolsky article:

Some programming teams adopt a "waterfall" mentality: we will design the program all at once, write a spec, print it, and throw it over the wall at the programmers and go home. All I have to say is: "Ha ha ha ha ha ha ha ha!" This approach is why specs have such a bad reputation. A lot of people have said to me, "specs are useless, because nobody follows them, they're always out of date, and they never reflect the product." Excuse me. Maybe your specs are out of date and don't reflect the product. My specs are updated frequently. The updating continues as the product is developed and new decisions are made. The spec always reflects our best collective understanding of how the product is going to work.

When I decided that it was time for us to start moving towards agile development, I actually printed the above quote in large letters on an A4 sheet and plastered several copies around our office ;-)

In general, the results have been pretty good. In particular, I've found that web-based development (of which we do quite a bit of) lends itself particularly well to shorter development iterations with incremental functionality enhancements. Users appreciate that we can turn-around feature requests fairly quickly and provide regular updates, and the developers cope better with smaller "bite-sized" stories.

Getting back to ROWE, one of my teams (my Rails team) has ended up in a ROWE by accident, rather than design. This came about when we simply couldn't find good Rails developers locally, and ended up hiring some contractors in another country. These guys work their own hours, set their own schedules and mostly work from home. My only criteria is that they keep me informed (we use tools such as PT and Campfire extensively) and keep delivering. Which they do. I've found that they are eminently more motivated and productive than the office-based teams working the conventional 9-6 routine.

The challenge I face at the moment is convincing some of my fellow PHB's that a ROWE is something worth exploring further - as it's quite a paradigm shift ;-)

What I find to be a very consistent failure of nearly all “motivational” techniques is ... they expect you to take work, or at least the workplace, personally.   In the USA at least, I think that this notion began to die in the mid-1990’s, and it has plunged irretrievably off of a cliff in the past three.

By “personal involvement,” I mean that you equate your identity, your feelings and self-image, indeed your life, to the work and to the work that you do there.   You can usually get a good finger on this pulse just by observing the number of personal nick-nacks that a person has in his or her workspace.   If you feel that you can get to know both the person and their children and their neighbors just by looking at the decorations of a cube-wall, you know you’re looking at a person who doesn’t have a life has strongly identified himself or herself with the workplace.

So, what happened?   Topsy turvy.   Massive layoffs.   Yes, hiring people from foreign lands (“We Work For Less! Always!”) and giving local jobs away to them.   (It happens, by the way, all over the world ... the grass is always greener.)   Giving people only the ability to be “contractors,” sans benefits, where they once could have expected full-time employment and a retirement account.   The message could not have been more clear:   “you need us, and we don’t need you, and the only value to anything that you do can be measured in money.   You are an Expense.”

Kind of a dumb thing to do, but it was all-the-rage in business books of the time.   Employees went on the defensive, and for very obvious reasons.   Dilbert became a best-selling comic that never ran out of raw material.   And, the game changed.

Abruptly, employers found themselves competing for resources who were now playing the same game that they once did.   Loyalty could not be obtained at any price.   When one party does not invest in the relationship, he cannot expect any “investment” from the other.   I suspect that it will be many decades (if ever) before anyone again feels that “years of service to The Company” will ever be rewarded – or even that it is safe to do such a thing.

One of my cousins, who was reasonably happy in his job for about eleven(!) years, found himself displaced ... and, although he is very savvy and landed quickly ... was absolutely shocked to be asked in an interview, “why didn’t you get another job in the last eleven years?”   He might have been making a wry joke, but he actually said to me, “I think the guy suspected I might have been in prison or something.”

If you are managing a project, I would frankly say that if you want to attract and keep the talent that you need, you’d better spend little time trying to “motivate your people” or second-guessing their psychology (and the culture of their inevitably-far-away country of origin) and a lot of time trying to make your project the best-run project you have ever seen.   If you observe that the people seem to be “un-motivated,” then the brain-drain has already begun and it is happening from the top.   If you lose ’em, you probably can never get ’em back.   Go look into a nearby mirror until you see where the problem is.

Interesting post. Thanks for the perspective and for garnering my interest.

I have only recently been thinking about this and, hence, this comes at an auspicious time for me. My thinking, admitttedly, relates more to a purely American perspective and regards the challenges that I face frequently in putting together teams on new projects; but recently and unexpectedly it took on a slightly global perspective from an unexpected source: my daughter.

My daughter, age 12, began attending a private secondary school this year and there are two twin boys from the UK that are in her group. The boys have been here in the US for a couple of years and expect to be here for many more (perhaps permanently).

There are, of course, the usual interesting and differing language differences that amuse and intrigue the kids. But my daughter noted a more profound challenge that prompted a long discussion between her and myself regarding the cultural differences.

The essence of the discussion related to the challenges the two boys face when trying to be a part of the young kids' culture and to good-naturedly "fit in" with the gentle teasing that goes on. My daughter's comment was that sometimes the boys "over do it" and their teasing takes on too strong or offensive a note.

That led to a discussion of how much one's culture framework guides our behavior and can, in unexpected (and even undesired) ways cause us to err when it doesn't fit with a different culture.

She was intrigued and had some truly impressive insights and ideas about how to help them and was surprisingly sensitive to how hard it would be for her to fit into what their cultural framework might be.

She noted that a lot of folks think that just learning the language and dialects is enough; but she correctly surmised that such is only the beginnig and that tolerance and allowance for the effects of the cultural framework is even more important.

That made me think of my own challenges of team formation. Your comments on the "other dimensions" beyond just the ones that Geert Hofstede, IBM, posed, were especially enlightening; they added a lot of important and good thoughts to my own ruminations. The cultural framework (whether from multi-national cultures or even multi-regional cultures within just one country), in my experience, even reaches beyond just team interactions; it also has a surprisingly (at least to me) strong effect on the technical work such as the approaches and paradigms that each programmer utilizes in their individual contributions to the team effort. That difference makes it especially challenging for us to integrate the works of the team memebers into a harmonious "common voice" result.

Thanks for the post and for giving me a lot more focus and voice to my own wonderings.

There's a problem with the whole term "team". There is especially a problem the way it is used, with multiple "teams" in a company. I'm not sure exactly how to replace it, but it is worth investigation.

A "team", you see, is a group of people each assigned a position working toward a common goal with definable victory conditions. A fire team wants to accomplish a military mission and preferably lose no team members. A sports team wants to have a winning season and preferably do well in some post-season playoffs. A team of doctors wants to help as many patients as possible as fully as possible without causing harm to any.

What is your victory condition when you put together different software development "teams"? Is it shipping one project on time? Is it getting the best behavior out of every line in terms of the spec? Is it shipping projects for the most money with the lowest cost to the company regardless of bugs and misfeatures? Unless there's a goal the group shares, it's not a team.

Furthermore, unless an organization fields multiple products with different goals, the whole organization should really be considered one team. One owner may have multiple racing teams in a circuit, and one baseball club may have teams in the MLB and several levels of minor leagues. Each has a separate individual goal, but usually there's one overriding goal. A baseball club will not hesitate to bring a start player out of the minors for the sake of the major-league team. Winning the games in the majors is more important to the organization overall. A NASCAR owner will want the best finishes for all his cars up until one driver's team needs points toward the season championship and the other is out of the points race. Then, one driver will often willingly and readily slow the pack behind the other "team"'s driver from the same owner, even if it means a worse personal finish. If you truly have different teams reaching for different goals, make sure they know what the overall organization's goals are when their team goals intersect at odd angles. Friendly rivalry probably isn't a problem, but when you cast people as separate "teams", be careful the rivalries stay friendly.

Teams in different pursuits are managed differently. A professional sports team needs some experienced players, but some youth is helpful both for athleticism and for keeping salaries below caps (in leagues that have such things, like the NFL). Some players can stay physically competitive for fifteen or twenty years, but not many. Many companies manage their intellectual workers like professional sports teams, though, and to ill effect. If a company (at least in a Western mostly capitalist economy like the US) is making money from selling its products and services, then any cap on salaries is not set by a league but is arbitrarily set by management. The productivity of the workers is not necessarily hurt by age, especially in an intellectual rather than physical type of work. In fact, it often increases with experience. Yet skimming the pool to remove the cream is an alarmingly common practice. A cheaper younger worker is not necessarily interchangeable with a more experienced one. Two cheaper, younger workers will fill a department faster than one more experienced worker, but will not necessarily produce any more useful work (or, truly, as much).

If you're making money, be willing to spend money on the resources that are making it for you. Creative and engineering talent are not overhead in a company producing software as a product or consulting as a service. They are the bread and butter of the organization. Cutting expenses by cutting productivity is not really cutting expenses at all. It is dumping valuable primary assets, which is something only moribund companies should be doing.

If your employees know that their jobs are secure so long as they contribute to the company goals, then you have the very start of what could be called a team. If you treat your employees as arbitrarily replaceable, you will never have a team at all. That's what professional sports organizations that have a history of competitiveness know. In a well-managed league no team can win every championship, and it is not likely even to have a winning season every season. Some teams, though, have a history of being sad-sack losers and some a history of being at least a factor season after season. Some go through a rough patch and don't come back as teams that matter by recruiting new players until the coaching staff is also replaced. If you have no caps, despite shareholder pressure, then pay as much as you must in salaries to make sure you make a successful product. Keep the key players and recruit only to enhance your team. Never recruit new, cheaper blood just to meet some arbitrary cap unless you're actually trying to limit your competitiveness in your league... umm, I mean "market".

Some markets are just competitive. They have not just a high cost of entry, but also a high cost of continued access. If you deny your company the cost of access to the market, you deny yourself the market. No amount of managing a team that is limited in talent, resources, and training by arbitrary cost figures will make up for that. Your group must have talent, training, and resources enough to compete or they simply will not compete.

Speaking of training, there's one thing a team has that many so-called "teams" in industry are denied. If you're recruiting people based on talent and training they already have but deny them any further coaching and training, you will lose. Oh, you might get a star player trained by some other team as a free agent, but he'll be gone again when he's offered more money elsewhere. For continued excellence, sports teams condition and coach their healthy athletes to be healthier and more skilled. They heal their injured players whenever possible. They provide facilities and personnel to improve even their best players. They have training during their off-season and continued training during their seasons. Some train three or four times as often as they play. In high school, an American football team might train five or six times as often as they play.

Yet in the IT industry, it is often expected that a person's training is over at the point of hire or that the employee is responsible for all of their own training on their own time. That's not how teams are built. Teams are trained together. Coaches may use individual strengths from previous training, but they also try to train away deficits. They also learn to play as a team by practicing as a team. A team that doesn't practice well together doesn't play well together. I'm not talking about an annual rope ladder and mud puddle "team building" exercise. I'm talking about teammates building useful projects together that are used internally before and between building projects to ship. A team knows how to perform together when under competitive pressure because they perform together when they aren't.

The team members know as individuals that so long as their contributions to costs ratio outweigh those of other prospects that their positions are safe. This is in teams with a maximum number of fielded players and a maximum number of rostered players. Yet what many in IT call a "team" has no such guarantee to its members. The single most valuable player may be removed from a team not because of retirement, free agency (the player seeking a better deal), injury, or a trade to fit under a mandatory salary cap. He or she may just be gone. Maybe he or she performed 60% of the really useful work out of a team of ten. Maybe the quality of work produced by others around him or her was improved by example. But perhaps that information was lost in management who doesn't know how to coach. Perhaps the business school taught about managing projects, time tables, and "teams". Maybe they didn't teach coaching and training of valuable personnel and actual living, breathing, interdependent teams.

Cool article... very dense... A lot of info you've been studying.

I'm huge into making my team the best. I find that I consistently end up being the team's cheerleader. People are not machines, and I think they need a lot more encouragement than most managers are willing to give.

Sometimes I think when management wants to put teammates into a spreadsheet, assigning roles according to some formula that they've studied, rather than focusing on the hurdles of a project, and then they want to press a button and start asking "When you gonna be done?"

Understanding roles is important, but only if that role and those expectations are clearly communicated to those who are supposed to take up the role--and then the teammates actually step up and take them on. Otherwise it's just going to be one more assignment that's as poorly defined as the project itself.

When that happens I find my loyalty to a project wanes.

Another trouble to defining team roles too rigidly is that people change over time--especially as the project becomes better defined. Even I've felt times when my enthusiasm is numbed, especially when my ideas are not given validation.

This whole investigation into agile programming is fascinating, and having been exposed to it at my current job, I'm beginning to wonder about what the overarching goal is. Certainly, one of the goals is to make sure the required productivity objectives are met -- bugs are squashed, and features are implemented. But that happens in a normal development process. So how is agile different?

I think the answer is that it allows management one level above the teams to keep a very close eye on what's happening at the ground level. The problem, of course, is that reality intervenes, with its expected delays on the carefully planned schedule. A production emergency arises, a high level feature must be implemented right away; someone is sick -- and the carefully drawn out schedule gets re-written.

What I don't think is covered by the agile process is what happens when the developers are done their due diligence, and the software needs to be staged and then deployed. You might do a small fix (less than a day of development) that needs days of testing. If the developer had to be on hand for the testing, whose budget does that come out of?

However, I agree with some of the agile ideas -- I think the daily stand-up meeting (where everyone on the team talks about their first three priorities of the day, and any possible roadblocks) is an excellent idea. I also think it's important that team members keep the team lead informed throughout the day, if their rate of progress changes dramatically (either "I got this done early" or "I'm having a problem with Vince again").

But I'm not so sure that making up estimates for each individual task is such a great idea, since estimating how long writing a piece of code is tough to do. Certainly, we can guess it will take 4-8 hours, but from a scientific point of view, that's hilariously imprecise (6 +/- 2 is an uncertainty of 33%).

I think I have a Meditation brewing. Great post, thanks so much!

I also think it's important that team members keep the team lead informed throughout the day

Agreed. However, that is not Scrum, as prescribed by the (recently updated) Official Scrum Guide: "Scrum recognizes no titles for Development Team members other than Developer". So, if you have a "team lead" title, you are not practicing Scrum.

I further noticed that the Scrum Update (July 2011) clarifies that "Development Teams do not commit to completing the work planned during a Sprint Planning Meeting" ... which agrees with my opinion, expressed (strongly) above in the "Team Commitment" section! :) Maybe our (certified) Scrum Master back then didn't know the Scrum rules as well as he claimed. However, after comparing to the official Scrum Guide of February 2010, my reading is that he was accurately applying the 2010 Scrum rules and that this July 2011 "clarification" is actually a rule change.