This team leader was not doing her job

I came across this story on Roy Osherove's blog (via Laurent Bossavit on the AYE Wiki).

Roy describes his experience solving a technical problem that took longer than expected:


After showing this to my team leader and getting a fairly lukewarm response I headed home for the weekend. When the start of next week came I was seek and when I came back two days into the week my team leader asked to see me in her office.After I sat down she said:

"While you were away Me and another person from the team were talking about your work and we were wondering if there wasn't a better way to solve the problem than the way you solved it. So, when the week started we sat together and found a different way. It took us about 2 hours. It is simpler, it takes about one tenth of the time your solution takes and it's totally quiet."

Needless to say I was shocked to hear this. There I was, slaving away at a solution for almost 3 weeks, and they go and find a much better solution in 2 hours without even telling me....



Roy draws some lessons about the responsibility around communication for both team members and leads.

I agree that both team leads and team members share responsibility for communication about status, new information, and roadblocks.

And it doesn't happen by accident. Team leads and managers need to put the structure in place to enable and ensure that communication happens.

If your a ScrumMaster or XP coach (or it fits for the way your team works) use a daily stand up to find out what's happening.

Ask these three questions:

What have you accomplished since the last meeting?

What do you plan to work on in the next period?

What's getting in your way?

If you're managing a team, hold weekly one-on-one meetings. These are private meetings were you meet with each team member to track progress and uncover obstacles.

In a one-on-one you can coach, too. In a similar situation, I would have suggested that the team member come up with at least three candidate solutions and present the pros and cons of each before diving in. And I would have set a trigger to review whether the work was taking longer than anticipated so we could reassess.

If Roy's team lead had been using either of these techniques (or even stopping by for a significant conversation) the situation wouldn't have gotten to the point it did.... and Roy wouldn't have been hung out to dry.

Johanna Rothman also has a post on making progress visible here.

More on one-on-one meetings here.

A story of quantity vs. quality (and a bit on the wonders of sleep)

This excerpt from Art and Fear showed up on Chris Corrigan's blog (via Kevin Kelly):

"The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the "quantity" group: fifty pound of pots rated an "A", forty pounds a "B", and so on. Those being graded on "quality," however, needed to produce only one pot -albeit a perfect one - to get an "A". Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the "quantity" group was busily churning out piles of work - and learning from their mistakes - the "quality" group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay."

Hmmm. Sounds sort of like iterative development and waterfall, doesn't it.

Projects that use an iterative development cycle have a natural opportunity to learn from experience and apply insight to the next "pot" -- if they take the opportunity. I've seen plenty of teams working with an iterative lifecycle who keep making the same mistakes the entire project.

Of course people can reflect individually, AND the effects are amplified when a team reflects and learns together.

So hold a retrospective after each iteration or sprint.

End-of-project retrospectives tend to show up different patterns, so do a retrospective after the release, too.

And if you're working on an waterfall-ish project, don't wait till the end (though it's helpful to reflect back then, too). Find natural opportunities to reflect while the project is in-flight -- at milestones, or at a set interval..

We have a choice about what to do with our project experiences... might as well learn something from them.

And while I'm on the subject of retrospectives, I found another interesting bit, from an article on WebMD reporting on a recent sleep study:

"...sleep may help the mind unravel mysteries and gain unique insights into solving problems."

I've noticed that groups who start their retrospective one day and continue the next have a different level of insight than groups that try to finish in day. Sleeping on it does seem to make a difference, and now we've got the research to prove it.

The Cadence of Blame

One of the local NPR call-in shows featured an advocate for child protection reform this morning. I have some interest in the topic (another story) and I wanted to hear the discussion.

I found myself feeling really put off by the guy, not because of the content of what he said... it was the cadence that put me off.

He sounded like he was blaming -- it was broadcast blame, aimed at social workers, case managers, counties, child protection workers..... who knows.

I tried repeating some of his sentences in a matter-of-fact tone, and I could agree with him... but when he said it, I found myself disagreeing.

Try reading these sentences aloud:

(matter of factly) "The culture of child protection must change."

(emphasizing certain words) "The culture of child protection must change."

You could do the same with nonsense sylables and the effect would be the same:

(matter of factly) tra la la la la la.

(emphasizing certain words) tra la la la la la.

When I hear this cadence, I know someone is trying to blame someone else.

More on blame later. (It's not an effective management technique.)

Career Guidance

...from Jerry Weinberg, in an interview posted on the Borland site:

Clay Shannon: Would you recommend a career in programming to young people today?

Jerry Weinberg: It depends on what the young person wants to do. I always give the same career recommendation: "Do what you want to do."

CS: What courses would you recommend they take? What languages/technologies should they key on?

JW: They shouldn't key on languages and technologies. They should key on learning to communicate, to think, and to work well with other people. Once they have those, the languages and technologies become simple matters. Without them, no amount of language or technology expertise will do much good.

CS: Which software project/product that you have participated in are you most proud of?

JW: I'm proud of all my work, and I don't participate in projects whose product I wouldn't be proud of.

Speaking Up

I came across this piece about having tough conversations with your boss at the Fast Company site.

The article suggests you ask these three questions before you launch:

Have I focused on reality?

People often put off having difficult conversations (and not just with the boss) because they're afraid of what might happen. When you're planning your approach, think off the range of responses. The article suggests you concentrate on the probable response, not all the possible responses.

I'd add that it's useful to identify the response that's your worst fear ("He'll fire me" or "He'll hit me") and see if you believe you could survive that. (You can.)

My experience is that my fear (Fantasy Experienced As Reality) about the conversation are almost always worse than the actual event. And the pre-conversation anxiety is more uncomfortable than the conversation.

Why am I having this conversation?

I'd rephrase this question as "What do I want to have happen as a result of this conversation." This is another chance for a reality check, and knowing why you are having the conversation will help you focus and develop your approach.

Am I going to inflame the discussion?

The article suggest using neutral language and gives two examples:

(accusatory) 'You say completely ignorant things from time to time that indicate to me that you're a racist.'

(neutral) 'You say things from time to time that make it sound as if you don't respect me.'

I think we can do better than this.

I tried to put myself in the place of someone hearing the "neutral" sentence.

In the first part of the sentence, I'm wondering "What did I say? What the heck is he talking about?" When I hear the second part of the sentence, My reaction is "Of course I respect you!"

Hmmm. Probably won't get you the open dialogue you want.

Start by staying the the "I" position -- stating what you saw/head and how you responded -- rather than stating your interpretation of the other persons motivation or intent. Ascribing feelings, motivations, or intentions is seldom helpful, and often puts the other person on the defensive.

How about:

"When I heard you say blah, blah, blah, I was upset by that. Can we talk about that?"

Then follow with:

"When you said blah, blah, blah, I felt like you didn't respect me, and I bet that wasn't your intention."

Jerk is not a protected class

Beverly Kaye of Love 'Em or Lose 'Em fame has a post on Fast Company, Jerks at Work. It's about bad bosses.

Here's an interesting stat quoted from "Monster Managers" in American Way:

42% of US workers reported incidents of yelling and verbal abuse in their workplaces.

Yikes!

I had a boss once who yelled, publicly upbraided, threatened and generally bullied people. Her behavior took a toll on productivity, morale, and our health. And guess what -- we left.

She's not the only manager like this I've met. I think managers who behave this way fall into two categories:

1) They believe this is acceptable management behavior. They seem to be of the "workers are lazy and you must hold their feet to the fire to make them perform" school of management.

2) They have significant difficulties in the arena of self-management. These bosses seem unable to manage their own emotional responses and actions.

This isn't a matter of style... it's a business issue. Abusive behavior stifles creativity, kills morale, and dampens productivity. These are all hard to measure... but it's easy to measure staff turn over. If people are leaving in droves (or no one internal will willingly transfer to that managers group) it's a clue.

A little survey of what bad-boss behavior would drive you out the door here. I had a hard time limiting myself to only 5 jerk behaviors that would send me out the door.

Belittling people in front of others, lying, and condescending are in the lead.

B = f(P,E)

Kurt Lewin (links related to Kurt Lewin's work here) shaped modern thinking about psychology and groups dynamics and stated (pithily):

B = f(P,E)

Behavior is a function of the person and the environment.

Let's assume that the Behavior in question is related to work performance.

A lot of the focus in organizations is on the Person -- his/her knowlege, skills, characteristics. If we can hire the right person or impart the necessary knowledge, skills, and qualities, we'll achieve the desired work performance.

I think this is very important and necessary (I'll use this opportunity to plug Johanna Rothman's hiring book again). AND, you can have the perfect person for the job, and if the Environment inhibits reasonable work, you'll get minimal performance.

Roadblocks in the environment can be:

cultural norms

infrastructure (lack of supporting resources, tools, policies, management...)

infrastructure (presence of punishing policies, management, reward structures...)

So as manager, you need to pick the right people for the job and then remove the environmental obstacles....as David Foster pointed out in a comment on this post.

Making Unclear Requests

I came across this example of a request on Ned Batchelder's weblog (along with some advice on asking for help.)

Hey, I'm in a hurry, so this isn't going to tell too much. I was having problems with your cursors pygame code. See if you can see what's wrong/fix it. I need to leave the office, see you later.

I think this qualifies as an unclear request.

Presumably Ned knows who the speaker is, and Ned is the recipient.

We can assume that both Ned and the requester share some understanding of "cursors pygame code."

But that's about all that's clear.

What action will satisfy the requester?

What time frame is the requester assuming?

Ned is left to guess at:

The behavior of the software that leads the requester to think there's a problem.

What steps the requester has taken to solve the problem or work around the problem.

Why the behavior is a problem for the requester.

What a successful solution would look like.

When a solution is needed.

What -- if anything -- the requester is will to do to aid Ned in finding a solution.

(This reminds me of many bug reports I've read over the years.)

When I received a request like this face-to-face, it's easy to ask questions to get the answers to the questions above.

But when I receive a written request like this (or a voicemail), I feel annoyed:

... so what am I supposed to do? Start looking through 10,000 lines of code trying to find problems and maybe I'll find the one you were thinking of? Right!

And that's where the viral effect comes in.

If I take up this request, I may feel annoyed or put upon. I may not want to help the requester. I may make judgments about the requester (What a jerk! Does he think I'm a mind reader? Does he think I have all day to guess what his problem is?)

When this sort of breakdown in communication happens repeatedly, relationships suffer.

As a requester, make sure you include all the elements of a request. Include:

information to create a shared understanding

what you want action will satisfy you

when you need it.

As the recipient of an unclear request, ask for clarification on these elements.

And if someone repeatedly makes unclear requests, make a request of your own: request that the speaker include specific information that will help assess the request.

Linguistic Viruses, Part II

More linguistic viruses that spawn much misery. The good news about linguistic viruses is that we can choose to stop them in their tracks.

6. Not Declining Requests

People who say "Yes" to every request tend to find themselves overwhelmed, resentful, and spending lots of time doing things they don't want to do.

Of course, this can be tricky in the workplace. Johanna and I did a session on saying No without getting fired at SD last fall.. perhaps I'll write some more about it.

The ability to say No -- decline requests -- is essential for dignity and health. And if you can't say No, you can't really say Yes, either.

7. Breaking Promises Without Taking Care: Undermining Trust

We can't keep every promise we make... the situation may change, we may fall ill, it may turn out that we didn't understand the situation... then we need to go back and reset expectations. When people don't do this step, they loose the trust of other people.

8. Treating Assessments as the Truth or as Assertions (Facts)

Budd defines an assessment as "a judgment that you make about the world in the interest of taking some action." So you might look at the thermometer, see the mercury at 16 F and say, "It's cold out." But I'd say "We're having a warm day," (because I live in Minnesota).

If many people share our assessment, we may believe it's fact, but it ain't.

9. Making Assessments Without Rigorous Grounding

Even though assessments aren't "the Truth," they are useful. How else would we judge the quality of software or the completeness of a feature? So we can ground our assessments in data and against criteria.

10. Making Fantasy Affirmations and Declarations

Budd talks about declarations as statements that bring something that didn't exist before into being... which isn't how I learned to think of declarations, but let's work with his notion.

I could say, "I'm going to post to my blog today." This is a declaration that's backed up by the fact that I have the authority and capability to follow through on. My declaration is achievable by following a set of reasonable steps.

A fantasy declaration might be "We're going to deliver these 20 new features in 3 months," when we've never even delivered 5 features in less than a year. Hope is not a sufficient strategy to achieve new goals. The goals need to be backed up with a reasonable plan of action.

Whew. I hope I don't catch any of these viruses! errr.... well, I'm human, so I probably catch them, but I hope it's only a mild case and I recover quickly.

Linguistic Viruses

I've been reading You Are What You Say by Budd and Rothstein. Budd is a physician and has a program that helps people look at how they use language and the affects health and well-being.

I really like his list of the 10 Linguistic Viruses which can wreak havoc at work and at home. Here are the first five.

1. Not Making Requests

People don't make requests of other people because they're afraid the other person will say "No," or because they believe a request is an imposition.

But a "No" is about the specific request, not a rejection of the requester. Assuming a request is an imposition also assumes that the other person doesn't have the gumption to say "No" if it is.

You're much more likely to get what you want if you ask.

2. Living with Uncommunicated Expectations

Oooooh. I really hate this virus. This one shows up when we have expectations about what other people "should" know or do without us having to tell them.

As in: "I shouldn't have to ask him for help. He should just see that I'm working on this and offer." Grrrr.

3. Making Unclear Requests

If you're going to request something, be clear on what it is.

A friend of mine asked her mother-in-law for help planning a Christmas party. Mom-in-law whipped the whole thing into shape in a day - sent out the invitations, planned the menu, arranged for the catering, etc. My friend didn't specify what sort of help she wanted and then got mad at her mother-in-law for "taking over."

Give sufficient detail so that the other person knows what you want.

4. Not Observing the Mood of Requesting

Effective requests are respectful of your dignity and the other persons dignity. A request is not a demand, nor a sniveling, pitiful appeal.

5. Promising Even When You Aren't Clear What Was Requested

Well, this is a bit of a problem in the software world, wouldn't you say?

Some people don't want to ask for clarification because they're afraid they'll look stupid. But not asking for clarification actually increases the chance of looking stupid.

Ok, that's enough for today. I'll write about the rest of Budd's Linguistic Viruses later in the week.

Growing articles

Keith Ray pointed me to Mark Forester's blog a few weeks ago. Among other things, Mark exposes his writing process, which he calls "growing an article."

His first draft is one sentence . The second draft is three paragraphs. It keeps growing at bit at a time. I love this!

I can't tell you the number of brilliant people who struggle with writing because they believe they have to have the article (book, presentation, what ever) all thought out, complete and polished before they put pen to paper.

In writing, you learn as you go and refactor relentlessly.

Maybe seeing Mark Forester's drafts will help people start putting their thoughts on paper.