The pies aren’t the same size

Something that’ s been hard to explain is why I think the “sprinklings” can’t, must not, be managed, even when we’re in a time crunch (are we ever not in a time crunch?). The thinking goes, “These sprinklings are great, but you probably need to postpone them till after we fix this critical defect. You need to concentrate on fixing this defect for now.”

See? We don’t have spare time sitting around to throw at these “sprinklings”. Why should we allow or encourage time to be spent on them? We’re so far behind already – we can’t encourage these “other” activities, can we? At least till we’re out of the hole?

Yes. We can. We must. Here’s why.

Doing Only the “Necessary”

Here we have a picture of where a developer spent one week of his time. In a 40-hour work week, he spent 94% of his time doing Official Stuff and 6% of his time doing Sprinklings (He felt a little guilty for doing the Sprinklings since no one had given him permission to do those things). He produced 114 DBPs* of work.

He fell behind on his estimates this week, though. Hmm. It looks like we could boost his productivity 6% by having him eliminate the “sprinklings” for now. Right? Wrong. Here’s the twist: the sprinklings didn’t take time away from his project – they’re what keeps him going.

The Momentum of Flexibility

Here’s my experience. Let that same developer have the flexibility to add in those extra sprinklings using his own judgment, and here’s what will happen (at least if he’s me):

In the following diagram, given freedom, the developer has now spent 56% of his time on Sprinklings and only 44% on Official Stuff. WHAT?! We can’t afford that kind of waste, can we?

But wait, look, in this same week he produced 745 DBPs of work. He was six-and-a-half times more productive, even though he only spent 44% of his time “on-task” as opposed to 94% time-on-task in the other scenario. (And he didn’t feel guilty – he knew what he was responsible for and was accountable for that).

Is This Realistic?

I admit it – I made up all these numbers out of my head. But I know that personally, when I’m discouraged and feeling that my hands are tied, it is so hard to be productive, and when I’m feeling free to do the Sprinklings along the way, I also get more done on my Official Stuff. It really does make a difference if a developer feels empowered or bound!

What do you think, developers? Does this match your experience (or is this “pie in the sky” ?)

Is this phenomenon limited to developers?

*Development Battle-Points

Stop feeling like a victim and do exactly as I tell you

Up to this point, I have not been able to pinpoint where the discouragement is coming from (I think the closest I got was with the allegory). But yesterday there was a breakthrough: the concept of a freedom and responsibility setup versus a “command and control” approach. That second term really describes what we have right now. I just ordered a book about a different approach and how you get there, titled Accountability: Freedom and Responsibility without Control.

A couple of quotes from the book:

A control-based workplace is 10 percent coaching and mentoring. A freedom-based environment is 60 percent coaching and mentoring.

There are people working for you right now who want desperately to make a difference, but many of them, because of the control-based environment in which they work, have lost their interest and enthusiasm.

Does that second quote resonate with anyone else?

The weird thing

The last few days I’ve been working at trying to understand and articulate where the discouragement is coming from here at work. Why do good developers keep leaving? Well, because they find brighter-looking alternatives. Ok, but why aren’t we the brighter opportunity? Why do people feel they have to leave to pursue that opportunity?

Perhaps the other company only looks better (when really it has the same issues)? Or maybe they’re just discontented people?

I don’t buy it.

Programmers I admire and respect are getting discouraged and leaving the company for reasons I bet they can’t always completely articulate, and I haven’t been able to clearly articulate the nature of my discouragement either. So I’m trying to figure it out. In the movies it’s always easier to fight the invisible monster once you figure out a way to make it un-invisible. That is what I’m trying to do.

So anyway, the weird thing is, I’m spending all this time thinking about this issue and yet I’m not falling behind on my regularly assigned work. In fact, now that my mind is going on this peopleware-type stuff, I think I’m actually getting more done on my regular work than when I was merely discouraged and trying to stick to just doing my job! I guess this is not a zero-sum game.

One more weird thing: It’s kind of odd to be applying problem-solving skills that I’m used to only applying to software, to people issues. It’s also kind of cool though.

Will I be part of effecting an important change at my company, or be fired? (Maybe everyone who ever tries something big wonders that.)

Top performers

Statements

1. A top performer needs the flexibility to use the “sprinklings” each day that keep him or her sharp and motivated.
2. Having to defend each sprinkling kills hope for a top performer.
3. A top performer has demonstrated that their way works, so it only makes sense that instead of demanding a justification for each decision, we should be learning from their example.
4. The trust (on a company’s part) involved in not requiring such defense is part of identifying someone as a top performer.
5. The question is, am I in that group?

Questions

1. Does this need for flexibility apply only to top performers?
2. When we deny a developer the flexibility to do day-to-day “sprinklings” on their own initiative, are we keeping them from becoming a top performer?
3. What are the challenges to an organization wishing to give flexibility to some but not others?
4. If you give flexibility to all, how do you deal with the lower performers whom you cannot trust to use the flexibility wisely? For such people, to what extent does the tighter structure help them produce acceptably (in other words, to what extent is the tighter control having its intended effect in the cases where it’s seen as needed)?

(Updated 1/14/2008)

The hidden assumption

The hidden assumption: that the level of work I’m doing when I am free to improve things is the same as when I lack such freedom and feel that my contribution to the company is not what it could be (with the accompanying loss of hope).

The assumption is that if we take out all the sprinklings* we meet our deadlines faster. But it’s those sprinklings that keep me going, otherwise it could take me a week just to put together a simple design doc! It’s another one of those upside-down things. How can more classes be simpler? And then in this case, how can spending fewer hours directly on a project make it quicker to complete?

Being able to defend and explain these things is a separate skill from being able to do them. I have more of the second, very little of the first.

——–

*What I’m calling “Sprinklings” are the things we do each day to improve our craft.