Showing posts with label organizational design. Show all posts
Showing posts with label organizational design. Show all posts

Sunday, September 12, 2010

Motivation: would your employees buy their own supplies?

This came from a local paper, but surely many teachers around the country behave similarly:
Like many colleagues, she said she spent about $100 on back-to-school supplies. She said she expected to spend another $400 of her own money over the rest of the school year.
Let's put it another way: suppose $500 is 1% of the teacher's annual wages, which seems like a fairly reasonable estimate.  They're spending money not for the employer, but for what you would call "clients", who should and are expected to provide for themselves. 

Now take a typical bond trader, and 1% of their salary is $5k to $10k.  (Yes, it could be a lot more.)  Would you think they would spend that much every year on client problems?  They might ask their company to pay, but if they didn't, how many do you think would dig into their own pockets?

The article goes on to say that many of these teachers have spouses that have lost their jobs due to the recession.  They spend the money anyway because they want to make sure every child has equal opportunity, and they want to provide a good environment.

How do you get an employee to care so much about their job that they take the quality of their work so personally?

Sure, it helps that teaching can be very rewarding.  Teaching can provide a meaningful purpose, which Dan Pink identifies as one of the three critical factors for employee motivation.

Another aspect is professional pride.  Teachers have a vision of how they want the lesson plan they've created to go, and every kid that doesn't have the right supplies is an obstacle to achieving that.  I know a number of software developers who pay for many pieces of software and hardware so that they can do their jobs better.  In both cases, autonomy about how to achieve their goals -- the teachers create their own lesson plans, the programmers can use their own tools -- imparts ownership of the results.  Yes, this covers both of the other primary inputs that Dan Pink discusses.

One personal aspect, though, is simply getting employees deeply involved with their customers.  Teachers see theirs everyday, and the desire to help springs forth.  (Or else, they become overwhelmed by it, shut down, and just see it as another job, the kids' problems as not part of their job description.)

Being around other people, personally sharing in their problems, unlocks a natural instinct to want to get involved.  We sometimes purposefully avoid knowing anything because we know beforehand that once we even put a toe in the water, we'll be compelled to jump all the way in.

If you're running software teams, get them in front of the users as much as possible, as much as the users allow.  That's one strong argument against separate support and development teams.  Programmers who see their users more won't need any more motivation than that to rush back and work quickly on that bug that seems so small (hey, there are workarounds!) but is in fact a major pain and awfully embarrassing.

Wednesday, September 1, 2010

Drive: reading list

At the end of Drive, Dan Pink offers a dozen or so books that provide more depth.  All of them intrigued, but these stood out:

Why We Do What We Do: Understanding Self-Motivation by Edward Deci.
"The questions so many people ask -- namely, 'How do I motivate people to learn?  to work?  to do their chores?  or to take their medicine?' -- are the wrong questions.  They are wrong because they imply that motivation is something that gets done to people, rather than something that people do." 

Fascinating.  Those are questions I'm asking all the time, so I've got the wrong ones.

Punished by Rewards: The Trouble with Gold Stars, Incentive Plans, A's, Praise, and Other Bribes by Alfie Kohn.
"Do rewards motivate people?  Absolutely.  They motivate people to get rewards."

I've been thinking about whether to given a small token at every practice for the hardest working player on the soccer team I'm coaching -- basically, a gold star.  Yes, very Management 2.0, but I figure these are 8 year-olds.  Maybe I should read this book first.  Kohn has been writing about this stuff from all sorts of angles; lots to explore.

Maverick: The Success Story Behind the World's Most Unusual Workplace by Ricardo Semler.  Pink calls Semler "the first autonomy freak."  He has 3000 workers in a manufacturing company, Semco -- the kind of company where you'd think stricter management would produce the best results -- and he lets them set their own hours, vote on major decisions.  Some set their own salaries.  Semler hesitates to call his company "organized" -- 3000 people! 

The company has done fantastically well for 20 years.

Tuesday, August 31, 2010

Drive: audit yourself

Drive offers a tool for measuring autonomy, one of the three tenets of Management 3.0.  Audit your workplace or your team. How much input do you or your team members have over:
  • Tasks -- responsibilities and main tasks.  Can they decide what they work on, what goals they want to set, what their priorities are?
  • Time -- work schedule.  Who decides when the "work day" starts and ends?  If there's rotational coverage of some kind, who determined what rotation was required and how was the coverage assigned?  Do you require people to spend time commuting?
  • Team -- who they partner and interact with.  Do they get to pick their project team members or are people assigned?  Can they decide to divide the work up with others any way they choose?  How much freedom do they have to interact with customers or business partners, or senior managers for that matter?
  • Tools -- how they're supposed to do it.  Tasks are what they're supposed to do; tools are the method.  For programmers, it could include architectures, IDEs, even languages: who chooses?  Are there a lot strict processes in place -- check in these things, fill out this form, then get sign-offs from these people, then schedule your release only on Fridays -- or is it totally free?

Compile the ratings given by everyone on your team or department or whatever level you desire. 

Being completely autonomous in every aspect of the job might be undesirable.  For example, jobs that require customer interaction have to consider the customers' hours and locations.  You'll have to get creative to find ways to bring more autonomy to that area of the.

Also, average scores might be fine, but a low score in one area might indicate an place to focus.

Monday, August 23, 2010

*Drive*, part 1

Drive tells us about Motivation 3.0.  Version 1.0 involved kings: do it my way or die.  Motivation 2.0 introduced management: supervision and evolved forms of control.
Management still revolves largely around supervision, "if-then" rewards, and other forms of control.  That's true even of the kinder, gentler Motivation 2.1 approach that whispers sweetly about things like "empowerment" and "flexibility."
Indeed, just consider the very notion of "empowerment."  It presumes that the organization has the power and benevolently ladles some of it into the waiting bowls of grateful employees.  But that's not autonomy.  That's just a slightly more civilized form of control.  Or take management's embrace of "flex time."  Ressler and Thompson call it a "con game," and they're right.  Flexibility simply widens the fences and occasionally opens the gates.  It, too, is little more than control in sheep's clothing.  The words themselves reflect presumptions that run against both the texture of the times and the nature of the human condition.  In short, management isn't the solution; it's the problem.

If you don't have management, what's left? 

Motivation 3.0, which comes from the self.  Drive is about how organizations can foster that -- indeed, that organizations must foster that, because those that don't will themselves die in the future.

Saturday, July 10, 2010

The real argument against outsourcing

It's clear to me there are only two paths.  One path is to take every repetitive, by-the-book task in your organization and outsource it or mechanize it.  The other path is to take every repetitive, by-the-book task in your organization and give the people who do that task the freedom, the incentive, and yes, the imperative to do something that cannot be outsourced.
Either what you're doing is repetitive, in which case you ought to outsource it, or it's homemade, insightful, and filled with initiative and judgement, in which case you can charge for it.

-- Seth Godin, Meatball Sundae:
Of course, this is only an argument against outsourcing if the organization distributes the power, and everyone runs with it.  Many organizations can't imagine such a scenario and hire people who wouldn't know how to respond.

Sunday, September 20, 2009

Pair programming vs autonomy

Pair programming has gone mainstream when you can read about it in gory detail in the NY Times:
Once two of our programmers had a falling out over a keyboard function. The navigator wanted to remap the caps lock key as a control key for when they switched roles.
Nothing ground-breaking here, but an example of the article's detail -- pretty geeky stuff. Soon, we'll be able to talk about the pros and cons of it with our parents.

I've never worked in a pair programming shop, and have always been suspicious about how well it would work.

My basic suspicion about it boils down to this: Dan Pink argues forcefully that the future of workforce motivation for creative professions involves granting lots of autonomy -- including locational and temporal. His argument is pretty convincing.

If people should be given the ability to choose their own work hours and location, how can pair programming survive?

Other agile practices can be constraining also, such as the daily scrum or a physical Kanban board, but none as deeply as pair programming. These guys have a daily 9 am meeting where they figure out who they'll work with and, presumably, what they'll be working on. Then they adhere to a fairly strict work pattern -- 25 mins on, 5 mins off.

The writer indicates all participants are pretty happy about it. I liked this article particularly because he went into such detail about their implementation at a personal level. Indeed, it sounded inviting to me.

But, I can't both be a fan of pair programming and also Dan Pink's research on motivation, can I? They seem inherently at odds.

Tuesday, August 25, 2009

How does your company compare?

If you work in a large company, you surely know how hard it can be to get rid of dead weight. You probably know some people who aren't contributing, yet manage to stay in their jobs for years.

Now imagine if
  • everyone that worked in your company earned a job for life on their 3-year anniversary, unless fired for cause.
  • workers whose jobs disappear, because the company got out of certain lines of business or closed departments, continued to get paid indefinitely while they waited for reassignment, even if they refused to take another job within the company.
  • all cases for firing, including blatant cases such as being knocked out drunk on the job, required a special investigation and an arbitration hearing, which can take up to 2 and a half years to start, 40 days or more in active testimony, and another year before an actual ruling, during which time the worker continued to draw a full paycheck.
  • over 2% of your workforce drew a paycheck and showed up everyday in order to do absolutely nothing, because they were waiting for arbitration or reassignment.
Do you think you'd have any incentive or motivation problems? How much dead weight would you expect, not even counting the 2% known non-workers? Imagine trying to get something done.

Sadly, this is a description of the New York City school system. Reading this full article presents an even bleaker picture than what I've summarized. The hundreds of millions of dollars all these non-working teachers and misaligned incentives cost annually is the least of the real cost.

There are a lot of messages and conclusions you could draw from this situation.

One thing that struck me is that many great teachers and principals still take the job, put their hearts into it, and do great work. They deserve an even bigger commendation, and probably more money, than I originally thought, and that's saying something.

And it speaks to the power of a shared vision. Despite being surrounded by wreckage (don't forget the poorly maintained schools and sometimes unsafe working conditions), a strong mission and sense of purpose can really help people who want to do good work stay focused.

If you have any leadership responsibilities in your company, surely the barriers to changing things and creating the better environment aren't as great as the ones facing the school system's superintendent. What's stopping you?

Saturday, April 4, 2009

How to get paid at Fog Creek

Joel Spolsky shared his company's compensation system in one of the "serious" April Fool's Day posts:
In Fog Creek's system, every employee is assigned a level. Currently, these levels range from 8 (for a summer intern) to 16 (for me). Your level is calculated formulaically based on three factors: experience, scope of responsibility, and skill set. Once we determine your number, you make the same as every other employee at that level.
I always appreciate companies that try new compensation schemes, and even more if they share it with the world.

Compensation is one of the critical levers that contribute to the culture of a company. At the same time, the culture of a company will greatly affect how compensation gets interpreted. Different sized companies with different cultures in different industries need different compensation systems. There's no one right answer.

Joel has clearly thought a lot about what he wants compensation to say about and how he wants it to affect his company. That, in itself, is at least half the battle.

The best part of Joel's system is that it prevents newcomers from making more money than the existing employees, which I see all the time. Most companies I've worked for just hire people, and rising market prices force salaries higher for the last one in the door -- even if people that already work there have equal skills, not to mention that they already understand the specific intricacies of the application and company processes.

Another underlying principle of Joel's system is to make everything transparent, so that everyone understands how their compensation is set. Lack of objectivity (or just the perception of it) really angers employees, either killing their motivation or resulting in their departure.

His system also removes favoritism, or at least discourages it by forcing it out to the open.

Two things prevent this structure from being more widely adopted:
  1. Small companies usually spend little time thinking about organizational issues. They're completely focused on staying alive by developing new product and new customers. But that's a bit like not implementing daily builds or automated testing because the focus is on writing new code.
  2. As a company grows larger, it requires increasing numbers of levels. Fog Creek currently has 9 different salaries in any given year. Given that they probably have less than 200 people, they might have 25 people in a level. Now imagine they have 2,000 people, resulting in over 250 people in some levels. The range of skills at each level will vary much greater; i.e., Ann, a level 11 who just missed getting level 12, will be closer in skill and contribution to Bob, who just barely made level 12, than to Clark, who just barely made level 11. The problem with having more buckets, though, is that in makes the gradations harder to define in a simple chart like Fog Creek's.
Fog Creek will eventually have to re-tool their compensation system, either because of growth or lack of it. But, I don't think it's a stretch at all to say that a lot of their success comes from strategic thinking about organizational issues such as compensation.

Sunday, March 15, 2009

"Forced entrepreneurship"

I think of software teams as entrepreneurs. Not just because so many software companies are start-ups trying to find a niche. Even at big companies like where I work now, the entrepreneurial spirit drives the success stories.

Read this NY Times article about laid-off workers putting their creativity to do new things. The subject of entrepreneurialism fascinates me, because the good IT departments at my company, as well as the good small companies where I have worked, all have that same spirit.

At one start-up I worked at back in the 90s, we had a huge client-server installed base. Eventually, Java and web service type applications showed too much benefit, and we jumped with two feet into that space. What made that a great time was not the relief that I could strengthen my resume, but being surrounded by individuals who eagerly threw away everything they knew, where we were experts, for the chance to try some new things, where we were rookies.

At larger companies, organizational bureaucracy may crush the entrepreneurial spirit. But, I also find that a large number of the people who come to larger companies no longer have a hunger to learn, or even a curiosity about what is going on around them.

The best IT departments in our company attack problems like something personal is at stake, as if they were laid off, and it's now up to them to find solutions, to try new things. This can be difficult -- there is a lot of organizational bureaucracy of course -- but that should be the aim of every team and department. If yours is lacking that, then figuring out how to change it becomes the top priority.

Thursday, February 26, 2009

What's the Google secret?

A final comment on compensation, this one related to options. (Then, like the bonus cycle, we'll be done with this subject... until next year. That's the way the financial industry works -- for now.)

Google gets a lot of press about how great it is to work there and how people are lined up for interviews, like the lines for American Idol auditions. Stories about their 20% free time policy, creative culture, self-organization methods, and of course free food sound very appealing. I admire them for their innovative products and efforts to balance business with "not doing evil". And yes, some of my best friends are Googlers.

Recently, Google decided to reprice options that it had given out to employees. Due to the stock market cliff-dive, the options became worthless.

This reminded me of another tech company that was once considered the greatest in the world, hiring only the smartest of the smartest people. They minted many millionaires through stock options. People dreamed about working there.

The company? Microsoft, which many would say epitomizes everything that Google is against. It wasn't that long ago that Microsoft was the beautiful company.

Which led me to wonder: is the warm glow coming from Google really just a function of their (previously) red-hot stock price? Will Google be perceived as just another company now that the options payoff has disappeared, and their pay matches most other companies (i.e., now that even their masseuse can't become a millionaire).

Obviously, this is a simplistic view. Google represents the cloud revolution against the desktop, just as Microsoft represented the desktop revolution against big hardware. That's also important.

But what I'm interested in is whether Google is actually a fundamentally different type of company, or they just have a good business at the present time. I think if you asked Google management which they would rather have, they'd choose the former. (Of course, everyone would want both.)

The typical justification for options is to align both the long-term benefits of the employee and the employer, via the stock price of the company. At the point that the company reprices options, the options are no longer acting as an alignment tool, though. The employee benefited despite how the company fared. The company's options program is exposed as just a form of deferred compensation.

There's nothing inherently wrong with that. Any manager would be foolish not to exploit a cheap way to fund super salaries for great people, as long as the shareholders don't mind.

Going forward, it will be interesting to see whether Google's creative organization continues to be heralded as their secret weapon, or whether their exalted image will follow their stock price.

Tuesday, February 24, 2009

There's no f in bonus

Bonus season winds down here in the financial industry, and we're left to consider what it all means. The bonus pool is particularly sensitive on Wall Street because financial firms rely on it excessively, outweighing regular pay for some employees. Many workers in the industry and in my company took a zero bonus.

What is the purpose of a bonus? Reward for individual productivity? Incentive to stay? Alignment of interests between employee and employer? Profit-sharing?

If your answer is all of the above, then I think there's no chance the bonus system at your company is working. It's just another form of compensation, so there's almost no reason to have it; just give a regular salary.

The general public is fuming about Wall Street firms' bonuses this year, in light of having their received taxpayer assistance. The public views these bonuses as a type of profit-sharing; thus, no profit, no sharing.

Individual employees view these as productivity rewards. Thus, the ones who worked very hard and had measurable positive results this year are upset about low or no bonuses.

Middle management typically views it as a key employee retention tool. Thus, even though Mary Developer didn't have the opportunity to produce like in previous years (maybe a couple of her projects were canceled), and Joe Programmer out-produced Mary this year, rarely would a manager consider switching their bonuses if Mary is viewed as the foundation of the group.

I would guess that senior management most commonly views these as a way to align employee and employer interests. Unfortunately, the payouts encourage the employee's short-term interests, which may be at odds with the company's long-term interests.

Underlying all these interpretations: a bonus that doesn't grow or, worse, shrinks feels like a punishment, even if the bonus is advertised as variable or tied to profits.

I think the biggest problem is that most companies haven't really thought specifically about what the bonus should accomplish. Thus, it tries to do all of the above by default, only because everyone interprets it however they want.

One of the most important decisions a company's executives makes is how people will get paid. If they want use bonus payments effectively, they need to be crystal clear about their purpose, and drive that down through the company.

On Wall Street, they would likely have revamped the entire bonus structure, probably eliminated it. Unfortunately, the issue has now spun out of control, and the revamping will be imposed.

Wednesday, February 18, 2009

What's in your box score?

I'm not a big fan of the NBA, but an article about NBA player Shane Battier is loaded with insights about teams.
It was, and is, far easier to spot what Battier doesn’t do than what he does. His conventional statistics are unremarkable: he doesn’t score many points, snag many rebounds, block many shots, steal many balls or dish out many assists... "He can’t dribble, he’s slow and hasn’t got much body control."

Battier’s game is a weird combination of obvious weaknesses and nearly invisible strengths.... When he is on the court, his teammates get better, often a lot better, and his opponents get worse — often a lot worse. He may not grab huge numbers of rebounds, but he has an uncanny ability to improve his teammates’ rebounding.... At the same time he somehow improves the defensive efficiency of his teammates — probably, Morey surmises, by helping them out in all sorts of subtle ways. "I call him Lego," Morey says. "When he’s on the court, all the pieces start to fit together."
Weak stats on both offense and defense, yet teams he plays for become winners.

An old adage claims that you can't manage what you don't measure. Seems true enough. Is the quality of your software improving? Much easier to say if you have some statistics on number of bugs, severity, etc.

But are you measuring the right things?
For most of its history basketball has measured not so much what is important as what is easy to measure — points, rebounds, assists, steals, blocked shots — and these measurements have warped perceptions of the game. ("Someone created the box score," Morey says, "and he should be shot.")
The ongoing financial meltdown contains numerous, unfortunate examples of what happens when the wrong behaviors are rewarded based on measuring the wrong things. For one, bankers bonuses were tied to the size of their deals, regardless of quality and risk.

It's only recently that the NBA started to figure out how to measure the value of team play. At "regular" companies, the use of 360 reviews attempts to get at something similar. Feedback loops from multiple sources on multiple aspects of a person's job can also be used.

Does your team / manager / company -- do you -- encourage behavior that makes the team stronger? Or are you breeding players just padding their own stats?

The article goes into a lot of other equally relevant and interesting subjects. Read the whole thing.

Friday, January 30, 2009

Dogfooding

Jeff Atwood discusses a particularly vivid example of "eating your own dogfood". In software development, this means using the software you make, thereby displaying confidence in your product.

While I am a big fan of the philosophy, this doesn't really work if the software you make is not for a mass market or for developers. My jobs over the past decade have been creating trading systems and international shipping tracking. Not much use for that on my own desktop.

However, in an earlier post, Jeff says

if you can't dogfood, consider working the help desk for a few days. I'm serious. There's nothing quite as effective as sharing the customer's pain.
I can't agree more with Jeff's suggestion. Not only do you get a great view of what your customer is thinking, but you get a great view of what the team is thinking.

As managers, we sometimes get the idea, "Hey, I'm a manager now, I don't develop anymore." Or, as developers, we sometimes think, "Hey, I'm a developer, I don't do QA."

Yet, dipping one's toe in these other areas pays innumerable benefits. Some companies train their managers with a starting rotation on the front lines; I'm completely in favor of that.

In a previous job, I was put in charge of a fairly large group, where the programmers did both development and support. I took some shifts working the "hotline", taking calls from users.

Here are some of the specific benefits that came out:
  • I got a deep understanding of the user's pain points (Jeff's point), which helped with decisions about priority.
  • I talked to and developed relationships with a set of users I might not have otherwise me.
  • I got a deep understanding of the cost of the user's problems, which helped with decisions about resource cost (for both fixing and not fixing).
  • The technical and business skills and knowledge of each developer became apparent when trying to find the right people to help with a given problem.
  • I combed through the code first-hand, getting a view of its quality and organization.
  • I had to familiarize myself with the dev tools and processes.
  • I received a first-hand view of how the team worked together.
  • These activities were not viewed as "management prying" because they were part of an actual goal-oriented effort.
  • Based on this knowledge, I devised a more efficient support and development schedule.
  • Because the schedule was based on line experience, it naturally included many of the developers' own concerns, and not just a plan "dropped from the sky".
You will notice that almost all of these benefits accrued to me. Sitting on the help desk was not an exercise in altruism, or a heroic symbolic gesture.

This is not dogfooding in the traditional sense. However, being forced to live in the environment that surrounds you, that you contribute to -- developers taking a QA turn or going on a sales call, managers taking a developer turn or answering the hotline, etc. -- is the same philosophy applied differently.

Dogkenneling, perhaps?