Structuring for Agility

Contents


Silo Stubbornness

Photo of a row of grain silos connected across the top
Credit: Ossewa, CC BY-SA 4.0, via Wikimedia Commons

Elsewhere on the site, I explained that Scrum teams are fully cross-functional, able to deliver a releasable product. Unfortunately, most companies still organize in function-based “silos.” That is, not only are hardware and software engineers in separate groups, within software alone the user interface developers and the people who connect the UI to the Internet may report to different managers. Often they are on different teams.

I find this bizarre. The damaging effects of silos are so well-documented, the term is instantly recognizable in business discussions around the globe as a bad thing. Despite best intentions to coordinate, in practice the silos almost invariably plan out of sync, such that one team is waiting on the other before it can continue its work. Individual team members assigned to cross-functional teams understandably give more weight to their appraisal-writing functional managers’ wants than the team’s needs. Some defects are difficult to find until silo team outputs are combined and tested as a system, which amounts to escaped defects as defined earlier, with all the attendant costs. Needs of other non-development organizations are usually forgotten, such that documenters and customer support managers block planned releases because they don’t have what their teams need to finish their work. The “Blame Game” becomes pandemic as each silo blames the others for release failures that are likely given the silo environment.

Only momentum and lack of will prevent a shift to a structure that reflects and supports cross-functional, full stack teams… and a lack of information. Let’s fix that next!

The Empowered Matrix

Enterprises that do project-like work—that is, almost all enterprises—are best supported by what I call an “Empowered Matrix” environment. This model is based on a standard organizational development model in which each line worker reports to two bosses: a “solid line” of reporting to the person who is their formal boss, plus a “dotted line” to the person who actually directs their daily work. The classic example is a project team, where each member of the team gets team assignments and performance appraisals from their functional manager but receives work orders from the project manager. Most managers I talk with about this mistakenly believe it is the only kind of “matrix” organization, but it is actually called a “weak” matrix because the person directing the work has little authority:

Weak Matrix Organization

In a “strong” matrix organization, the lines of reporting switch. That is, the project manager is the formal boss, but each person also follows guidance related to each function from the functional managers:

Strong Matrix Organization

Notice the dotted lines are now vertical, and the solid one horizontal. This has long been the recommended form for companies that do “projectized” work, for the obvious reason that it makes each project member accountable to the project. In this case, common sense aligns with the psychology research on motivation: Each person puts the project first, maximizing productivity toward the effort that makes the company its money.

An “Empowered Matrix” organization eliminates the project manager, because in agile the teams are self-directed, and project management is covered by the sprint and release planning processes. The teams report as a whole to the business unit manager (who might be in charge of each of the functional managers, too):

Empowered Matrix Organization, best for an Agile enterprise

This may seem like a lot of overhead for that manager, but he or she has no direct role in planning or managing the work of the team members and tracking progress is as easy as checking the Agile Tracker. We will discuss later how to ease the burden of formal performance appraisals, if your organization requires those. In effect, each team is just one additional “direct report.”

Implementation Issues

Convincing the Top and Sides

Moving to any matrix starts at the top, though with critical conversations on every side. The business unit manager (usually a vice president or higher) needs to have bought into agility. The whether-to-matrix discussion may be more difficult. You are asking for a shift of much time and effort by executives. Given that they will need to rely on advice from the Finance and Human Resources departments, and those people often have not even heard of Agile… well, don’t underestimate the challenge!

All of the affected managers will have to be brought into the discussion. I strongly recommend you follow this site’s Agile transformation process, replacing the Agile-specific content with making the case for eliminating silos. Managers will have many questions that I try to answer for you in the rest of this topic.

Who Reports to Whom

Ideally, as stated above, the teams report as units to a “skip-level” middle manager. By that I mean instead of having a “team leader” or “line manager,” all members of the team report to the manager that team leader or line manager would report to. This will seem daunting to middle managers in companies with outdated but typical performance evaluation systems. Combined with changes to how performance data is gathered, discussed later, the burden actually balances out and can even go down under Full Scale agile™. In effect, supervising five teams can prove little more challenging that supervising five individuals.

Part of the reason is because unlike traditional team managers, the Empowered Matrix supervisor does not:

  • Have daily involvement with team activities.
  • Take team-level tasks, at least on a regular basis.
  • Define the team’s workload.
  • Assign work.
  • Oversee progress in depth.
  • Track performance.
  • Fix project problems.

The FuSca™ processes for portfolio management, release planning if used, and sprint planning cover the first four bullets, and the tracker provides the next two. Any of the various roles in the system can fix problems, and whom does so is clear once the problem is defined.

Before an executive rejects the concept of treating a group of people like an individual, have them do some self-reflection. Corporate executives are fierce defenders of treating entire corporations as individuals under U.S. law! If that executive thinks the concept valid for a group of 100,000 workers, it surely must be for a group of five or 12.

What Managers Do in Scrum

The role of the traditional line manager is one of the biggest problems with the attempt to run Scrum teams within a waterfall company instead of changing the entire organization. Take, for instance, the standard waterfall software organization. There will be teams of testers with their own managers awaiting a handoff of work from the team of developers on one project while (hopefully) working on a previous handoff from another project. Besides the usual personnel functions of hiring, performance evaluation, training, and budgeting, the manager will be assigning people to projects fluidly and sometimes even assigning specific testing tasks within each project. He or she will also oversee the work to ensure it is getting done right and on time.

In Scrum, each software team has one or two testers who work only on that team’s project. The testers self-assign tasks with input from the team. Their managers don’t need to know what specific tasks someone has, much less assign them. Team members oversee each others’ work and arrange their own cross-training, such that the difference between developers and testers blurs. An agile coach and/or Agile Release Manager has primary responsibility for coaching members. In the most advanced, truly self-directed Scrum organizations, the manager has light involvement in hiring or performance appraisals—the team does the heavy lifting on those as well!

In short, functional managers, meaning those responsible for a particular discipline or skill set, have much less to do in agile organizations. In turn, that can mean the company needs fewer managers. In fact, for both companies and employees, reducing manager head count is a possible benefit to agile, as mentioned elsewhere. The company saves money, and the line employees have fewer management levels between them and the top.

This issue did not start with Agile. I addressed it in the earliest version of The SuddenTeams™ Program when it was just my consulting practice training manual, written a year before Ken Schwaber and Mike Beedle’s seminal Scrum book came out. The issue is related to the nature of self-directed teams. In a strong-matrixed organization where people in different disciplines work together instead of in silos by function, fewer functional managers will be needed. When the work teams are self-directed, you might eliminate one full-time manager slot per team.

In my years of consulting experience, I found this to be the single biggest obstacle to managers agreeing to self-direction. It reduced the social power and job security for the managers in the best position to implement this approach. Because self-directed teams are more independent and productive, and less costly than leader-led teams, it was good for the company, but not for the team leaders!

In Agile the role of the functional manager in daily actions of the team ends with the assignment of their personnel to the program. As in any matrixed organization, the manager retains responsibility for filling general personnel needs of the company within the manager’s discipline, general orientation, and assigning employees to teams (unless the teams are allowed to do the hiring themselves as I recommend). They will also have responsibility for enterprise-wide training, technical tools, and technical processes related to that discipline, though in Scrum each team must be allowed as much latitude as possible for its own processes. In companies which use performance evaluations, the functional manager is handed most of the input on direct reports from the tracker and from other members of the teams instead of through direct observation.

That’s not enough to keep one person per team busy. Upper managers implementing Scrum will need to find other ways for those individuals to contribute. Within FuSca, the line manager who is capable of giving up directive power might make a fine Architect or Team Guide. One of my best Agile Release Managers was officially titled, “Software Engineering Manager.” Should the manager take one of these Guidance Roles, however, it is critical for mutual accountability that the former team manager give up performance evaluations of the other members.

Here are some other suggestions for managers finding themselves with more time on their hands:

  • Process expert—Map, review, and champion improvements to processes that cross team or business unit boundaries.
  • Quality champion—Become an expert and lead efforts in quality techniques such as Continuous Quality Improvement or Six Sigma.
  • Technical consultant—Go back to doing what you love about your industry. You can spend some of your extra time getting yourself caught up and becoming the company expert in those technical areas.
  • Special projects champion—Take on the company tasks that need to be done but no one else has time to do.
  • Agile champion—Help other managers learn about and adopt Agile techniques.
  • Customer champion—Lead efforts to better understand your unit’s—or the company’s—customers and how to satisfy their needs.
  • Systems thinker—Conduct research to understand “the organization as a system and… the internal and external forces driving change,” per the classic work on “learning organizations,” The Fifth Discipline. Then develop methods to help “managers throughout the organization come to understand these trends and forces.”[1]

Re-focusing on Team Performance

Asking for “We,” Paying for “Me”

I could fill a book with the scientific arguments and data against annual review processes. Fortunately, others have already done so.[2] If your company is realistic enough to have dumped them already, skip to “Team Pay for Teamwork.” The unfortunate majority of you, keep reading.

The typical performance evaluation process drives a focus on “me” instead of “us,” especially if the results are tied to bonuses or raises or, in the face of layoffs, keeping one’s job. No matter how much a company or manager stresses the importance of “working as a team,” if direct or indirect financial incentives emphasize individual performance, the individual is going to focus on what’s best for him or her. Hence I recommend a scheme that “games” the performance evaluation system to place the emphasis on team results and an individual’s teamwork behaviors.

I will summarize that approach to say that reinforcing a team focus is best achieved through inclusion of measurable achievements by the team and 360-degree performance evaluations of individual behaviors. These will drive a host of psychological changes that improve team performance, such as:

  • Commitments to the team (and therefore the team’s customer) becoming more motivating to the individual than commitments to their functional manager.
  • Improvements to teamwork skills such as sharing knowledge and communicating earlier about potential problems.
  • An increase in what scientists call “organizational citizenship behaviors,” basically actions that help the team, but are not part of the person’s official job description or sprint commitments.
  • The same self-control of negative social behaviors with team members the person shows with their boss.

Rating Team Results

At least a third to a half of an individual’s performance rating should come from team results like these:

  • Delivery of 100% of planned sprint stories most sprints.
  • Delivery of 80% of planned epics to which the team contributes in most releases.
  • One or fewer escaped defects per release.
  • Improvement in customer-satisfaction ratings regarding the team’s product, year over year.

Unlike most annual review standards I have seen, notice these are tied to specific numbers. Scientifically valid results get the same ratings regardless of whom does the rating. The numbers also must apply to everyone being compared against each other, and account for environmental or market changes beyond the individual’s control. Otherwise they are inherently unfair.

Let’s take a typical schema that says someone, “Does Not Meet,” “Meets,” or “Exceeds,” standards. All too often the company does not specify what those standards are, or they aren’t measurable, or they only provide a binary “yes-no” measurement, despite the fact that three levels imply a three-part measurement. Here’s how you could measure the four bullet items above for a team doing four releases a year:

Standard Does Not Meet Meets Exceeds
100% Sprint Delivery <80% of sprints 81-95% of sprints >95% of sprints
80% Release Delivery <3 of 4 releases 3 of 4 releases 4 of 4 releases
Escaped Defects >3 (year) 2 or 3 (year) 0 or 1 (year)
Customer Satisfaction <10% improvement 10-20% improvement >20% improvement

Notice some themes:

  • Every standard is objectively measurable. Assuming you have valid means for measuring each, and you communicated the standard and means of measurement to everyone at the start of the year, no one can argue against the rating.
  • The standard is a realistic range. I can’t believe how many times I have seen a single number in a standard, meaning you have to hit that exact figure. I have seen teams hit each “Exceeds” standard, though none have hit all of them in the same year.
  • Most don’t demand perfection, because humans aren’t perfect. Setting impossible goals is an instant de-motivator: Because the person knows the goal can’t be achieved, they won’t bother trying (or more likely, will figure out a way to “game” the system).

Sadly, I haven’t succeeded in getting a client to include customer satisfaction in a team’s results, which is ridiculous given that it is a critical factor in sales growth and the first of the Agile Manifesto’s principles.

360° Performance Evaluations

These evaluations are surveys asking the same questions about each individual, filled out by each of the individual’s team members, their supervisors, and potentially a few stakeholders the individual works with directly. Here are some examples:

360-Degree Performance Evaluation Form

Most of the numbers are used as inputs in place of supervisor judgments in the performance evaluation system. The last scale above about blaming would instead be used to assess the team’s performance on the related Agile Performance Standard. Granted, the members could collude on the scoring, but so can a manager and each of that manager’s favorites on the team in the traditional system. Plus, collusion would look pretty obvious in the patterns of responses, and the manager’s and outsider’s ratings would provide perspective.

Be aware there is an entire science around the development of surveys. It is surprisingly difficult to create surveys that actually measure what you are trying to measure and get the same answers each time they are taken. I was lucky enough to take a course on research methods in graduate school from someone who wrote a textbook on the topic. In that class I helped create a statewide political poll to learn the principles. Unless you had similar luck, consult a survey professional from a local university. The money you spend will pay off in morale because employees will feel the system is easier to fill out and more fair than they otherwise would. If the evaluations are tied to pay, the system will likely be easier to defend if you get sued. In short, as car commercials often say in the fine print: “Professional driver. Do not attempt.”

Rewarding Teamwork

After reviewing research on performance management as relates to teamwork, I recommend this breakdown of the overall rating:

  • Team performance (1/3 to 1/2)
  • Performance as team member (1/4 to 1/3)
  • Performance as individual (1/4 to 1/2)

To support teamwork, at least half of the evaluation should be based on the first one or two items. For example, if your system awards points on 10 evaluation items, 3–5 of those items should relate to team performance; 2–3 to the individual’s teamwork, like “Coordinates his/her work with teammates”; and 2–3 to individual performance.

Whether or not you do formal performance appraisals, this breakdown also applies to compensation. HR consultant Lyholzer, mentioned on the previous page, noted in her presentation deck, “Compensation thinking is a century old.” Again there are plenty of books about progressive systems for paying for performance instead of mere time. To repeat my earlier point, if you pay for individual performance instead of team performance, that is what you’re going to get.

Team Pay for Teamwork

Overview

A drawing of hands holding old-fashioned money and a walletTeam members must be given incentives to work together if they are to overcome the usual “me first” approach. Initially, giving them information and the power to change their working conditions may be incentive enough. Over the longer term, money should be involved. Since the team will be saving or generating new money for the company, team members will think it only fair that they share part of the newfound wealth. As one researcher noted, “Talking about teamwork and cooperation and then not having a group-based component to the pay system… signals what the organization believes is actually important—individual behavior and performance.”[3] Using the larger part of the amount your company makes available for bonuses and profit-sharing to compensate each team as a whole, rather than as individuals, will place the focus on team achievement.

Four elements of standard compensation schemes work against teaming:

  • Focus on individual achievement.
  • Employee preference for individual recognition (discussed below).
  • Numerous promotional levels, because a focus on attaining a higher pay range may take away from teaming efforts.
  • Seniority pay, which diminishes the opportunities for rewarding teaming and other skills.

Employees in the United States and similar cultures tend to prefer individual recognition schemes[4] and thus may resent this approach initially. A researcher quoted a worker as saying, “I’m a team player, but I want rewards to be individual.”[5] But there is considerable evidence that individual recognition systems “absorb vast amounts of management time and resources, and they make everybody unhappy” due to perceived unfairness in how individual rewards are doled out.[6] Plus, part of the preference may simply be habit—it is what they are accustomed to. As with performance evaluations, a good compromise might be to leave the majority of the compensation emphasis on individual performance at first, but tie a major share of that to the individual’s performance as a team member. Of course, if you tie the individual’s base and/or reward compensation to performance evaluations, and those evaluations are tied to team performance and teamwork as discussed earlier, the same result will be achieved. Over time you can shift to a more balanced approach.

Whatever compensation system you adopt, make sure the team members understand it, and more importantly, understand what they must do to receive their rewards. This seems obvious, but is too-often overlooked. The easiest way to do this is to adopt open salaries. That is, as practiced in all United States governments and many companies, make everyone’s pay visible to everyone in the company. The bits of evidence I found in the compensation research, and articles in the business press, suggest the pros far outweigh the cons.[a] This was also my experience working for government entities that practiced it, both as an employee and a manager. The cons seem primarily based on lack of clarity about what pay levels are based on. Transparency about the basis, if not the salaries themselves, fixes that.

Once a system is in place, resist changing it quickly other than to make minor improvements. Morale will be severely damaged if people spend months or years working to achieve certain standards and the related pay, only to have the standards change dramatically. In the book and movie Catch-22, the number of missions required of a World War II flier before he could go home kept going up as people approached the previous requirement. This destroyed morale to the point of driving characters insane. However, do not rest on your laurels after you get your new system in place. Reassess your plan yearly.

The rest of this section focuses on different ways to support teamwork with money, in most cases using funds provided by better team performance.

Reward Types

Incentive Rewards

Incentive rewards drive productivity through promised rewards for performance. (The word “rewards” may refer to either a raise of base pay or a bonus.) A key element is certainty: the team members should know beforehand that they can get a reward and what that reward is. Most researchers agree that incentive rewards should be at least 3% of base pay, and possibly more depending on the organization’s raise history. Anything less has little motivational effect. Incentive schemes that support teams vary somewhat according to the type of team:

  • Raises for new teaming skills or knowledge, and/or work skills learned as a result of the team’s efforts (Best for management, development, production, or support [“line”] teams).
  • Bonuses for efforts—as opposed to results—tied to achievement of milestones (Advisory teams like quality circles, project teams).
  • Bonuses for successful suggestions (Advisory, line).
  • Bonuses for results, tied to achievement of objectives at the team, division, and/or company level (Management, line).
  • Profit-sharing—Returning a portion of the company’s or division’s profits to the employees (All).
  • Gainsharing—If team activities result in measurable cost savings or revenue gains, giving a percentage of the extra money to the team (All).

Each of these types are discussed in detail further down except profit sharing, about which there is plenty of information in the popular business literature.

Recognition Rewards

Recognition rewards come after the achievement and are not promised beforehand. That is, they are surprises to the recipients. These include company wide awards (with or without money attached), and take the form of such things as:

  • Equal cash amounts to each team member.
  • Social events ranging from dinners to group vacations.
  • Additional training or equipment upgrades not covered by the regular budget.
  • Gifts or gift certificates.
  • Perks such as reserved parking spaces for the whole team.
  • Providing the team a lump sum to split up or otherwise use as it chooses.
  • Merely recognizing and thanking people for good actions, in private and public.

Combinations of Rewards

Incentive and recognition rewards are not mutually exclusive; a combination of them may work best. One researcher[7] used as a model the compensation system used in professional baseball:

  • “Base salary—usually determined by ‘going market rates’ for the average player in each specialty… influenced by the player’s past performance…;
  • “Individual one-shot bonuses—for an outstanding performance such as a ‘no-hit’ game by a pitcher;
  • “Seasonal bonuses agreed (upon) in advance by contract… which links the size of the total pay package to the player’s performance statistics…; and
  • “Team bonuses that are shared (usually equally) by the players—for overall group performance such as finishing a season high in the league… The players decide as a group how to divide up these extra earnings.”

Example Programs

  • “Tag You Win”—Established by Operations Management International, the program allowed anyone to reward anyone else for exceptional work. The recipient got a framed certificate at a team or division meeting, plus “Quality Bucks” that could be redeemed for gift certificates, movie tickets, etc.[8]
  • A Ralston Purina division handed out around the company note pads that said “Thanks” in big letters across the top, and “…for going the extra mile” on the bottom. Researchers wrote, “The pads were such a hit that the region exhausted inventory each of the past two years.” Once those managers used them, others began doing so. Many employees reported holding onto notes they received to use as spirit lifters.

For more ideas, see “Appreciation.”

Incentives for Skills or Knowledge

Description

Incentive pay can be partially tied to skills or knowledge that an individual or team learns. After comparing two otherwise similar manufacturing facilities within a major corporation, two researchers[9] found that skill-based pay correlated with 58% greater productivity, 16% lower labor cost per part, and an 82% improvement in quality.

Considerations

  • Establish in advance the methods you will use to measure skill attainment, to ensure that pay increases are granted fairly. Possibilities include:
    • Knowledge or performance tests.
    • Individual productivity standards.
    • Completion of certification programs.
    • In mature teams, other team members’ ratings.
  • Job descriptions may need to be expanded to provide a wider range of skills for advancement. This also will prevent people from trying to earn extra pay for skills that do not contribute to team success.
  • Be sure to include administrative and interpersonal skills to foster team growth.
  • Maintain a balance between technical and people skills, and between on-paper and on-the-job measurements.
  • Measure previously learned skills periodically to prevent backsliding.
  • Keep job descriptions broad enough that it takes three to five years for a person to gain them all at a particular job level.
  • Tie the pay and skills closely. One approach is to pay an extra x amount of money per hour for up to a maximum of y skills learned and still being used on the job.

Example Programs

  • At General Motors’ Fitzgerald Battery Plant, employees were paid “for what they are capable of doing rather than the task they are doing at a particular moment… An employee must demonstrate competence at all jobs on two different teams in order to advance to the highest pay level. This typically takes about two years.”[10]
  • A forms-printing company established skill levels for pay as follows:
    1. “Entry level, can perform simplest task in each function.”
    2. “Is capable of two or three simple tasks.”
    3. “Can deal directly with customers; knows files.”
    4. “Can handle all but most exceptional situations.”
    5. “Can make independent decisions in 99% of situations that arise.”[11]
  • Eastman Chemical Company required that all members of a team achieve a basic set of technical, teaming, and business skills before any member could move forward in the program. Members then could move up in pay by mastering additional skills, taking on leadership roles on the team, and after that, by moving into certain specializations. In addition:
    • Teams had to maintain their basic skills every year.
    • Members had to show that they were using their new skills 10% of their working time.
    • Specializations had to be chosen with the needs of the team in mind.
  • The Orthopedic Division of Smith & Nephew (SNO) implemented a skill-based system for setting base pay. Workers could receive on-the-job training in 13 skill areas including technical and people skills. Seven were required for everyone, including listening and teamwork. Six others were optional. It took anywhere from six to 24 months to learn a new skill and demonstrate proficiency. With each skill came a pay raise of a set amount.[12]

Pay for Efforts or Results

Description

Incentives can be tied to achieving pre-determined measurable results, and/or valid efforts to do so. If you use this system, base reward pay only on results mostly under the team’s control.

Considerations

This approach is exclusive: unless your whole company is organized by projects, not everyone can be on the kinds of teams where effort pay works best (an advisory or project team) and results are easily measurable or separable from other factors. If you implement this method, be aware that it could therefore be a source of jealousy for people not on your team(s). One way around this is to implement a program by which the team recognizes others in the company that contribute to its success. For example, Great Plains Software let its teams create “Friends Lists,” whose members received formal thank-you notes signed by the entire team and a choice of gift certificates.

If the objectives to which incentives are tied are too easy, such that the bonuses become commonplace, those bonuses may come to be seen as entitlements instead of incentives.

When providing incentives for long-term efforts, consider having a series of bonuses, delaying the earlier ones to keep the team moving forward. A bonus paid right away could compound the usual “accomplishment let-down.” So, for example, Lotus Development Company provided a large bonus to a non-agile program for hitting an initial rollout date in April of one year, but did not pay out until July. Meanwhile, the team kept working toward the full rollout date in November, the bonus for which was smaller but was paid immediately.

Example Programs

  • Rockwell Automation established company-wide goals for before-tax profits, sales growth, on-time shipments, and scrap reduction, with three measurable standards for each goal. The goals were applied at the group or site level. Achievement of the least-challenging standard by a work group added a bonus of 0.5% to each unit member’s base pay; the next higher standard added 1%; and the highest, 1.5%. Achievement of the highest standard on all goals could have resulted in a bonus capped at 6%. The company also added a connection to overall company performance by multiplying the percent figure times a factor based on the company’s operating return on sales (OROS). If the company hit or missed its OROS goal, the payout could decrease by as much as 50% or increase up to 75%. All employees were told the company’s performance results; the increased understanding resulting from this open-site management was praised as one of the program’s biggest successes.
  • Great Plains paid out pre-announced bonus amounts to product development teams (again non-agile) in two parts. Half was paid if and when the team hit the target deadline. The other half was paid only if quality targets also were met. Those targets were measured by customer satisfaction surveys, responses of pre-identified focus groups, and technical support calls as of 90 days after the release date. The bonuses were not large, but combined with other recognition programs, they helped reduce turnover rates.
  • On top of SNO’s skill-based pay program mentioned earlier, percentage increases were applied to the person’s base salary using division goals in the areas of customer focus, operations, financials, and innovation and learning. There were minimum, “target,” and maximum measures and related percentages. Hitting targets for all four areas added a total of 2.5% of base pay and hitting all of the maximums, 10%.[13]

Incentives for Suggestions

Description

If you are having difficulty getting useful suggestions, consider paying for them. Offer a portion of any financial payoff to the submitter. Build accountability for suggestions by paying half of the incentive upon approval of the idea, and half upon implementation. To avoid charges of favoritism, consider a system in which a board of people not on the team meets on occasion to review suggestions, or allow the team to evaluate them itself.

How you handle rejected suggestions can be as important as how you handle accepted ones. Use rejections as an opportunity to teach, by providing detailed explanations of why a suggestion was not accepted.

Example Program

Utilicorp United created a program to encourage employee-created teams to come up with suggestions for improvements. It rewarded results with “Utilibucks”:

  • Submitters received 15 Utilibucks for ideas that saved or earned between $500 and $1,000 over twelve months.
  • The figure increased with the savings amounts ($150 for an impact of $5,001–$10,000, for example).
  • The Utilibucks were put into accounts the team member could use to buy merchandise from a catalog.
  • For W-2 purposes, the company added the tax amounts on the Utilibucks as part of the bonus, in effect paying the taxes, which added perceived value.
  • In three months, the program resulted in $16 million in savings.
  • The program later was changed to give only a small percentage of due rewards upon approval, and the rest upon implementation, with the suggestion-making team taking the lead in implementation. Also, the team could review effectiveness a year later and receive additional rewards for ongoing success of the improvement.

Gainsharing

Description

Similar to incentives for suggestions, the basic gainsharing method is to quantify the current or historical “normal” performance, and then give the team a share of any cost savings or additional revenues above that norm. One suggestion is to average performance on the related measure(s) over the two to three years prior to teaming.

These may be direct cost savings; indirect ones to which financial figures can be tied, like reduced absentee rates; or revenue increases. Notice that gainsharing pays off to the team regardless of the impact on profit. This is by far the most powerful incentive for performance improvement. But obviously you need to be careful not to use it in ways that could harm the balance sheet. For example, one way to cut short-term costs is to cut quality. If you tied gainsharing to cost cutting, you would need to require that quality measures not go down.

Considerations

  • When implementing gainsharing, make doubly sure the standards you set tie into company goals, because the gainshared objectives will take a high priority for members.
  • Operations over which employees have little influence (because of high automation or dependence on other teams, for example) are not good candidates for gainsharing.
  • If major capital investments are planned, hold off on gainsharing. Otherwise it will be difficult to separate team performance effects from equipment upgrade effects.
  • Along those lines, do not implement gainsharing until after the team has completed its initial agile transformation. Teams need to be running smoothly with relatively stable processes to get accurate baseline data for improvements.
  • If gainsharing rewards decline over the years, so will their motivational effect. On the other hand, declining rewards may cause the team to go after riskier goals in hopes of raising the rewards again, perhaps to the detriment of the team.

Example Program

Bayer Corporation allowed a team to create a “Productivity Plus” plan identifying measurable improvements it hoped to make in one of three areas: safety, financial results, or operational results. If the team was able to show bottom-line gains from the effort, it received a percentage of the dollar savings.

Individual Teamwork Rewards

Description

Consider compensating individuals for their performance as team members, in addition to any rewards for individual work performance. By compensating for teamwork:

  • There is less of a focus on what others are or are not doing to help the team, both because an individual can get something out of it regardless, and because this facilitates the belief that people with poor teamwork will “get what’s coming to them.”
  • The incentive to adhere to team values and procedures is increased.
  • If the team fails, individuals still feel compensated for the extra time and effort, which will be critical to their willingness to try teaming again some day.

The best judges of how to allocate teamwork rewards may be the team members themselves, perhaps using 360° evaluations as discussed earlier.

Example Program

Lotus Software project leaders would sign contracts with team members describing in detailed language what constituted extraordinary individual performance. A few star performers by those criteria received substantial bonuses. A somewhat larger number who performed better than required, but not at the same level as the stars, received amounts about half of the top-level rewards. Another set, which performed well but not necessarily “above and beyond the call of duty,” received rewards about half the amount of the second-level rewards. In one team of 23, for example, three won the top reward, five the next level, and ten the third, so only the five poorest performers received no reward. To prevent jealousy from harming the team, again it would be critical to make the standards objectively measurable if possible; based in part on teamwork skills; and if subjective, to use team member ratings.

Special Considerations

  • Multilevel targets—Per some of the examples above, with milestone, objective, or profit-based plans, consider multiple levels of achievement and rewards. For example, you might add 1% to base pay if the team gets within 90% of a given target; 3% for meeting the target, and 6% for achieving 110% of the target.
  • Advisory teams—Make sure any extra compensation for advisory team members does not outweigh that for their regular work, lest they give more importance to the advisory work (unless you want that to happen, of course!).

An Ideal Agile Enterprise

Drawing of a big house in a beautiful valley with a rainbowAs it happens, all these points about structure align with research into organizational effectiveness. Based on different definitions in journal articles,[14] an “effective organization” can be described as an enterprise or a subunit able to choose and achieve goals it believes will maximize its performance. Those studies together suggest that an organization built for maximum effectiveness would not look like most workplaces. It would emphasize customer satisfaction over other goals, and exhibit decentralization of control, “low specialization, high decision autonomy, high participation in decisions, low formal standardization… low punishment,”[15] and the team characteristics described throughout this site. Taking all of these to their logical extremes leads to a model of an ideal, extremely effective agile enterprise.

Instead of a hierarchy of functional groups, this model is built on a foundation of cross-functional, self-directed, regionally if not fully collocated, and full-stack groupings called, for example, “pods.” Each pod is made up of multiple small teams fitting the same description (cross-functional, etc.). Every pod is dedicated to a specific set of end users (if a product pod) or customers (if a services pod). Each is effectively its own small-to medium-sized business, responsible for all aspects of satisfying its customers. Notice this reduces or eliminates issues of globalization such as competition about priorities among regions, globally required procedures that don’t fit everywhere, and inefficient global teams.

Functions like Human Resources, Information Technology, Legal, Finance, etc., are matrixed. Each specialist reports to a pod; however part of each person’s capacity is set aside for work with functional peers in “advisory teams” for the purpose of cross-organizational tasks, for example annual reports. Knowledge experts on techniques like Six Sigma or technical skills, called “coaches,” replace silo managers for needs like technical training, and form advisory teams for efforts such as organizational technical certifications (e.g., ISO).

The team-level aspects are detailed under “Self-Directed agile,” but I’ll summarize them here. Each team (technical and advisory) is a self-directed work team following processes and rules it creates and perhaps Scrum or Kanban as appropriate to its workload. Instead of having a team leader job, it has a “facilitator” or “coordinator” role which rotates among some or all team members, primarily responsible for facilitation of meetings and coaching on team processes. Entire teams, as opposed to individual members, report to “pod coaches” (replacing middle managers) with facilitation/coaching roles for multi-team planning, plus networking tasks between pods and with advisory teams.[16]

The pod coach role is made manageable by:

  • the Agile Tracker, which provides real-time progress reporting;
  • the lack of responsibility for project-related tasks, handled instead by the teams and agile processes;
  • team-led hiring practices; and
  • the fact that single-reviewer annual performance appraisals, if in use, are replaced with 360-degree evaluations of peers by peers.[17]

Compensation is tied significantly to achievement of organization, pod, and team performance standards and goals, plus 360 results. Combined with base salaries or hourly wages for all workers that cover minimum living requirements, the totals are at or above the typical market rate for each skill set within a given year—that is, within current economic conditions, which can cause fluctuations in that rate.

Major organizational decisions are made by org-wide vote. These include identity decisions (mission, values, etc.), top-level strategies and goals, and how to handle financial difficulties. Smaller decisions are made by a Supporting Council representing all employees. Teams elect representatives to Pod Councils with similar duties at the pod level, and the Pod Councils to the Supporting Council, plus each advisory team is represented. The Council may elect the equivalent of C-level executives, perhaps designated “Servant Leaders.” That title would emphasize their mandates limit them to implementing what the council decides and making fast decisions when required, which the council may later overrule.

Here is what it looks like:

Diagram showing customers at the top, pods of multiple teams below, teams of specialists further below, and a "council" at the bottom

Pods include teams, a coach, and functional specialists not needed on individual teams:

Pod Details

To enable democratic governance, all organizational information not protected by law is available to all employees after signing nondisclosure agreements: Budgets and financial results, performance data, individuals’ compensation, customer information, contracts, and vendor information. Taken together, these approaches maximize two-way communication, autonomy, and participation in decisions.

This model is post-bureaucratic, democratic, and (lower-case) lean and agile. Thus it is extremely effective, choosing and achieving the best goals for its business. Yes, it is wildly different from the typical work organization. Yet it reflects principles found in effective exceptions that have attained lasting financial success, high job and customer satisfaction, and positive notoriety. It may sound utopian, but those examples prove it can become real.

Agile Across Enterprise | → Financial Agility


[1] Senge 1990.

[2] For example, Abolishing Performance Appraisals: Why They Backfire and What to Do Instead, by Tom Coens and Mary Jenkins; and Stop the Leadership Malpractice: How to Replace the Typical Performance Appraisal by Wally Hauck.

[3] Pfeffer 1998.

[4] LeBlanc & Mulvey 1998.

[5] Donnellon 1996.

[6] Pfeffer 1998.

[7] Rosen 1989.

[8] Unless otherwise noted, examples and quotations about the various reward types are from Parker, McAdams & Zielinski 2000.

[9] Murray & Gerhart 1998.

[10] Stewart, Manz & Sims 1999.

[11] Weisbord 1992.

[12] Crandall, Wallace & Bisgeier 1997.

[13] Ibid.

[14] Achilles A. Armenakis and Arthur G. Bedeian, “Organizational Change: A Review of Theory and Research in the 1990s,” Journal of Management 25, no. 3 (June 1999): 293–315, https://doi.org/10.1177/014920639902500303; Richard M. Burton, Børge Obel, and Dorthe Døjbak Håkonsson, “How to Get the Matrix Organization to Work,” Journal of Organization Design 4, no. 3 (2015): 37–45, https://doi.org/10.7146/jod.22549; Randel S Carlock, The Need for Organization Development in Successful Entrepreneurial Firms (New York: Garland, 1994); “Definition of EFFECTIVE,” Merriam-Webster, 2019, https://www.merriam-webster.com/dictionary/effective; Aakanksha Kataria, Renu Rastogi, and Pooja Garg, “Organizational Effectiveness as a Function of Employee Engagement,” South Asian Journal of Management 20, no. 4 (October 2013): 56–73; Damien J. Power, Amrik S. Sohal, and Shams‐Ur Rahman, “Critical Success Factors in Agile Supply Chain Management ‐ An Empirical Study,” International Journal of Physical Distribution & Logistics Management 31, no. 4 (May 2001): 247–65, https://doi.org/10.1108/09600030110394923; D.D. Warrick, “What Leaders Need to Know about Organizational Culture,” Business Horizons 60, no. 3 (May 2017): 395–404, https://doi.org/10.1016/j.bushor.2017.01.011; Chuck Williams, MGMT9: Principles of Management, Ninth edition (Boston, MA: Cengage Learning, 2017); Wei Zheng, Baiyin Yang, and Gary N. McLean, “Linking Organizational Culture, Structure, Strategy, and Organizational Effectiveness: Mediating Role of Knowledge Management,” Journal of Business Research 63, no. 7 (July 2010): 763–71, https://doi.org/10.1016/j.jbusres.2009.06.005.

[15] Simon Dischner, “Organizational Structure, Organizational Form, and Counterproductive Work Behavior: A Competitive Test of the Bureaucratic and Post-Bureaucratic Views,” Scandinavian Journal of Management 31, no. 4 (December 1, 2015): 501–14, https://doi.org/10.1016/j.scaman.2015.10.002.

[16] Eng Chew and Kenneth Dovey, “Learning to Create Sustainable Value in Turbulent Operational Contexts: The Role of Leadership Practices,” The Learning Organization; Bradford 21, no. 4 (2014): 243–57, http://dx.doi.org.csuglobal.idm.oclc.org/10.1108/TLO-05-2013-0019; C. J. Collins and K. D. Clark, “Strategic human resource practices, top management team social networks, and firm performance: The role of human resource practices in creating organizational competitive advantage,” Academy of Management Journal 46, no. 6: 740-51 (December 2003); Mintzberg, H., Simply Managing: What Managers Do—and Can Do Better (San Francisco, CA: Berrett-Koehler Publishers, 2013).

[17] Ian O’Boyle, “Traditional Performance Appraisal versus 360-Degree Feedback,” Training & Management Development Methods; Bradford 27, no. 1 (2013): 201-207,705; J. Zenger and J. Folkman, The Extraordinary Leader: Turning Good Managers into Great Leaders (New York, NY: McGraw-Hill, 2009).

[a] Bieber, Christy, ‘Pros and Cons of an Open Salary Policy’, The Motley Fool, 2018 <https://www.fool.com/careers/2018/06/28/pros-and-cons-of-an-open-salary-policy.aspx> [accessed 14 May 2021]; Conlin, Bennett, ‘Benefits and Downsides of Salary Transparency’, Business News Daily, 2018 <https://www.businessnewsdaily.com/11077-pros-cons-salary-transparency.html> [accessed 14 May 2021]; Conney, Samantha, ‘Should You Share Your Salary With Co-Workers? Here’s What Experts Say’, Time, 2018 <https://time.com/5353848/salary-pay-transparency-work/> [accessed 14 May 2021]; Quittner, Jeremy, ‘How Pay Transparency Can Help Close the Gender Pay Gap and Other Workplace Inequalities’, Inc.Com, 2014 <https://www.inc.com/jeremy-quittner/pay-transparency-and-wage-discrimination.html> [accessed 14 May 2021]

Share this page