I just heard that a group of people is working on a CMMi-like framework for Agile Product Management. And of course there’s the Agile Maturity Model. And various surveys to assess Agility.

“Maturity” and “agility” are the wrong things to measure.

Level doesn’t matter.

Results matter. Year-over-year improvement matters.

I’ve seen plenty of companies that assessed at some vaunted level, but still produce crappy results and still grind engagement and creativity out of their employees.

“Maturity” and “Agility” are proxy measures have the same risks as all measures: they focus attention on the wrong things and often drive behavior that’s counter-productive.

Focus on doing better every day. Practices help you do that. Removing organizational impediments helps you do that. Improving skills does that. Improving the quality of management does that. Improving team capability does that.

Esther Schindler recently put forward a scenario about a struggling employee named Frank, and solicited advice from her network.

Briefly, the scenario is this: Frank was a great maintenance programmer, but the company is retiring the system he worked on. Frank has moved to a new project in a new language and he’s not catching on. (Full scenario is here.)

The Other Esther summarized the advice she received in When the Job Changes But the Programmer Doesn’t and When the Job Changes But the Programmer Doesn’t Part II: Saving Frank’s Job.

My full response (excerpted in Esther Schindler’s posts):

It sounds like Frank has been a valuable employee. But now he’s in a position where his skills and preferences aren’t a good match for what the position requires.

So first, I’d think about whether there is a way to make use of his maintenance programmer skills on the new system. Can he fix bugs? Can he contribute domain knowledge in some other way?

It’s not unusual for people who are learning a new skill to follow rules rigidly. They haven’t internalized the new knowledge to the extent that they can see possibilities and use the skill intuitively.

The scenario doesn’t say how Frank has gone about learning the new language. Pair programming can be a great way to learn, and pairing a beginner with an expert can be enlightening for both.

I’d also look at how the work is chunked up. It may be that if Frank broke the work down into more discrete 1-2 day chunks he’d be able to make better progress.

If there’s no way to use Frank’s skills, then Frank’s manager needs to have another forthright conversation with him, explaining his expectation and concerns, and hearing Frank’s point of view, as well. Chances are pretty good that Frank is as distressed as his manager is.

But before the meeting, Frank’s manager needs to decide if he’s willing to give Frank another chance, or give him time to find another job within the company. If not, get the ducks lined up with HR to end Frank’s employment.

If Frank wants to try once more to get up to speed, they need to agree on a plan with specific actions. They need to agree how they’ll evaluate whether Frank is making the kind of progress the job requires. And the manager has to put a time limit on it–weeks not months.

If Frank recognizes that he’s just not in the right job, and he’s an employee that can still make a valuable contribution somewhere in the company, set a time frame for Frank to find a job internally–weeks not months. Start looking for Frank’s replacement. If Frank hasn’t found an internal job by then, end his employment.

If Frank isn’t a good candidate to stay at the company, don’t let the situation drag on forever. The current state is painful for everyone. And while firing Frank will probably be painful, it won’t be as difficult as the alternative.

A couple of things to emphasize:

Allow weeks not months to turn the situation around. That means 2-6 weeks, no more.

Choose based on how big a hit you can take on the project. Look at the trade offs. Some times no body is better than a warm body. If working with Frank is taking significant productive time away from others for little potential return, 0 weeks is the right answer. As Jerry Weinberg asked, “Is this a business or a charity?”

If Frank can be valuable to the company, but not on your project, set a time frame for *Frank* to find a new job. You are not a job placement service, and not your job to find him a new assignment. It’s Frank’s job to find that next assignment. You can offer to introduce him to people or give a reference, but Frank needs to do the work. And set a time limit 2-6 weeks, no more, depending on your project needs. Do not wait until Frank has found a a new assignment to start looking for his replacement.

Peer feedback is a core skill for collaboration. It’s impossible to work closely with out running into some bumps: differences, disappointments, and disagreements. Peer to peer feedback can help keep working relationships on track and improve results (and it keeps the manager out of the transaction so it doesn’t be come a *big deal*).

I teach about feedback in both my team collaboration workshop and management workshops. “But does it work in the real world?” some ask. Ola Ellnestam blogs How I Learned about Feedback.

Building trust may seem mysterious… something that just happens, or grows through some unknowable process. Like many things, there are concrete actions that tend to build trust (and concrete actions that are almost guaranteed to break trust down).

First, a definition of trust in the workplace. We all know that trust is the foundation for teamwork. But to hear some people talk about it, you’d think team members were getting married, not creating software together. What we need in the workplace is professional trust. Professional trust says, I trust that you are competent to do the work, that you’ll share relevant information, and that you have good intentions towards the team. Taken broadly, that’s trust about communication, commitment, and competence.

1. Address issues directly

It’s inevitable that some person on the team will rub another person on the team the wrong way. Maybe it’s they way he cracks his gum, or listens to voice mail on speaker phone. Maybe it’s using your laptop and changing all the preferences. Maybe it’s breaking the build and then leaving for lunch.

These frictions are inevitable. When a team member speaks directly to the person who is bugging him, he builds trust. Raising an issue says, “I value our working relationship, and I’m willing to have an uncomfortable conversation to make it better.” It says, “You’ll know where you stand with me; I won’t be talking behind your back.”

These conversations aren’t always easy. Sometimes people delay the uncomfortable discussion until the situation becomes intolerable, letting anger and resentment build.

Sometimes people try to avoid the difficult conversation by telling their manger about the problem. And sometimes the manager falls into the trap of carrying the message. Seth had just started a new job and hadn’t really made friends with anyone on the team yet, so he spent is lunch hour alone. On his second week on the job, his new manager called him in to inform him that another team member resented the amount of time he was taking for lunch, since 45 minutes was the unspoken rule.

(I do wonder why no one bothered to tell Seth this, and why no one invited him for lunch in his first week on the job, but that’s another issue.)

When his coworker talked to the manager instead of talking directly to Seth, he broke
trust. When I talked to Seth, he’d been at that job for over a year, and still didn’t fully trust his coworker. No one likes a tattle tale.

When people don’t know how to have difficult conversations…or think it’s not their job to navigate working relationship, trust erodes. And that’s why people need a framework to talk about interpersonal feedback.

2. Share Relevant Information

If you don’t support an idea or approach, say so. (Of course, there are more effective and less effective ways to do this.)

When someone on the team withholds and opinion or concern when a topic is under discussion and then comes back later to say “I thought it was a bad idea from the start,” other team members feel blindsided. That breaks trust.

Relevant information is about the task, but it’s also about you. People tend to trust people they know as individuals and can identify with. Shared experience, shared interests and identification form solid ground that people can land on when there is friction and conflict. You don’t have to share your deepest secrets, but letting other people on the team know something about life outside work makes people “real.” It’s hard to trust a cipher; much easier to trust and be generous with someone who shares some of the same challenges and interests that you do.

In order for teams to function, team members need to believe that their co-workers are reliable. Without the confidence that others are reliable and will carry their share of the load, few will commit to a shared goal.

3. Follow Through on Commitments or Give Early Notice When You Can’t

No reasonable person expects that every person can meet every commitment all the time. We know that sometimes a piece of code turns out to be more complex than anticipated or we discover we didn’t fully understand the task when we made our estimate. But when you wait until the moment the task was due to let people know it’s going to be late, it breaks trust. So let people know as soon as you know, and renegotiate.

4. Say No When You Mean No

Sometimes you just can’t take on another task, or do a favor that someone asks for.
But most of us are programmed from an early age to please other people. If we say no, we’re called selfish or “not a team player.” But if you really can’t do what’s asked, it’s more respectful to say No and let the other person get on with getting his need met elsewhere.

Saying Yes without follow-through leads others to doubt your word. If you can’t say No, your Yes won’t mean anything.

It may seem paradoxical, but building competence trust sometimes means admitting that you don’t have all the answers.

5. Show What You Know and What You Don’t Know.

Be generous in sharing your knowledge (without inflicting help). But also be willing to hear other peoples ideas, build on them, and help others shine. Admit when you don’t know the answers; there’s nothing worse than a know-it-all who is wrong. Ask for help. That helps other see you as a real person, and people generally like to be helpful.