Compound Thinking

TurboGears 2 sprint

I’ll be hosting a TG2 sprint here in Ann Arbor Michigan on October 27th, hopefully we’ll also have a large virtual presence from folks around the world.

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.

Motivation, Demotivation, and Constructive Conflict

If you hire people who actually care about what they do and structure things so that people actually get to do what they are good at, you’ll find that people have motivation that goes beyond getting a paycheck.

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.

Changing Values

It’s hard to change your corporate culture, because it requires changing the way people think, feel, and act. And smart people can do really stupid things when they try to change other people.

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.

An Agile Paradox: People over Process (part 1)

The agile manifesto says we focus on “people over processes”.

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.

Diagnostics, Problem Definition and “House”

There was a “House” marathon a couple weeks ago, and I caught a bit of it while working on some projects around the house. As I watched it became pretty clear that every episode is built around solving a complex medical problem. And 90% of the show is spent learning about the problem, finding new pieces of information, and testing incorrect assumptions.

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.