Improvement requires three factors:

• Information. People need information about the context and how their work fits into the big picture. They need information from the work so they can self-correct. Without this information, systematic improvement is impossible.
• A desire to improve. Most people want to do their best and learn to do better–until that impulse is squashed. One-sided evaluations, organizational hurdles, relentless pressure strangle the desire to improve.
• Time to reflect and learn. People need time to design and implement new processes, and  practice new skills. Relentless deadline pressure makes this impossible. People under pressure are less likely to try something new, or think clearly about anything.

When one of these factors is missing, individual and systemic improvement goes out the door.

I remember sitting in a project meeting back when I worked for a Big Company. The project manager, Ted, announced the top three priorities.  When I offered a different view point, Ted declared, “You’re wrong. We decided on these priorities yesterday.”  He didn’t notice six out of eight people at the table  shaking their heads “No.”  

Ted didn’t notice the responses and reactions of people around him. He also didn’t  notice that he didn’t notice.

We all have filters. That’s a good thing–our cognitive systems can’t process all the data that’s available. But most people filter out useful information as well as extraneous information (for example, the size of loops in the carpet or shoe styles). What any one person filters depends on his preferences for big picture vs. detail processing, intake style (verbal, visual, tactile) and training.

Learning about your own filters builds self-awareness. Knowing what you tend to filter allows you to choose to ignore that information or make a conscious choice to notice it.

Ted deprived himself of the choice to notice people’s reactions. Ted was continually surprised when people “resisted” or “backtracked” on decisions. He didn’t pick up on the fact that after he made a few sharp criticisms, people stopped offering ideas.

People who lack self-awareness don’t realize their own observational biases or notice the impact of their behavior. They wonder why things don’t work well (or work well) but don’t see their part in the situation.

One relatively small action by a manager can send ripples or shockwaves through a system. Ted’s lack of self-awareness suppressed the groups effectiveness. Some people ignored Ted’s dictates and did what they thought was right–which splintered the group’s effort. Others left for positions where they could participate in solving problems rather than carrying out the managers prescriptions, driving turnover. Since hierarchy amplifies biases, it behooves people in management roles to build their awareness and find their filters.

Here are two exercises to build awareness of your own filters.

1. Work with a colleague who has different type preferences or a different sensory intake style. Make an agreement to share observations after meetings or working sessions.  What does your colleague consistently notice that you miss?  What do you miss by missing that?

Work on noticing those things that you have missed up until now.  Notice what insights you gain about yourself and the group.

2. Reflect on a recent meeting.  Did  you notice anything about the flow of conversation?  For example, in what order do people speak? Who interrupts whom, and how often?  Did you notice anything about physical arrangements? Or who is on their iPhone? Did you notice what emotions came up?

Choose an aspect of human behavior that you normally don’t notice. Then, practice noticing it.  Notice what insights you gain about yourself and the group.

If it fits for you, report back here. If you would like some help honing your self-awareness, drop me a note.

I don’t doubt that its possible to have an organization with out traditional managers. I’ve read about Semco and Morningstar Farms. I’ve talked to people who work at Gore. My husband works for a less well know firm that doesn’t have traditional managers.

But those companies didn’t get there by happenstance. They got there by design. People chose, designed, evolved practices and structures to support a specific culture. They didn’t take off-the-shelf models of functional or product based organizational structures.  They didn’t slide into typical  for people management practices, organizational structures, job levels or reporting relationships.

Most companies settle for practices shaped by management thinking of the first half of the last century–without a second thought. The language of this thinking is mechanistic and dehumanizing. It’s the language of efficiency, compliance, hierarchy, rules.

If you want a different sort of company, start with using a different language.

For example, rather than talk about “managing performance,” talk about giving people the information they need to continually improve or sitting down on a periodic basis to examine how we can work better together.  Does that feel different to you?  It does to me. Those words offer a different set of possibilities.

Because we are talking about people and complex human systems, not moving parts in some vast machine.

Last week, someone tweeted that the C-suite “gets agile,” but middle managers “resist” it. I also saw a tweet that the C-suite doesn’t get agile, but middle management does.

I don’t doubt the observations of either of these tweeters.

I have observed situations where both senior and middle managers saw the value in moving towards a team-based organization and iterative incremental delivery. In my experience, it’s a little more common for middle managers to hold onto the existing pattern. And why not? When they don’t see their place in agile they don’t embrace agile. And agile is silent on the role of middle management. Blanket statements that dismiss the need for managers or management don’t help.

Organizations moving to agile still need management, and often still need people in management roles, especially in large complex organizations. In traditional hierarchies, middle managers look up the hierarchy for direction, and focus down the hierarchy to accomplish cascading goals. When teams pull work from queues and self-organize to meet goals, the real opportunity for middle managers is to look across the organization to improve the system and develop people and teams.

So what do middle managers do when they aren’t directing day-to-day work? Plenty.

Now you see some of the things middle managers can do to help their colleagues, their managers, and teams. Do you need help shifting the role of middle managers in your organization?  Give me a call or drop me an email.

In an earlier article, I said, “Hiring new people for a team should always be a joint decision that involves team members.” After all, who has more at stake than the people who will work with the new person day in and day out?

Consider what happened when a well-intentioned manager decided to hire without involving the team. His rationale was the team had fallen into group-think and needed “new blood” to shake them up. When I visited, I found a fractured team. The new member struggled for credibility. Half the team wouldn’t speak to him. The other half of the team spoke to him–and resented their former teammates for ostracizing him. The team wasn’t stuck in group-think any more, but they were too busy bickering to get much done.

Whatever the issue–workload, projects that require specific technical or domain skills–involve the team in the hiring process. You’ll increase the chance of a good fit and gain commitment to help the new hire succeed. Plus, sharing power with the team helps create partnership.

Describing the Ideal Candidate

Teams often have a good idea about what’s missing on the team and where the bottlenecks are. They know when they no longer have the capacity to keep up with an increasing workload. Look at the current work, and the near-future work. Examine the current skills and work approach of the team. Then, work through a job analysis such as the one posted here.

Developing the Question Set

Involve the team in generating a list of questions that will reveal the candidates’ qualifications. Questions should focus on the skills, qualities and characteristics from the job analysis. Once you have a list, arrange the questions in logical groupings and prioritize them based on elimination factors along with required and desirable elements from the job analysis.

Finding Candidates

Team members may know others who are likely candidates. Activate those social networks! But don’t rely on the team to fill the funnel and sieve the candidates. Enlist HR to recruit and screen. Winnow down the likely candidates through phone screens. Bring the team back into the process when you have a handful of suitable candidates.

Interviewing

Assign one team member to each question area to avoid subjecting the candidate to the same questions over and over, and ensure all areas are covered. If the team members are sufficiently skilled, have them do one-on-one interviews. Or have a lead interviewer present in all interviews and assign a different team member present for each interview segment. The team member can ask the bulk of the questions, but the lead interviewer is there to listen for areas to probe for more information. This is a good option if the team hasn’t been involved in interviewing before.

In the United States, some questions are illegal, while some are okay if you ask everyone the same question. I don’t expect team members to know these rules. Invite your HR representative to brief the team on what’s appropriate and what is not.

You may want to do some practice interviews so team members know what to listen for, how to probe for deeper insights and recognize red flags.

Auditioning

Auditions provide a candidate with the chance to demonstrate relevant skills. Unlike solving puzzles, these auditions relate directly to the work the candidate would perform. You can ask a person to write a small function in a language he claims to know. You can sit him down in front of a product and ask him to test it (after you’ve given him enough background information so he’s not completely lost). You can ask a designer to review an existing design and add some new feature. No matter what the job, you can devise a way for the candidate to show his stuff.

Pairing

Some companies seem to think that as long as a candidate can solve cognitive puzzles and answer technical questions, they’re good to go. Technical skills are a necessity, but not sufficient to succeed in most organizations. This is especially the case when team-based work or communication with other humans is involved.

Pairing–whether to program, test or design–gives a window into technical skills and much more. More and more companies are bringing in top candidates to pair for a half or full day. You will need an NDA (nondisclosure agreement), and possibly need to cover some expenses for the candidate who is probably using a vacation day to participate. But at the end, you’ll know much more about how the candidate responds to new situations, and how he approaches problems. You’ll know how something about how he enters groups, and his ability to interact with people on the team. You’ll know whether the candidate is confident enough to ask questions, admit when he doesn’t know something and is willing to learn from others. You will avoid hiring someone who will rub everyone on the team the wrong way.

So you’ve involved team members in various ways. Now what? It depends on how much you want the team to invest in the new hire’s success.

Choosing

From a legal perspective, an agent of the company must make the salary offer and complete the legal aspects of hiring. But choosing which candidate is the best fit is a shared responsibility. Bring the hiring team together and pool the information. Check for elimination factors and see who you are left with. If you end up with only one candidate, your work is still not done.

Create a gradient of agreement to gage the level of support for the candidate. When there is only lukewarm support, keep looking. If support is bifurcated, explore the reasons for both strong support and opposition. In some cases, hearing another point of view will change some minds. But if not, move on. If you hire someone abhorrent to one member of the team, you’ll have problems in the long run. (Of course, if there is someone who is opposed to every candidate and has no credible reason, you’ve got a different problem.) Strive for consensus–you want the team to support the person, not tolerate him or her. Over-rule the team at your peril–because if you do, you will own every problem with the new hire.

It’s an Investment

Preparing team members to participate in the hiring process will take time–time to coach the team on which questions to ask and which ones to avoid; time to teach the team what to listen for; and time for practice interviews. Is it worth it? Yes! Interviewing is a broadly applicable skill. The abilities to formulate questions and to listen for what is said and unsaid are invaluable in speaking with customers, clarifying problems and devising solutions.

The person who makes the hiring decision has a vested interest in having that person work out. Including the team in the hiring process ensures that the manager is the most invested party. Because the team chose the new candidate, they will be more willing to show the new person the ropes and explain the context and domain. They’ll be more likely to offer help and encouragement. By having the whole team involved, you’ve created a support group to aid the new person with integrating into the group and become a productive member of the team.

Most importantly, involving more people in the hiring decision shares power and creates partnership. And if you want to get the best out of people, that’s what you want to be–partners.

Resources

If you want to learn about hiring–soup to nuts–get yourself a copy of Hiring the Best Knowledge Workers, Techies & Nerds by Johanna Rothman.

This article originally appeared on Gantthead.com.

Last week, I posted a mind map that shows the benefits of the team effect.  But what about the costs of a team that is not doing well?  A team that isn’t working well doesn’t have a neutral effect. A struggling team costs the people and the organization in engagement, quality, and money.

The Struggling Team Effect

A while back, I posted a little mind map about business costs of a struggling team.  But what about the benefits of the team effect?  What does a business gain when teams thrive?

The Benefits of the Team Effect

Recently, I tweeted, “/Estimating/ is often helpful. /Estimates/ are often not.”

Several people asked, “How can this be?” Let me say more, in more than 140 characters.

/Estimating/ is often helpful.

Estimating helps when the process of estimating builds shared understanding among the people who want the work done and the people doing the work..

Collaborative estimating gives the best results. Diverse experience yields a broader range of perspectives and questions.  Questions and perspectives build understanding of the what, why, and who related to the request. That’s helpful.

Group estimating reveals differences in knowledge and understanding. Finding those gaps early is helpful.

Group estimating surfaces assumptions. When we are aware of our assumptions, we can verify–or debunk– them.

When the group knows enough about the “what” to think about the “how,” they can analyze implementation.  Working out implementation details reveals more assumptions, and generates more questions.

Sometimes estimating reveals you only know enough to reason by analogy. The best you can do is posit that the desired functionality is about the same size as X.

But sometimes, estimators realize that they don’t know enough to think about size or effort in any meaningful way.

This situation calls for discipline. Discipline to resist guessing and speculation. Estimates born of ungrounded guesses are worse than useless. Rather than guess, experiment, interview, model, sketch designs or do some activity to gain more clarity about needs and context. Then try estimating again.

/Estimates/ are often not helpful.

People turn estimates into targets. Meeting the target becomes the de facto goal and the de facto method.  Meeting needs fades in priority.

People construe estimates  as promises. No one can predict the future, but many people treat estimates as guarantees. Failed predictions fan blame. Trust and openness suffer.

People construe estimates as bids. Bidding usually involves some calculation of profit. That implies a margin. However, managers discourage margins in estimates. Managers view “padding” as a moral failing–but it’s really a contingency for the unknown (or compensation for bosses who are known to cut estimates to fit wishes. See below).

Inappropriate precision in estimates implies that people know more than they do.  When expectations and reality meet, people may feel disappointed. More likely, they feel  deceived. Trust and openness suffer.

People game estimates. How many of you developers out there have thought long and hard about an estimate, only to have a managers say, “That estimate X is too high. The estimate should be X – Y.”  Me, too. Fudging estimates to fit wishes sets off another round of deceit and disappointed expectations. Trust and openness suffer.

So please, estimate. But don’t get caught up in estimates.

Recently, I met with a group of managers who work in an organization moving towards agile methods. People seem to be happy working on cross-functional teams. They solve problems and work things out without management intervention. Best of all, they produce working software that the customers like. This makes the managers happy.

But the managers have a lingering concern: How will we know that senior developers are doing senior level work?  How will we know they aren’t slacking off?

I hear variations on this question in many of the larger organizations I work with.

So let’s unpack what might be going on here.

It could be that these managers have no experience how teams work together to produce results. They don’t have a visceral understanding of what it feels like to say, “We can’t single out one person’s contribution. We did this together.”  Their own experience as managers in the organization reinforces the individual focus. In many organizations, management rewards and incentives leads to local optimization at the expense of over all goals–which obscures the interdependency of their work.

“Manager think” is shaped by emphasis on individual achievement in formative institutions such as schools, and by HR policies within their organizations. For example, individual ranking/rating systems ignore interdependency.  Finely differentiated job grade levels reinforce the notion that its possible to put a neat box around each person’s contribution. Further, they focus attention on “doing my job” –or not doing a job that a more senior (or more junior) person should do–rather than on accomplishing a broader goal–such as delivering customer value.  Narrow functional descriptions (automation tester, exploratory tester, front end tester) have the same effect.

Some people in management believe that if people aren’t pushed, pressured, and held accountable, they’ll slack off.

I have observed that many people are motivated by following through on commitments they themselves make. Many people find time boxes and deadlines useful to prioritize and organize where they spend time and attention. Commitments–made by the people doing the work–and time boxes can be useful structures.

Pressure, pushing, oversight work in a very different way (or, more likely, don’t work).These managers might be worried that people won’t do senior level work if no one is looking.

I actually find the opposite happens more often–people engaged in their work strive and go above and beyond.  OTOH, sometimes people create the appearance of striving (and doing senior level work) when they are pushed, pressured, and “held accountable.”

Here are some of the “senior level” things I would expect to see on a thriving team.

• pairing
• mentoring
• informal lunch and learns
• looking for patterns of problems in the code
• convening discussions about standards to address code quality
• initiating coding katas
• modeling good engineering practices
• task walls and a pull system for tasks
• delivering working code each iteration
• examining the teams practices and looking for ways to improve

Managers don’t need to be involved in the day-to-day  tracking of technical tasks to observe that these activities happen.

Senior people don’t have to initiate these activities.

I’ve seen many teams where junior people–both in terms of time on the job and technical skills– lead in these areas. If only senior level developers initiate good practices, I worry that they’ve created a pecking order on the team, and junior people with good ideas don’t get a chance to contribute. (Its a variation on the HiPPO problem–deferring to the Highest Paid Person’s Opinion).

Sometimes I try thought experiments.  I might say, “Suppose we formed four teams. After the teams have some time to get their legs under them, they’re producing results. They are getting software out the door, and the customers are happy. But you don’t know exactly what each team member is contributing. Could you live with that?”  Most people say they could live without knowing. When they can’t, that’s indicative of a bigger problem.

Very often, the notion of social loafing comes up. Then we’ve reached the crux of the matter.

The original experiments on social loafing looked at uninteresting physical tasks. Some of the experiments involved people working under compulsion. But we aren’t talking about odious work done under compulsion–at least I hope we aren’t.

Remember the old saying, many hands make light work?  People talk about social loafing as if it is  morally wrong for  one person to reduce his effort because others are working at the same task.  I hear the same logic when a well-functioning team makes work look easy. Someone inevitably complains that if they aren’t struggling, they must not be working hard.

When people hold beliefs like these, the systems they build tend to be  self-reinforcing, dysfunctional–and difficult to dislodge.

When people are in small teams, and engaged in meaningful work, social loafing is rare and working hard is common. But it might not look that way to someone who hasn’t see a thriving team.

No matter the name, the  intention of the role is to help teams learn new skills, continuously improve, and make the transition to a new way of working.

Some people say it’s a technical role, others claim that the role is primarily facilitation. I say, there is no one-size-fits-all when it comes to hiring an agile coach or ScrumMaster.

Understand the Needs of Each Team

Every agile team is alike in some ways and different in others. Agile teams are alike in that they strive to work cross-functionally to deliver working software. Most of them work in iterations. But from there, differences abound. Some teams need to learn solid engineering practices. Others need help with a specific skill such as automated unit testing. Still others need coaching to become a functioning team. Many need help making the mental shift to working in feature-slices that fit into sort iterations.

If your company is just starting out with agile methods, you may not know yet what teams need. Rather than hire a generic coach who may or may not fit the needs of the team, look to an expert help you. “Help” doesn’t have to be a prolonged and expensive contract. It can be a short assessment to gauge the areas where teams need support to make a successful transition to a different way of working.

Consider the Qualities, Preferences, and Style for the Role

What exactly are you looking for in an agile coach? Understanding of the agile method you are using is obvious. What about the personal qualities, preferences and other skills needed for the role? I’ve worked with teams that needed a field marshal personality–someone who won’t be cowed by the alpha-geeks on the team. And I’ve worked with teams where a subtle touch was all that was needed, and the only thing that would have worked.

When you consider the qualities, think about disqualifies, too. I would disqualify someone who believed that there must be no deviation from canonical sources on agile methods. People are more like to accept a change when they have a hand in shaping it. So allow for shaping, but hire someone who can keep an eye on the why. That way, the team will retain the intent and essence of a practice as they adapt it to fit their unique circumstances.

I would also disqualify the coaches who have only one style, or have faulty ideas about coaching and change processes. One self-proclaimed coach bragged about making people cry in his prior assignment. Cross that one off!

Put the Two Together

Once you’ve considered what the team needs, you’ll have a list of technical skills, agile method knowledge, collaboration skills, and qualities. You will not find the ideal candidate. So note which ones are required, which are desirable and which ones are will definitely disqualify a candidate.

Consider the interactions, responsibilities and deliverables. These factors highlight the primary relationships, expectations, and integrating aspects of the role.

Consider using a role analysis such as the one I did for a ScrumMaster/Agile coach role.

Treat this Like Any Other Job Opening

Whether your are seeking internal or external candidates, treat this as any job opening. Create a job description, screen the candidates, use behavioral interview questions and auditions to find the best-fit candidates.

When you find a candidate who has the skills, desire and potential to fill a servant leader role, make sure that the organizational incentives are aligned to support the new role rather than holding the old behavioral patterns in place.

Changing a Title is Not Sufficient

Some managers decide that changing a persons title from “project manager” to “coach”  is sufficient. It is not. Supporting a team and helping them up a learning curve requires a very different set of skills and preferences than those essential for project management.

Some project managers can make the transition. They understand how to create the enabling conditions for a team, how to set appropriate decisions boundaries, when to step back and when to step in. But even good candidates for the role will need role models, coaching and support to make the transition.

Don’t count on the unreliable “flip the title, flip the switch” method to fill the need for coaching new agile teams. Discern who has the potential to adapt to role that relies on personal effectiveness rather than positional authority.

Agile coach is a critical role and the person who fills it needs to be up to the job. A competent coach will help the team learn how to work cross-functionally, fit their work to short iterations, and help them avoid adapting their way back into waterfall.  A coach who is a good fit will have the specific skills and qualities to help a specific team. If you are serious about realizing the benefits of agile methods, be serious about filling the role of agile coach.