Tag Archives: teams

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.

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.

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.

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.

Agile methods depend on effective cross-functional teams. We’ve heard many Agile success stories…at the team level. But what happens when a product can’t be delivered by one team? What do you do when the “team” that’s needed to work on a particular product is 20 people? Or 20 teams?

There are no simple answers. But there are design principles for defining workable arrangements when the product is bigger than a handful of agile teams.

Most companies have policies that govern the selection and hiring process for new employees. Not a bad thing. But I’ve noticed that in many of the companies I visit–especially the big ones–the guidelines put far less rigor around hiring people for dev teams than for management roles. (Occasionally, I see the opposite. Might write about that at some point in the future.)

I agree with the need for due deliberation in hiring managers at any level. Managers can have a big impact, and it makes sense to hire carefully. Many companies take a broad stripe approach to hiring managers. They look at management skills–but also assess psychological make up, interpersonal skills, and ability to work with others. At senior levels, the candidate often interviews with the other people he or she will work with. They gauge the candidates style, fit, and personality–and gain commitment from the work group, not only the hiring manager.

But when hiring technical people, many of these companies take a narrow stripe approach. They look only at technical skills and domain knowledge. Both are important, of course.

But there’s an assumption there that personal qualities and interpersonal skills don’t matter as much, and team buy-in is irrelevant. There’s also an assumption that people developing software work independently as individual contributors, and they are relatively easy to replace if they don’t work out.

But, if you want to develop strong, creative, capable teams, you need to up the hiring game at the dev team level.

Here are four reasons why:

1) A person working on an agile team is not an “individual contributor. ” He or she is expected to work interdependently. In agile teams, people collaborate, negotiate, make trade-offs, handle conflicts. These interactions require a high level of interpersonal skill and emotional intelligence.

2) Even junior members (in terms of experience, age, or skill level) are expected to exhibit a high degree of self-management. They make commitments to other team members, follow through on commitment, manage their own work level and task completion. They need to know how to ask for help, and be comfortable admitting when they don’t know something.

3) People on agile teams need to have excellent problem-solving skills–beyond those needed by an “individual contributor.” An individual contributor needs to solve problems that are bounded by his task assignments. Problems of coordination and dependencies are often someone else’s job. People on agile teams work together to solve technical problems, handle issues, and interface with other teams. The manager isn’t doing the bulk of the integrating work between tasks and solving problems–team members are.

4) People on agile teams need an exceptional ability to learn and apply that learning–both in growing “generalizing specialist” skills and in improving team processes.

You can learn a lot about these factors in an interview if you use behavioral interview questions. But not enough. But it is very difficult to assess how someone will fit into the team, unless the entire team has a chance to meet him and interact. It’s hard to assess how people code, test, problem-solve, unless you see them in action. That’s why auditions are so useful.

Further, the broader the interview team, the more people will be invested in the new hires success. They won’t have the cop-out of saying “your problem, I didn’t choose him.”

“The beginning is the most important part of the work.” Plato, Greek philosopher and writer, 429–347 B.C.E.

I’ve written several articles about a manager’s relationship with a team that has already formed. A manager’s relationship with a team as they work is essential for cultivating a self-organizing team and maintaining a link with the organization. But a managers role in growing effectives teams starts long before the work actually begins.

The 60-30-10 Principle

J. Richard Hackman, has been studying teams for decades. One of his most significant findings is that 60% of the variation in team effectiveness is attributable to the design of the team, 30% to the way the team is launched, and 10% to leader coaching once the team is underway. By “design of the team,” he doesn’t just mean picking the best people. You also have to think about the nature of the work, articulate a goal, and plan for enabling supports.

Aim for Flexible, Long-lived Teams

You can call a group of people a team the first day they come together. But that doesn’t mean they’ll achieve teamwork right away. People need time to understand each others strengths, weaknesses and work styles. They need to agree on, try, and adjust the way they work together to find their groove.

In many organizations, managers from cross-functional teams to meet the needs of a specific project. In some cases, that means the team will be together for a long time. More often, it means teams will be disbanded after a few weeks or months. That’s barely enough time for a team to gel and gain the benefit of the team effect.

Analyze the work that’s in the pipeline. Aim to organize the work so that teams have “whole” work–creating a product or service that has meaning from a business perspective. Look at the trade-offs and tensions inherent in the product. Make sure people who represent those aspects are part of the team. Look for dependencies and to the extent possible, keep them within a team boundary. Form teams that have the breadth of skills to handle a broad range of work.

Then, bring work to the teams, rather than reforming teams for each new project. You won’t find a team that’s perfect for all the work in the pipeline. When teams lack a specific expertise, keep the core team in tact and add expertise.

Articulate a Compelling Goal

An effective goal statement does two jobs. First, it focuses the attention and effort of the team. When the team has a shared understanding of what their task is, they pull in the same direction. When teams have don’t agree on the goal–or the goal is so vague it’s open to many interpretations–team members waste time and brain cycles arguing, working at cross purposes, or doing the wrong work.

Second, a well-formed goal engages the team in a meaningful challenge. An effective goal provides a sense of purpose to the teams work. The goal might be solving an important problem, enabling business, launching a new product, or meeting a customer need. State the goal in a way that taps into purpose.

Take the goal handed down to the FinCore team: “Maintain the FinCore Product.” That goal isn’t enough to get someone out of bed in the morning. It talks about a process (maintenance), but leaves out the purpose. It misses the opportunity to tap into pride-in-work. A more compelling goal might be:

Sustain the FinCore product by adding necessary functionality and ensuring the technical integrity of the code, so we can provide uninterrupted service to 40,000 customers.

Not all work is exciting and sexy, but all work should have a purpose. Making that clear will help people focus and engage.

Pillars of support

The right people and a compelling goal are a good start. But if you neglect the pillars of support, the team may still wallow. The pillars of support are:

Information related to the situation, domain, problem and technology. These reinforce the goal, and provide the context for the team to make good decisions.

Material support, such as machines, tools, facilities, adequate budget, and supplies. Adequate material support communicates that the work of the team is important. Starving a team for resources undercuts the goal and creates cynicism. Paradoxically, providing too much isn’t good either. A certain level of constraint can drive creativity (and over constraint kills it).

Expertise to supplement the knowledge and skills of the team when needed. Even when the team has all the skills required by the task, they may need an expert eye for consulting or reviewing. Some times there is some aspect of the work that requires scarce knowledge. It may not make sense to develop that knowledge on the team, or it may only be needed for a short time.

Feedback loops that connect the team to the organization. Regular demos of working software allow the sponsor or product owner to see how the team is doing–and allows for course correction. The heartbeat of progress builds trust.

If any one of these pillars is missing, you’ve put the team at a disadvantage.

This Sounds Like More Work for the Manager. Why bother?

Team design is a pay me now, pay me later proposition. It’s a myth that you can throw a group of people together and they’ll gel as a team. Strong effective teams don’t just happen by some magic chemistry. Well designed teams are more resilient. They make better use of the knowledge, talents, and skills of team members. They function and stay on track with relatively little management intervention. You may not always be able to bring together the perfect team. But you can set a team up for success….or failure. It is up to you.