I think it’s a truism that there is no single barrier to IT project success more powerful than bad management. There are dozens, if not hundreds, of ways in which bad management directly and indirectly decreases productivity, and undermines even the the possibility of success.

Foucault, is the twentieth century master of uncovering hidden power relationships, and anybody who’s read his masterwork Discipline and Punish will learn a variety of tools to uncover hidden power relationships, and these tools can be immensely valuable in unpacking what’s really going on when a situation “just feels wrong.”

It’s hard to quantify, but knowing this stuff can definitely help you avoid political landmines, and create a safer work environment. But, I still haven’t figured out how to make Foucault palatable and understandable to the average IT manager. ;)

But Naked aggression is easy to spot

On the other hand, you don’t need a sophisticated set of tools for unpacking power relationships to see what’s wrong with some teams. For example, I once worked for a manager who held daily motivational meetings, in which he enumerated every small mistake that any of us could make that might make him look bad, and let each of us know in no uncertain terms that we would be “terminated” if we were seen to have made even the smallest mistake. If we didn’t answer the phone with the right phrase, or try to convince customers that they wanted more expensive products than they needed, or failed to live up to any of thirty different (and sometimes contradictory) arbitrary rules, we were told we would be fired instantly.

Doing the wrong thing may pay off now, but it almost always hurts you later.

I left after less than 6 months, by the time a year was up, only 2 of 20 of the original people on the team were left. But, the manager received a commendation for “running a tight ship.” Things were looking good. Then again, a year later he was fired, because his team just couldn’t keep up, and everyone on the team was so busy not screwing up that the had no time or energy left for the important things they were hired to do.

Dominance games, and pure aggressive pressure helped him meet his daily and weekly goals, but killed him in the long run.

Project managers need to learn to wield power with a light touch.

It’s inevitable that there are power-relationships involved in the context of an important project. If you’re doing things right people are passionate about the project, people want to do the right thing, and people don’t always agree about what the right thing is.

It can be tempting to jump into these disagreements and make decisions — and it can speed up progress in the short term. But be careful, just like the manager who made his short term goals, but lost in the long run, you may end up killing people’s passion, and cutting off discussion before critical information is revealed.

Sure, there are times when a strong good push can help people avoid prolonged and useless discussions, but it’s too easy to take advantage power relationships to avoid difficult but important discussions.

There’s lots more to be said on the subject of power relationships in software development, but I think one of the key things we have to understand is that computer nerds participate in power struggles too, they just do it naively and instinctively. And that leaves us easy prey for those who do it with knowledge, talent, and finesse. And those people are out there and in places where 2 years is a long time, they can get away with it for a surprisingly long time.

P.S. I wrote this post in 2007, almost published it in 2008, and am just now getting around to publishing it. So, please don’t think this is about anything happening to me personally right now, but it is something I keep seeing “around town” and something I think we need to understand better if we are going to stop falling prey to those who understand power politics better than we do and wield them more aggressively, and end up ruining many good projects.

ArbCamp will be tomorrow night, in the upstairs of the downtown Cottage Inn’s, so this is kind of last minute, but I think it’ll be a very cool event. It’s an UnConference, and people will be self-organizing a variety of sessions, and the possibilities are endless.

Children of kings and great magnates were the first to grow up out of touch with the world. Suburbia means half the population can live like kings….

Paul Graham

You can’t shelter people from everything bad or scary, and expect them to live in the real world.

Project managers, System Administrators, and parents should take note of this.

People can only step up and take responsibility when they actually know what’s going on. Seems to me that there are lessons for how we talk to people about project risks, how we handle e-mail spam problems, and how we think about IT services. It’ll be a while before I figure out what exactly all of those lessons are….

Data is certainly not like many other assets, it doesn’t depreciate, you can copy it endlessly, and it’s next to impossible to imagine a commodities market for data. Heck copying the data can either increase it’s value (think “The DaVinchi Code”) or decrease it (think passwords). People don’t pay for data as much as they pay for human attention. You can use data to get attention or you can use attention to collate, assimilate, and otherwise transform raw data into useful information, but either way data needs people to understand and interpret it to become valuable.

So at best:

data + human_understanding == value

Bruce Schenier takes it one step further, calling data the pollution of the the information age.

Data Pollution

Data sucks up space, time and human attention. But more than that, data can be parsed, manipulated, and transformed to fit various agendas. And in a world where data about all of us is “owned” by various large corporations, from Amazon, to Google, to Enron, it’s not always clear how that data will be used. Besides which millions of credit card numbers are stolen from various companies who store our data “in good faith.” Data costs money in terms of maintenance, in terms of storage, and in terms of liability. Heck, I know people who work for companies who have an e-mail retention policy — which is really more of a mandatory e-mail deletion policy.

Polluted Data

And that assumes that all that data is verifiable true, and that’s definitely not the case. I sold a car once and the new owner didn’t take it to the DMV to get it registered before his friend drove it without a license and got it impounded. And that showed up on my credit report for years. I have a friend who somehow ended up “deceased” even though she’s still very much alive and well.

All of this is to say that as software developers, IT Mangers, and companies in general need to think a lot more about data, and to invest in some better terms for the various different things we call data.

We need to differentiate between raw data, information, and knowledge. We need to help our customers think about the life cycle of the data they want us to capture. We need to educate people about the costs and benefits associated with keeping data, and ultimately we need to follow the mantra:

Think before you store

And if you’re concerned about privacy, and individual liberty, please take a few min and read Bruce’s article.

Why have motivational meetings?

The right way to use motivational meetings is to reaffirm the purposes of the group, and help people to connect the dots between their individual efforts and the collective goals of the group, and to connect those goals with their own individual aspirations.

Basically, motivating people is easy:

• Give them work that is meaningful to them and to the organization
• Treat them with respect

Treating people with respect includes paying them a fair wage, and not doing any of these things.

Among other things it also means not letting people who aren’t contributing to the common goals of the organization hold back the group by not doing their job.

Research has shown that one of the survey questions most highly correlated with motivation and performance is:

Does my supervisor, or someone at work, seem to care about me as a person?

Which is another way of saying does your boss respect you. At the same time the single highest correlation for any question was:

I get to do what I do best everyday at work.

So, it’s really important to line people’s intrisic skills and internal long-term motivational drivers with the work you ask them to do.

If you’re not doing those two things, motivational meetings are a loss. If you are doing them you can use a meeting to remind people of how their deeper motivations are connected to what they are doing now.

P.S. My info on the top questions and their correlation to performance comes from Gallop research via the very interesting book First Break All the Rules, which is one of the best, and most evidence based, books on managing for exceptional performance I’ve read.

Motivation is a complex network of hopes, dreams, fears, needs, frustrations, incentives, and personal morality. Motivating people is as much about connecting their individual aspirations to the goals of the organization as anything. If people can do what’s right, become who they want to be, and get paid to do it, that’s a far more powerful motivator than you can get from any meeting.

If those things are true, you can skip the motivational meeting. Everybody would rather sit down and get some work done. And if they aren’t true it’s not likely that another meeting will help.

Clark Ching recently blogged about something I’ve seen a couple of times. He worked for a company that paid developers very well. You’d think that would be good for morale, but it wasn’t. Clark puts it this way:

It was horrible. Everyone who worked there agreed.

People who hated their jobs stayed just because of the money. This meant that everybody had to work with people who hated being there, and that meant that nobody wanted to be there ;)

Good pay reduces turnover, which is generally a good thing. But some turnover is good turnover, so too much pay can actually hurt you. Beyond that great pay keeps people around, but bad experiences with managers and coworkers can do more to kill morale than you can ever replace with money.

The long and short of it is that you can’t paper over morale problems with money, and you can’t fix them by instilling a sense of urgency. Paul Graham suggests one solution — do something good. If you’re doing something good for the world people want to help you. I’d extend that to say if you’re building something people can be proud of, you’re far more likely to create the kind of positive morale which lasts through hard times.

Case in point, this story of a couple of apple employees worked on the graphing calculator that was shipped with the original Macintosh computer. The interesting part is not that they were excited to work on the project, but that they kept working on it under-cover for months and months after they had been laid off.

Why would they do that?

I had long been proud of the elegance and simplicity of our design…. I had designed it for all users, even those who know little about computers and hate math.

I wanted to make mathematics as easy and enjoyable as playing a game.

They did because they were proud of what they’d done, and because they wanted to make mathematics more accessible.

Python get’s a very positive review:

Today you’d be nuts not to look seriously at PHP, Python, and Ruby.

So, the rise of the so-called scripting languages is one of the inflection points, but it’s not the only one.

He singles out web-framework development as one place where there’s a lot of stuff happening, and a lot of new “rails-like” frameworks are cropping up all the time. TurboGears will live or die in the context of a much larger web-development revolution, and we need to be prepared to make our way forward in the midst of that.

What comes after rails will not be a rails clone. It will learn the right lessons from rails, avoid the pitfalls of rails, but it will also need to carve out something new and better than rails. For RDBMS users, I think the key difference between TG and Rails is the power and flexibility of SQLAlchemy. We need to “sell” this better.

There are a lot of other revolutions coming according to Tim. And I do think we’re looking at big changes in terms of everything from programming language choice, to web-development tools, to end-user desktops, and data persistence mechanisms. We’re also just beginning to see what the world of high-end javascript and other “rich” internet applications is going to do to our view of end-user software.

He doesn’t even mention the rise of EC2 and the Google App Engine as sea-changes in the way we buy computational resources, and I think that’s going to have a huge impact.

In the end my prediction is that the way we develop applications will change more in the next 5 years than it did in the last 5, and it’s time to start getting our heads wrapped around these issues, or we’ll be left behind.

If stress is a weed, urgency is the seed.

–Jason Fried

Just the other day a project manager I know asked me how she can “instill a sense of urgency” in her team. She wants to get more done, and get it done faster. Increasing developer productivity is a laudable goal. And she is being asked by internal and external customers for more and more stuff.

But I think there’s something wrong with the question. Urgency and “time pressure” are viewed as tools which can increase productivity. And I think this is wrong. But, it does work — in the short term.

In the long term motivation, tools, skills, and processes along with things like good unit test coverage, and good “architecture” determine productivity. Constant urgency, looming deadlines (particularly if they are artificial), and constant pressure actually hurt motivation, remove the slack required for building tools, discourage process improvements, and create all kinds of technical debt. This debt can be measured in terms of decreased test coverage, and “short-cut” coding techneques which undermine good architectural choices.

To put it more bluntly, urgency often produces short term results at the expense of long-term productivity.

If you push the question a little bit, as I did with my friend, you will usually find that the problem is not a lack of urgency, it’s a lack of motivation. Motivating people is hard, and if they have been burned out by too much “urgency” it just gets harder.

I’ve done it too. But now-days when I hear people pushing a “sense of urgency” I take it as an opportunity to start looking for deeper motivation issues.

But, in spite of 30 years, and thousands of pages written, people still don’t get it.

Up until Monday I was working on a suite of fantastic applications for patient data and hospital management. I was part of a small, but very talented team of developers doing amazing things. Sure we had great tools like Python, Ext.js, TurboGears, etc. But the fundamental reason we were so successful is that we had a great team that worked together really well.

How do you know you’ve got a great team?

Chad Fowler’s very good (but very poorly titled) book My Job Went to India: and all I got was this book has a chapter explaining how before he became a programmer he was a musician, and someone gave him this powerful advice:

“Always try to be the worst player in the band.”

If you seek out people who are better than you, people who will push you — people who will make you grow just to keep up — you won’t have the option of stagnating. You either get better, or you get out. That’s how I felt on this team, and I know it’s how we all felt.

We knew each-other, knew our strengths and weaknesses, and we knew that together we could make things happen. We knew how to challenge one another, and if something went wrong, we would take action to fix it as a team.

Great teams are a huge asset

I can honestly say that it was the best team of people I’ve ever worked with, and we were producing products with real revenue attached — in other words, we were making money, and lots of it.

But as you can probably guess, after the acquisition came layoffs. And the team was chopped in half. Even though the team consisted of the best developers in the company, even though we were the most profitable part of the company, even though things were going amazingly well in our little corner of the world — we were still torn asunder by layoffs.

There may be some higher corporate logic behind this. And perhaps at some level it was the right thing to do, though I doubt it. I am convinced that Lister and Demarco are right is arguing (via peopleware) that a “jelled team” is an incredibly valuable resource for a company. They get stuff done, and get it done quickly, because they already know how to work together well. We cared about one another, cared about our work, and cared about our company, we were motivated, skilled, and we got things done. Loosing that is loosing a lot.

I got lucky

I was fortunate enough to be the newest member of the team, and was one of the folks that was let go. Why fortunate? Because I don’t have to sit around every day trying to get stuff done without the rest of the team, because I don’t have to be reminded every single day of what once was, but is no more.

And because I can take this opportunity to take a breath, look around and try to find a job which fits my long term goals. I don’t know exactly what I want to do yet, but I do know that I want to do something good for python, something good for the world, and something where I get to work with great people.

So if you’re interested, feel free to drop me an e-mail (mark.mchristensen@gmail.com).

Please hire these guys — they are amazing!

But more importantly there are some other great developers who are also looking for jobs. I’ve seen them perform miracles in C#, Java, Python, and any number of other languages. And I know them well enough to know that they would each be a huge asset to any company who’s looking to develop a great team.

One of the things you need the most in team development is someone who has a picture of how it could be better, of what’s possible, and the will to make it so. In addition to their technical skills, I know that’s something they all have. So, if you’re looking for one or more highly skilled software developers in the Atlanta area (or you’re willing to work with remote people) I can’t recommend them highly enough. Please send me e-mail if you’re interested and I’ll pass the info on to the right people.

I’ve created a page on the Wiki for Sprint Organization tasks: http://docs.turbogears.org/SprintOrganization

If the sprint goes well it could get us very, very close to the point where we could reasonably do a TurboGears 2 technology preview release.

The main things we’ll need to do is sync up with the latest pylons, improve our tests, and do some basic doc organization work (migrate some information from the doc strings to the docs wiki, and create some pages which link to external docs). There’s lots of other things I want to do like improve out user authentication/authorization/registration support, or create a toolbox tool for helping create SQLAlchemy models. So, there’s tasks for anybody who can lend a hand.

If you’re available and want to help out (either attending physically or virtually), feel free to add your name to the wiki.

Likewise, if you can host a in-person sprint in another location, please feel free to edit the wiki with that information.

Motivating people is hard, but de-motivation i s easy, and that’s the subject of Esther Derby’s article on CIO.com. I’m sure we’ve all experienced some of the core de-motivational techniques she describes:

• Surprises at your annual employee review
• Constant Micromanagement
• Public criticism
• Being asked do do one thing, and evaluated on not doing another
• Being given unachievable deadlines
• Being asked for input and then having your input ignored
• Having coworkers receive preferential treatment
• Being treated as untrustworthy, or as an outright criminal

I’ve had managers who called employees names in public, who gave job requirements with no warning, who played favorites with particular employees, and who lied (or at least fuzed the truth) about important company metrics to make himself look good. Heck, that was all one manager! (And if you think you know who this is, you’re probably wrong, unless you’ve known me for a long, long, long time.)

I had another manager who ran a morning company wide “motivational” meeting every day, and who used that opportunity to threaten to fire each and every one of us, if we didn’t do all of a dozen sometimes contradictory things.

The best thing you can do in those kinds of pathological cases is to move on. But in other less extreme cases, you may be able to help your manager understand why her motivational strategies might be backfiring on her. I’ve had success with saying:

Hey, do you have a min. to talk about something that will help the whole team work better?

I’ve noticed that my ability to stay focused and motivated is being impacted by something that happened at our last team meeting. And I’m afraid others may have had the same reaction. I know we really want this project to succeed, and I don’t want to let this get in the way.

You’ll remember that Mary was out sick, and you joked that she would jut bring up bad news anyway… Well, that kind of thing makes me think you won’t handle bad news well, and makes me less likely to bring bad news to you right away. And I don’t want that, since I’m sure that limits your ability to help us to problem solve….

The key things to remember are:

• Establish that you’re trying to help with something they care about, not to attack them
• Raise one issue at first, don’t make this about a pattern of behavior — that’s harder to admit to.
• Don’t use emotionally charged words, just present the facts as they happened
• The let your boss know how you interpret those facts,

These kinds of social confrontations can be very hard for us programmers, but they really can make a difference in our working environment, and can improve our teams.

Learning to handle conflicts well is just as important as learning to catch exceptions in untrusted code. Failing to do either one, is likely to end up with things blowing up at random times in ways that we can’t control.

Once, long ago, I worked with a company that was struggling to attract top notch people in a very small field. The were constrained by the number of people they had, and the were loosing good people, who were hard to replace. So, they wisely decided that they needed to to change their corporate culture, and to make themselves a more attractive place to work.

Their primary tactic in achieving this strategy was to publish a new “company values” statement, and adding “cool” to the list of criteria by which employees were judged at review time. Figuring that if their employees became cooler, people would be more attracted to working with the company. At the same time they also hosted “mandatory fun” activities outside of work hours, on top of the mandatory overtime, and near-constant travel, which was the norm for many of their employees.

At the same time the manager, who was the force behind this, continued to speak condescendingly towards others he perceived as “less valuable” in the organization and was well know for his political games, and his “me first” attitude. This lead to widespread fear that the subjectivity of the “cool” rating was just an attempt to provide material for weeding out the “undesirable” employees.

Needless to say, their attempts did not earn them a worldwide reputation as “one of the most fun places to work.” And many people who felt their contributions weren’t valued left, and they told stories which made it even harder to find people in their small field.

If you want to change your corporate culture, you have to change the way people think, the way they feel, and the way they behave.

Changing people is hard. Rearranging words on paper is easy. Smart companies don’t confuse the two.

If you want to effect real change in an organization:

• Start with changing yourself. You are part of the culture, and if you are a leader people are watching what you do more closely than what you say.
• Be honest with yourself and with everybody involved about the problem. Take responsibility for your part what’s gone wrong.
• Ask people to join you in the hard work of making things better.
• Continually look for the reasons behind people’s resistance. Perhaps there’s a lack of trust, perhaps the your words are saying one things, and your actions are saying another.

Honesty, openness, and ability to communicate a vision of how things could be better will get you a long way. But you also need to be prepared for resistance, and you need to learn from that resistance. As Jerry Weinberg says:

“Overcoming” is not what you want to do with so-called resistance. What you’re calling “resistance” is what it looks like to you when [people] don’t feel safe following your suggestions. So, what you want to do is learn from it–it’s a gold mine of information, as long as you don’t push to “overcome” it.

Another thing you might want to consider in that most negative corporate cultures trickle down from the top. Contempt is the sulfuric acid of organizational change, it creates defensiveness, super-charges resistance, and corrodes working relationships.

So, if your managerial team shows any traces of contempt, you might want to do is buy a couple copies of Bob Sutton’s new book “The No Asshole Rule” and slip them on a few key people’s desks.

And I think that’s the right thing to do, people are ultimately more important than processes. But, at the same time, there’s a paradox to be thought through here, because focusing your management efforts on people can be counterproductive. If you focus on people it’s easy to blame them for failures, to try to change them, and to loose sight of the processes which got you the wrong people, or which made it difficult or impossible for the right people to do the right thing.

In fact much of the benefit of the Lean/Six Sigma camps comes from the notion that you pretty much always get better results if you always assume it’s a process problem, and try to improve the processes.

The solution to the People over Process paradox is easy enough:

Good managers lead by creating an environment where people are empowered, in other words they lead by focusing on a different kind of processes. Processes which put people in charge, and which encourage learning and self-correction. That might sound hard, but really it’s not as complicated as you think. For, example Toyota has thrived by creating a “metaprocess” which gives every employee power over the day to day processes of their job. These meta-processes which make standards of work clear, and make it the team’s responsibility to relentlessly and ceaselessly continue to improve those standards. Employees are expected to think, and to act on a regular basis to improve the way things are done. And they are ultimately “in control” of the processes which govern their work.

If you focus on the right metaprocess, you won’t get into the kind of “process problems” that the agile manifesto was written to combat. Processes will be owned by the people doing the work, not imposed from above, and they will be adjusted continuously to meet the daily needs of the project.

Processes must serve people. But at the same time people following good processes — and even more importantly good process improvement processes — are more productive than people with no process. So, removing process isn’t the answer to “People over process” it’s providing people with control over the processes, and with a well defined way to improve those processes.

I think this is a pretty good description of lots of a lot of projects I’ve worked on as a software developer and project manager. Lots of Software Developers want to get the “Problem Definition” done as soon as possible, and get on to the “real work” of solving the problem. But there’s real danger there, it’s easy to define and solve the wrong problem.

I like the system they use in House — there’s a central whiteboard which contains a description of the problem they’re trying to solve. As the show progresses, the problem definition is continuously updated, and the diagnostic team comes up with various theories. I’ve worked on projects where we the developers didn’t have a clear understanding of the problem, or where our understanding of the problem was months and months out of date.

The result was that we built the software that solved the wrong problem, or in the best case, software that solved the right problem in the wrong way. Either way, what we built fit the user stories we got for that iteration, but wasn’t “well designed” in terms of solving the core problem. In both cases, it was very clear as I talked to the end users after the project was completed, that we could have spent less time, and built better software if we’d just had a clear and up to date picture of the client code.

I think a problem definition whiteboard is a great addition to the standard Agile software system, and I’ve started thinking about how to integrate this into all the projects I’m working on.

I think this is particularly important for Open Source projects with a distributed team, so I’d like to integrate this idea with the TurboGears 1.1 development process. I’ve posted Alberto’s 1.1 roadmap on the Docs wiki (docs.turbogears.org) and I’ll try to keep that as up to date as possible, and to add a very clear problem definition to the top of the roadmap.