No is in the air

A while back, Slacker Manager bemoaned micromanaging colleagues who over use "call colleague X" as thier next action (a la David Allen).

And that got me thinking about saying No.

Most of us are inclined to accept any task that comes our way at work-- whether we have the bandwith to do the task or not. We take on tasks because we don't want to disappoint people.

But we do end up disappointing people when our Yes doesn't mean anything.

There are alternatives to a reflexive Yes:

Not now, at some later time.

Not by me, but another co-worker.

At this time, if you are willing to help me with ________.

At this time, instead of __________.

These answers present the possiblity of a choice or negotiation.

When someone says Yes without a clear plan to accomplish the task, the other person waits hopefully (or impatiently) as their options for getting the task done dribble away.

When you can't or won't do something, saying No allows the other person to move on to find some option that will work. (Jeffrey Phillips talks about Getting to No --via Frank Patrick-- as failing fast... and then moving on to more productive.)

So why is it so hard to say No?

Many of us have Rules about saying No:

Always cooperate.

Always be considerate.

Always be helpful.

Treat the boss and his requests with respect.

(fill in your rule here)

(For ideas on transforming rules, look here.)

Some of us don't know how to say No in a way that doesn't feel mean. Try a one of the alternatives to a relfexive Yes, or Satir's Soft Spurn (from Jerry Weinberg's More Secrets of Consulting):

Show appreciation
Give a regretful No (but no excuses)
Make an opening for some future relationship

"I'm flattered that you'd ask me. Unfortunately, I'm unable to do that at this time."

If you can't say No, your Yes doesn't mean anything.

(Jerry will be leading a session on choosing Yes or No at the Aye Conference in November.)

Looking for Clues about Culture in the Hiring Process

A colleague applied for a management job at a large national organization -- 2 months ago. Aside from a form email acknowledging receipt of his application, he hasn't heard a word.

There's information about the organization here. Were I in this position, I'd be wondering:

What does this say about how this organization makes decisions?

Is the speed of this process typical?

Are the managers in this organization pushed to the wall for time?

How does this organization treat the "wait state" and what effect does that have on interdepartmental and external relationships?

Is "hurry up and wait" a pattern in this organization?

How does this organization treat people?

Every organization reveals something about its culture in the hiring process. You just have to look.

a peer feedback example

Last week I wrote about peer-to-peer feedback. In response, Liz Keogh offers her story here.

It almost always works better when peers resolve their own issues, even when the issues are socially awkward. Had Liz taken this issue to the MD, I suspect the outcome wouldn't have been as good, and might have been very, very bad.

So even when with an issue like this, talk directly to the other person before escalating.

Blurring job boundaries

Zhiyi Zhang wrote in a comment posted on 6/10:

"I realized that I can't do a good job if I keep wearing multiple hats...
It's quite possible that management pushes to that extreme in the name of agile, knowingly and unknowingly."

This is a good point.

In my view, there's a difference between blurring job boundaries, and taking on multiple roles.

Suppose we have a company, BigCo, were there are software designers, UI designers, UI programmers, middle ware developers, and database coders. Software designers create designs the application layer. UI designers create the UI design. UI programmers only code the UI, middleware developers only work ont he middleware and database programmers only concern themselves with the database. Each does tasks within a that narrow band. There are lots of hand-offs, and groups have to coordinate with each other (but they're not always effective, and people end up waiting for another group to complete their work).

Blurring the job boundaries would mean that a sw designer also codes, a developer also writes database queries, etc. People may have specialties, but they also have skills in the other areas. Each team has the skills it needs to build a functional slice of software.

When I talk about blurring job boundaries, I'm talking about moving on spectrum where specialist is one one end, and generalist is on the other. But the spectrum focuses (at least in this discussion) on creating working software.

It's harder (and less effective) to juggle multiple organizational roles -- from project manager to developer to operations support tech.

Job Boundaries

On Agile teams, traditional job boundaries start to blur. Testers are more involved during development. Developers write tests. Testers and developers help with documentation. Team members pitch in to do what needs to be done. And in this process, they broaden there skills. People don't lose specializations, but they become more generalists.

This is a good thing.

Static functional job boundaries have (at least) three downsides:

People focus on doing their *job* -- as defined by a functional specialty-- instead of doing *what needs to be done.*

People learn within a narrow focus rather than learning about the big picture or how their works translates to providing value.

It's harder to adapt to change.

Cross-functional teams, OTOH, can adapt more quickly, see the system more broadly, and learn across functional boundaries.

Accountability

A friend of mine reminded me of a little article I wrote a few years back.

And it seems timely to bring it up again: "Accountability" is one of those words I hear a lot in organizations where things aren't going very well. Everyone wants some one else to be "held accountable." It's usually a code word.

Decoder here.

Back online

I'm back online. Blogger seems to work just fine with the new hosting provider, Pair Networks.

I did try to resolve the issue with my previous hosting provider -- and found their trouble ticket process fascinating. Each individual response was timely and polite. And as part of each response, the technician closed the trouble ticket....whether or not the trouble was solved (it never was).

I'd send something like:

"I'm having trouble FTPing to my website from Blogger. Here's what I've tried: X, Y, Z.

I can access my site using FTP from my local machine, but not when I try to FTP via Blogger."

I'd get a response like:

"X, Y, and Z work. We have also tested FTP to your site. We were able to add a file.

Trouble ticket closed."

Then I'd reopen the ticket, pointing out that the problem was still unresolved.

Bet these folks are being measured on the time the trouble ticket is in the queue and how many tickets they close.

Peer-to-Peer Feedback

I talk to a manager who had attended one of my feedback workshops.

One of his staff members had come to him complaining about another team member who had a habit of eating cookies when they worked together, and was getting crumbs all over his desk and keyboard.

Prior to the workshop, this manager would have listened to the complaining staff member, then gone to the crumb-making staff member and had a chat.

But this time, he did something different. He told the complaining staff member that he need to address the issue directly, and gave him coaching on how to deliver the message.

In essence, he took himself out of the middle. This is a good thing. When ever possible, issues between peers are best addressed between peers. Bringing in the manager immediately escalates the emotional content of the feedback. And bringing in the manager erodes trust -- no one likes to be tattled on.

It can be uncomfortable to give peer-to-peer feedback. But learning to do so has benefits in building trust and handling issues when the are small.

For some guidelines on peer-to-peer feedback, read my little article on stickyminds.com.