Skip to main content
Consortium for Service Innovation

Early Adopters and Lessons Learned

Consortium members have been thinking about and testing Intelligent Swarming concepts for many years. The speed at which any of the models the Consortium works on is dependent on the members' willingness, and more importantly courage, to try something that has not been done before. While everything in this guide is based on member experience (or related academic research validated through operational experience), we don't yet have all the answers. Elements of the framework are still in a discovery phase.  We are focused on describing what we have learned about how to implement Intelligent Swarming.  At times, it is also helpful to describe what not to do.  The power of collective thinking and collective experience often lies in the lessons learned about what didn't work.
Case Studies:
Following are some of the key lessons learned from the early adopters.  
 

Don’t Over-Engineer the Process or the Tool

  • The knowledge workers who are collaborating should be the ones to design and own the process, the People Profiles, and the functional requirements.
  • The process and People Profiles don't need to be perfect - they only need to be good enough to get started.
  • The process and profiles may start out as mostly manual, but from that, we will learn what they optimally need to be.  Starting manually helps define the functional and integration requirements.
  • Expect there to be many iterations on the process, profiles, and functional requirements.

 

Culture Change is Critical

  • It’s ok to ask for help! Our past focus on individual contribution has created a sense that asking for help is a sign of weakness or incompetence.  We need to assure knowledge workers and managers that asking for help, at the right time, is a good thing. 
  • A balance of individual measures and team measures is necessary.  With Intelligent Swarming, resolving issues becomes a team sport. We expect that much like an Agile development environment, measures in a mature Intelligent Swarming environment are largely team-focused. 
  • 1st and 2nd line managers must shift their mindset.
    • Bounded vs boundless: a bounded management mentality of "my team" and "our work," or creating contests or competition between teams, is death to a collaboration model. To optimize the capability of all the skills in the organization, we have to embrace a boundless mentality that is focused on customer success and productivity - or at least the higher-level goals of the organization.
    • Managers are coaches and facilitators - not directors of work or judges.  Gary Hamel says it best in his forward to the book The Open Organization:

"The human capabilities that are most critical to success - the only ones that help your organization become more resilient, more creative and more, well, awesome -- are precisely the ones that can't be "managed." - Gary Hamel

Consistency and Communication

  • The rate of change in organizations today makes it hard to keep everyone informed.  Leadership must double down (or triple down) on communications.
  • Leadership must take accountability for people's understanding and buy-in.
  • As with any serious change initiative (and Intelligent Swarming is a big change for most organizations), consistent messages on why we are doing this and what it means to each of the stakeholders is critical. For the messages to have an impact, they must be frequent and consistent. And, leadership's behaviors and focus must align with the messages. 
  • Don't just change the label; change the behavior and attitude.  We often have a tendency to change the vocabulary ("Now instead of escalating, we are collaborating!") while we keep doing the same behaviors.  Our behaviors and attitude must reflect "we," rather than "us versus them."  

 

Collaboration and Intelligent Matching

  • Not all issues are worthy of collaboration.  A common misperception of Swarming is that many people are involved in the resolution of each issue. This is not the case if our intelligent matching capability (whether manual or automated) is good at getting the issues to the person best able to resolve the issue on the first touch. This greatly reduces the probability that the first responder will need assistance. The initial swarm is the requestor (customer) and the responder.  If additional resources are needed to resolve the issue, then the next best resource joins to help solve the issue. Multiple resources work on the resolution only if the situation warrants it.  
  • Don't just use "experts" to help. If someone needs assistance, that request should be visible to those in the next higher skill level for that topic - not necessarily to the most expert. This is an important consideration in designing the skills profiles.  A skills hierarchy of three (novice/interested, capable, expert) is the bare minimum, and a skills hierarchy of five will give us more accuracy and diversity in the intelligent matching capability.  
  • The power of autonomy.  Freedom of choice - a sense of control over my activities and my work - are critical motivation factors in Intelligent Swarming. If intelligent matching becomes an assignment engine instead of how we manage visibility of relevant work to people, we have lost a key motivational element.  The enthusiasm and commitment I have around work I choose to do is dramatically different from work I am told I must do. We refer to this as the opt-in factor and it is critical for a successful and sustainable adoption.  The typical reaction to this is, "What if nobody opts-in?  Certainly no one will opt-in for the really tough issues!"  To this we say: oh ye of little faith.  First: do we trust the people we employ to make good judgments?  Second: have our historical measures created an "avoid the hard ones" mentality because we measure volume instead of value?  Third: if we begin to recognize those who are creating value instead of those who are just busy.... we will be encouraging knowledge workers to take the hard ones.  All that being said, we still need to have triggers and exception monitors in the system that will flag requests that may require intervention. If we do it right, the exceptions will be infrequent.     

 

  • Was this article helpful?