Using fluid team structures 1) to promote new serendipitous connections and innovation, 2) to develop people for competencies rather than prescribed roles, 3) to better match those people to business challenges, and 4) to prevent emergent arbitrary authoritative deference and improve idea generation, analysis and evaluation by removing pre-existing valuations due to the source or position of originators (basically, make it easier for people to speak their mind in a mutually respectful way).
- Fixed teams limit tacit knowledge transfer outside of organizational silos and preclude the serendipitous connections between people and ideas on which innovation depends
- Repetitive, routine work can lead to monotony and diminished motivation and can inhibit “flow”
- Familiarity eventually leads to static mental models; anchoring and availability biases make it harder to see old problems in new ways; “if all you have is a hammer, pretty soon everything starts to look like a nail”
- Negative social dynamics can become calcified over time, within silos and between silos, and bad habits can be harder to break than developing entirely new habits
- Cognitive dissonance can lead people to defend the status quo in the face of necessary change
- Titles of authority can intimidate junior members, inhibiting the open discussion of ideas, and embue a false sense of confidence in ideas originating from an authority figure
- Replace organizational silos with networks the more accurately reflect real social interactions and relationships
- Value, develop and organize people around competencies (e.g. leadership, formal communication, statistical analysis, design aesthetics) rather than functions or roles
- Match skills and experience to business challenges to assemble a lean "dream team"
- Re-frame the business as a portfolio of projects, some shorter in duration than others, and regularly reallocate people to new project teams, allowing for team members to participate in more than one project at a time
- Rely more on informal sources of authority and influence instead of formal reporting structures and controls to enable people to move around the organization more easily
- Create new forms of performance feedback loops that eschew the annual review cycle and top-down approach to evaluations to incorporate more perspectives (peer and manager alike) into the process and avoid any tendancy to "kiss up" to the boss
- Limit the number of hierarchy levels, aspiring to a truly flat organization, thereby diminishing the interference of power dynamics and politics
The ideal state described above as the solution would disrupt many common, long held aspects of traditional corporate organizational behavior. Many of these structures evolved for the command and control requirements of reducing variability and increasing productivity in the Industrial era. Enabling a new team structure, one that allows for shorter duration collaborations and greater fluidity between teams, is more complicated than just automatically switching teams periodically. Issues of continuity, knowledge transfer, and expertise development need to be acknowledged and addressed to be sure these "short duration teams" are still highly productive and effective in their jobs.
Start with Competencies
Start by grouping people into meta-competencies that reflect a set of skills required for familiar job functions or departments. Rather than an Accounting department, people would be grouped into an Accounting competency or a Financial Analysis competency. By reframing the organization in this way, it will be easier to spot opportunities for people with the right skills to get involved in new project that might diverge significantly from past experiences.
How competencies are decided depends on the organization size and level of support for the hack. A bottom-up effort might be self determining while a hack supported from the top might use that circuspect position to estimate what are the required competencies for running the entire busienss. People could potentially be grouped into more than one competency but as these will be used to form teams, assume just one for now.
Within a given meta-competency, individuals would be teamed up into groups for professional development (with 5-12 individuals in each). The number 7-12 is selected from psychological research on optimal group sizes. This is one of the reasons why 5-7 is common in agile development and military squads are 8-13. Here decision making isn't what's most important, rather social interaction and familiarity.
Professional Development Teams and Continuity
These teams would become the most basic unit of the organization; their focus would be on continuous learning and development. Through regular meetings, team members would come to rely not on just one manager or mentor but one another, their peers for guidance and advice, help addressing business challenges and advancing their careers. These professional development teams provide a solid base for individuals to then venture out to work in various project teams. It ensure the necessary continuity and knowledge transfer to ramp up quickly on new projects and develop critical subject matter expertise.
It makes sens that each team would have a lead, a sort of career coach, to help direct efforts. Presumably this would be the most experience professional in the group, which could emerge organically but could also be an assignment. Assigning an individual to be a coach would provide another leadership development opportunity.
Sourcing Talent from Professional Development Teams
Matching people to projects would be one of the responsibilities of the career coach, and the formation of each new project team would be a matter of shopping around for the right skill set amongst employees with the capacity to take on additional work. Each team member would be assigned to projects according to the business need, the individual skill level, and professional development plan. Proactive employees could even work with career coaches to seek out new projects as part of their professional development plan so advancement could actually be redefined, not as climbing the corporate ladder but developing new skills, acquiring new experience, and incrementally taking on harder, more interesting and more rewarding projects.
The detailed logistics of setting up new projects, finding project opportunities, and sourcing talent are out of the scope for this hack, but there are a number of technology enabled solutions. Social enterprise software could make it easy to set up a market for project ideas and for professionals to market themselves internal, developing a personal brand. Even without technology, coaches and peers could use personal networks in much the same way these things get done now (improving on that status quo is another hack).
Team Durations
Actual projects could be short or long term in nature, depending on the business challenge (e.g. financial reporting would be redefined as a long term project). Short duration is not a good in and of itself; instead duration should fit the challenge to be addressed. Over time, individuals could work on a variety of each kind, and a long duration project need not have a static team. Any one individual could take on multiple projects at a given time, depending on the demands of the project. As people move from project to project, the development team would remain as the persistent anchor. Over still longer timescales, even the composition of any given professional development team could be expected to change. This ensures value from both continuity and fluidity.
Team Dynamics
Professional development team members would spend most of their time interacting and collaborating with members of their project teams, but they would also convene periodically as a development team to discuss challenges from their projects and solicit help or share learnings and best practices. These meeting simultaneously promote knowledge transfer, develop the employee network, create the opportunity for serendipitous connections and innovation, and expose team members to solving challenges beyond their immediate projects.
For the actual project teams, leads would be accountable (in the RACI sense) for business decisions related to the successful execution of the project but would exercise much less formal authority over team members. Performance evaluations would be the shared responsibility of everyone - project team members and development team members and the career coaches would all contribute to evaluations. This flatter organizational structural with more diffuse power centers would make it easier for people to move amongst projects, with less friction from power and politics.
Again, the detailed logistics of how performance reviews might change is another hack itself but the ideal is something more peer driven, and again, there are technology solutions available such as Rypple (acquired by Salesforce.com). The point is to remove sources of friction and interference by addressing their root causes. Advancement would mean taking on more responsibility, not power. Power would flow naturally from demonstrated leadership among a team of peers.
Benefits
The reframed idea of career advancement would also negate the Peter Principle. Compensation would rise according to the value added by the individual, not titles. Successful past performances would earn people the opportunity to get involved in new projects. People would compete for the chance to take on the most exciting projects and play more leadership roles (although still acting as just another member in other projects).
Headcount would cease to be such a politically charged issue tied to power and budget. Competencies would be like shared services, and rather than resources going to the darling projects, the entire business would stand to benefit from the decision to add people to a particular competency. Hiring would be driven by the need to meet business challenges and not other considerations.
People could even smoothly and seamlessly move amongst competencies, changing over to a new development team, gradually taking on more projects using that new competency, learning from the development team members already more experienced in that competency, bringing the fresh perspective of an outsider to some of the problems familiar to the team, overtime turning over old projects to individuals looking to learn and develop that competency.
Hypotheses:
- Periodically changing up team composition, while still matching team member skills to the business challenge, will introduce another kind of diversity that will lead to more innovation (innovation defined as novel thinking that creates value)
- Moving team members around will facilitate knowledge transfer so that knowledge travels further and faster
- Longer duration career development teams will enable new project team members to ramp up more quickly and even achieve a higher level of ultimate productivity
- Mobility will keep work fresh and interesting for employees, resulting in higher work satisfaction, lower churn and a higher overall retention rate
- A more networked organization will improve collaboration both within and across organizational silos as self-reported by employees and will cut down on the bureaucracy and managerial layers necessary to support operations
- More social familiarity will make performance evaluation easier, rewarding leaders and helping laggards improve
Measurement:
- Innovation – number of business innovation ideas generated (any idea for improving the business)
- Knowledge transfer – degrees of separation between questions (who has a question) and answers (person with the answer); how many people have to be consulted to get a definitive answer
- Productivity – average time to complete tasks; average time to train new team members; average quantity of work product per person
- Work satisfaction – self-reported by employees through questionnaires
- Collaboration & Bureaucracy – time spent by management on administrative tasks; time spent in administrative meetings; average wait for administrative approvals
- Performance evaluations – average performance rating of subjects versus control, before and after the experiment
Experimental subjects:
An organizational unit or silo under one executive sponsor. If the organization is large enough, individuals under the same executive sponsor in similar roles can be randomly assigned as subjects or control group members to make the results more statistically significant. Otherwise, anecdotal evidence with some suggestive data may be the best that can be hoped for. In the event there is no sponsor, volunteers can be solicited from within one organizational unit/silo as though there were a sponsor.
Organizations that already do project based work are the best candidates since it circumvents having to reframe common operations as projects and makes moving people between projects (rather than actual functional roles) easier. For example, professional service firms such as management consultancies, services and account management units, R&D and prodcut development. Indeed, some of these examples might realize outsized benefits from this new team structure.
Control group:
Assuming the smallest scale for the experiment, the control group would be all the other organizational units not participating in the experiment. Experiment results could also be compared against the baseline of the experiment participants, pre-experiment. If the organization under the executive sponsor is large enough, the control group should be randomly selected from the same population as the experiment subjects so that both have a comparable average-makeup (e.g. good performers vs. bad, new hires vs. veterans, quants vs. poets, etc.)
Timeline:
First 30 days
If it seems practical secure an executive sponsor. Otherwise, solicit volunteers to participate in a weekly "coffee chat" focused on career development and advancement. Chats can be held at a convenient time for everyone, onsite or off, with actual coffee or not. The most important thing is meeting with regularity and in an environment that is free of distractions; this isn’t a happy hour. Coffee chats emulate the role of the professional development team in the ideal solution.
If the number of responses exceeds 14, split the coffee chat group in half, aligning to competency areas as best as possible. No need to nominate a “coach” for the group; rather, let roles within the group evolve organically. Coffee chats should focus on career and professional development as well as trouble shooting actual problems that people are facing in their job.
Make it clear upfront the purpose of the coffee chat and the experiment goal. Ensure everyone is bought in and committed to participating. Explain the hypotheses and hoped for benefits to the participants.
Take some baseline measurements of the variables described above (innovation, job satisfaction, productivity, etc.) Coffee chat participants can help collect these as homework after their first meeting. Continue tracking metrics where appropriate on an ongoing basis, e.g. every time the coffee chat is able to connect a participant to an answer, record the degrees of separation it took.
Second 30 days
Use the coffee chat network to seek out opportunities for participants to get involved in new and different projects, perhaps one team member switching out for another. If none seem to be readily available, consider proposing a project as a group that will add some business value. The goal should be to get at least one person and ideally everyone involved in at least one new project over the course of the experiment.
If participants join an existing project, metrics on that project before and after will provide important comparisons. Given the brevity of the experiment duration, some of the most important measurement will be on the ramp up period - how quickly are new team members able to get up to speed and attain maximum productivity.
Final 30 days
Continue meeting weekly, discussing professional development and job challenges. Begin collating metrics for the experiment subjects and the control group that did not participate in the experiment. Present metrics to the executive sponsor (if there is one) or to management to elicit support for a longer term, expanded experiment.
ALTERNATE CASE
The above experiment is a rather generic design for all forms of companies and projects. Some more specific scenarios might allow for being a bit more “aggressive” in testing the impact of cycling through several projects during the experimental period. One hypothetical could involve a software development unit with four product development groups/teams, each working with development cycles of a year or more (presumably at the end of each cycle, teams are reorganized based on new developmenht priorities).
- The roles/competencies across these teams are relatively uniform, so they can be rotated relatively easily across teams
- The experiment would focus on seeing the impact of rotating people in an out of teams during the cycle, as opposed to waiting for the cycle to reach its natural end
- The experiment would be conducted in two teams, while the other two would be the control group
- The teams in the experiment would do competency mapping and organize dev teams along the competencies; in addition, they would rotate people sharing the same competency from one team to the next (in some cases, it might make sense to do one rotation in a 12-month period; in other cases, it could happen more frequently)
Thanks to Michele Z., Jim S., and Todd F. for their contributions to this hack.
Ben, the topic is really interesting and hope your approach will find its supporters. But some practical questions stay unclear. First of all, How can we identify the collaboration and bureaucracy time - this measure is indeed important. Secondly, how can you recommend to deal with unwilling team member to change his position? And how often does this replacement take place?
- Log in to post comments
You need to register in order to submit a comment.