The Rational approach to technical enablement

from The Rational Edge: Read how two leaders in the IBM Rational organization describe the challenges and practices of preparing customer-focused field teams to help businesses succeed. This content is part of the The Rational Edge.

Share:

Darrel Rader, Manager, WW Technical Enablement, Rational Expertise Development and Innovation, IBM

Darrel Rader is the worldwide leader for technical enablement within IBM Rational and has been focused on improving capabilities of both customers and the Rational technical community for the last seventeen years. Lately he has been working to change the traditional paradigm for learning by finding ways to leverage Communities of Practice as the foundation for establishing a collaborative learning environment -- one that accelerates the building of technical expertise within Rational and for our customers.



John McDonald, Technical Sales and Enablement Executive, Rational, North America, IBM

John McDonald leads the technical sales team for Rational in North America. For thirteen years he has held various positions in the software sales business at IBM, including expanding the first Software Architect team, creating the Technical Exploration Centers network of customer and partner facilities, and helping to design and lead the TechWorks and SkillWorks organizations, focused on delivery of technical sales infrastructure and training and enablement for IBMers and business partners.



12 November 2008

Also available in Chinese Russian

illustrationA knowledge worker is someone who develops or uses knowledge in the workplace. Within the IBM® Rational® brand, the Rational services and technical sales organizations arestaffed with hundreds of knowledge workers dedicated to ensuring the success of our customers. Perhaps you have worked with one or more of our team members at some point during a Rational implementation, training session, or demo. Improving the abilities of our knowledge workers is at the core of what wecall "technical enablement," the process of effectively tapping into and maximizing each knowledge worker's expertise potential as it relates to your business.

The turbulence of the software and systems delivery space defines our era of constant change, which author Stephen R. Covey compares to steering through a river's whitewater rapids. Suddenly, a change in the general terrain requires you to use far more advanced navigational skills than your trip has thus far demanded. Over the years, the Rational organization has evolved and expanded its marketplace to address similar challenges associated with rapid change in the software and systems delivery landscape. Today, we are confident that our own whitewater experiences can help customers through their difficulties and on to business success. But to get there, they need much more than tool experts. They need to partner with a company that can leverage the collective information and experiences gained across the globe, not just from a single source of technical knowledge.

This articleis written for our customers and others who have a similar concern or passion for discovering and providing new and innovative ways of improving the abilities of knowledge workers. Our intent is to explain the ways in which the IBM Rational organization continually develops expertise in the context of rapid change, and how we refine our skills through Communities of Practice engaged with our customers and partners.

The enablement challenge

Peter Drucker, well-known management expert, coined the term "knowledge worker" to mean someone who develops or uses knowledge in the workplace. In the IBM Rational services organization, improving the abilities of knowledge workers and organizations, specifically related to software and systems delivery, is at the core of what we do. It applies to our technical sales, services, business partners, and ultimately our customers. We call this effort "technical enablement," which is the process of effectively tapping into and maximizing each individual's expertise potential as it relates to our business.

Originally an independent company, the Rational organization was founded in 1981 with a very simple yet important mission: "To ensure the success of our clients who depend on their ability to develop and deploy software and systems." Obviously, the world of software and systems delivery isn't what it was in 1981, and it continues to change at an astonishing pace. Change is definitely the norm. However, through the numerous acquisitions and restructurings, including the IBM acquisition of Rational Software, Inc. in 2003, our mission has remained intact. The key phrase from our mission statement still describes the core of the challenge: "...their ability to develop and deploy software and systems."

The true value of our offerings does not lie solely in the tools being installed and set up. Customers only achieve value from adopting tools and effectively applying them in the context of their business to achieve the results they need. This requires understanding the concepts, processes, management, and effectiveness of how they can apply a combination of new tools, processes, and skills across their organization to achieve their desired results; all while continuing to meet the demands and pressures of their current business.

Providing expertise beyond product knowledge

Our customers depend on our technical sales and services teams for more than just product knowledge: they need IBM to understand their unique challenges and help them improve their abilities to achieve timely results. This implies that, prior to making a decision to invest in a solution, they need to reach a certain level of trust that IBM is going to help them achieve the expected results. As Stephen M.R. Covey notes in his book The Speed of Trust, demonstrating competence and a track record of delivering results are the most effective ways to increase trust. Competence, in this case, means having the skills and knowledge necessary to improve others' abilities, whereas the track record means having experience doing this effectively. In other words, our customers need expertise.

Responding to rapid changes in the market (innovation)

As a leader in the Software and Systems delivery space, we know our customers expect our people to be on the cutting edge, not only with our tools, but with processes and methods. Many of our technical people are working with our customers and our development teams to solve problems that have never been solved before. When you're on the front edge, you are forced to learn while doing, applying experiences along the way. Waiting for a basic training class or a book isn't an option, because there are no other experts to turn to. One of our responsibilities to our customers is to provide the guidance from our early experiences. Evidence of this can be seen in intellectual capital such as the Unified Modeling Language (UML), the IBM Rational Unified Process® (RUP®), numerous practices, books, course materials, whitepapers, and most recently the Measured Capability Improvement Framework (MCIF.)

Expanding our marketplace

In the fall of 2006, the Rational software organization began a dramatic growth curve as its market expanded beyond development tools and process into managing software as an asset in any size organization. Specifically, several large acquisitions and internal product transfers allowed us to enter entirely new markets (complex systems and embedded software with Telelogic®, and enterprise modernization and mainframe software with product shifts from the IBM WebSphere® brand). In addition, the Rational software organization expanded its focus in the IT market beyond software developed in-house into the management and governance of software assets; particularly software inherited, purchased, or commissioned from a vendor.

In addition to market pressures and IBM's need to provide real solutions, IBM continues to face the realities of being a successful, competitive global business. This has resulted in the following enablement challenges:

Effectiveness of enablement. Like all companies, we've long needed to do more with less: build the right skills portfolio, maximize our investments in relevant skills, and minimize time away from customers.

Silos of intellectual capital development. We discovered numerous redundant or overlapping intellectual capital development efforts across our organization. Acquisitions have made this even more of a challenge as we integrate new organizations.

Expense pressures. Like most companies, we've experienced increased pressure on expenses associated with travel and living costs for training. We needed to be able to show a higher return on investment than we had experienced from traditional training methods.

In his book, The Eighth Habit -- from Effectiveness to Greatness, Stephen R. Covey makes an observation about our world. Approximately 60-70% of what goes into all of the products sold in today's market comes from knowledge work, compared to 20-30% just twenty years ago. This comes as no surprise to people who have been involved in the field of software and systems delivery; it certainly feels like the epicenter of this wave of change. Dr. Covey compares being in the world today to being in permanent whitewater: "We live in a constant, churning, changing environment. In turbulent whitewater, every single person must have something inside of them that guides their decisions." He goes on to say "If you try to manage them [the knowledge workers], they won't even hear you. The noise, the roar, the immediacy and urgency of all the dynamic challenges they face will simply be too great."

This insight can also be extended to the technical enablement of our services teams. In this age of rapid change and increased impact of knowledge work in the global marketplace, we need to enable our people in a way that maximizes their individual potential versus teaching them everything we want them to learn.


Foundational principles

Over the last several years, we have identified a set of foundational principles that serve as our compass. While some of the words might have changed, the principles have remained constant.

Experiential learning from others. The vast majority of what is learned comes from individual experiences and the experiences of others, not from a book or a training class. We must cultivate a strong collaborative environment that reaches beyond organizational or geographic boundaries and encourages mentoring and working with others in the context of customer engagements.

Expertise from practitioners. The people closest to our customers have valuable experiences to share. As a result, enablement cannot only be treated as a top-down flow of knowledge from a worldwide team. Knowledge and experiences need to flow freely throughout the community among practitioners.

Enablement as a business investment. We must assess costs versus returns and risks versus advantages when considering investments in enablement.

Constant improvement and innovation. When there is no precedent set, individuals learn while working closely with others to solve new customer problems. This results in new experiences that are shared with others and form the basis for future iterations of intellectual capital.

Enablement everywhere. We must use a spectrum of delivery methods and effectively leverage distance learning and collaboration technologies to design enablement into everyday work life, resulting in more opportunities for practical application.

Individual ownership. The responsibility for learning and building expertise must ultimately fall to the individual with support from their manager. The majority of the enablement requires a level of self-directed discipline and passion.


The Community of Practice model

Before getting into the details of the enablement framework, it is important to have a high-level understanding of the Community of Practice model, which serves as the foundation for our technical enablement strategy.

According to Etienne Wenger (a recognized expert on Communities of Practice), Communities of Practice ... are groups of people who share a concern or a passion for something they do and learn how to do it better as they interact regularly."

Consistent with this concept, we've found that one of the motivating factors for technical people is the chance to connect with great people and make a real difference. These connections tend to come in many different forms, all of which act as accelerators to building the expertise relevant to meeting the needs of our customers. With the right leadership and supporting infrastructure, Communities of Practice are a primary mechanism to make it easier for these connections to take place.

Wenger describes three critical components to establishing Communities of Practice.

The domain. A Community of Practice is not merely a club of friends or a network of connections between people. It has an identity defined by a shared domain of interest. Membership implies a commitment to the domain, and therefore a shared competence that distinguishes members from other people.

The community. In pursuing their interest in their domain, members engage in joint activities and discussions, help each other, and share information. They build relationships that enable them to learn from each other.

The practice. Members of a Community of Practice are practitioners. They develop a shared repertoire of resources: experiences, stories, tools, ways of addressing recurring problems -- in short, a shared practice. This takes time and sustained interaction.

Excellent examples of Communities of Practice are found in the medical profession. Small groups of doctors collaborate and learn from each other as they work toward a common goal of finding new cures. They then share their findings and experiences through conferences and publications in medical journals. Together, they advance their practice and expertise. At any point in time, a group may be a producer of experiences to share while others in the community may be consumers.

Rational Communities of Practice are groups of practitioners from around the world and across the organization who share a common concern or passion for improving methods and practices -- innovation that matters to our clients -- focused on specific domains or segments within software and systems delivery. They come together as a community to find ways to improve their method and practice.

Membership is voluntary, but is highly recommended for all Rational practitioners because it is the primary method of connecting and collaborating with fellow experts around the world within a common domain. Practitioners come from technical sales, technical services, development labs, technical support, IBM Global Services, marketing, and business partners. The connection with our development labs is extremely important, in that this builds strong relationships between the people building the products and the people who are closest to understanding how to apply our products to solve customer problems. This collaboration is essential to our ability as an organization to develop both the products and expertise needed to help our customers achieve their results.

While Communities of Practice are informal organizations, we have made an investment in this model as a foundational component of our technical enablement and our business. In addition to some dedicated community leadership roles, all of our technical enablement content, proof of technologies, customer courses, practice and method content, and service offerings are organized on our Communities of Practice structure. It's important to note that these roles are filled by customer-facing practitioners whom we have asked to lead by example with our customers.

The overall purpose and reason for this investment is that Rational Communities of Practice are tied directly to accelerating our client results and, in turn, the IBM Rational business. Accelerating our client results has three main components:

  • Productivity -- Solve problems and find answers faster, building intellectual capital from what we find once (and once only), and reusing more assets, templates and frameworks
  • Quality -- Solve problems more capably for our customers by bringing more experience and expertise to the table, providing quicker feedback to development, and reducing the time to value
  • Innovation -- Working together across organizations and geographic boundaries to accelerate our ability to solve new problems that customers face and then documenting and sharing new methods, practices and ideas

The role of technology in Communities of Practice

Like most Communities of Practice, members are geographically dispersed; disconnected by more than a cubicle wall or a hallway. Interpersonal connections are not maintained face-to-face, so we need to leverage technology to help us communicate across the globe. We have developed a Community of Practice infrastructure for each community, as shown in Figure 1. This infrastructure brings the latest learning and collaboration technology together with a primary purpose of connecting members of the community. For example:

  • Small Group workspaces using wikis, Lotus® Quickr™ sites, and IBM Rational Team Concert (based on the IBM Rational Jazz platform)
  • Online discussion forums using IBM Forums
  • Synchronous connections like IBM Lotus Sametime® and IBM Lotus Sametime Unyte™
  • News, calendars, information channels using RSS feeds and podcasts
  • Online learning spaces like the IBM Learner Portal
  • A practice library of case studies, assets, frameworks, guidance, and roadmaps (currently migrating to IBM Rational Asset Manager)
  • Access to experts on various topics

Diagram shows variety of communication methods

Figure 1: The IBM Rational Community of Practice infrastructure provides a number of different ways for members to connect.

If you're interested in understanding more about Communities of Practice, there is a great book by Etienne Wenger, called Cultivating Communities of Practice (more by Etienne Wenger can be found in the References below).


A framework for technical enablement

We must have technical professionals that not only understand Rational technology, but also have knowledge and experience of how that technology applies to our customer's business. Ultimately, we need to build trust with our clients through demonstrating credibility. There are three types of skills needed by our technical professionals. These skills are highly dependant upon each other, and their interdependence needs to be understood if we are going to be successful in building trust with our clients.

Knowledge and skills about the products and offerings. These are skills that all sales, technical sales, and services people (including business partners) need in order to effectively help our customers understand the value for what we bring to the marketplace, which in turn provides the opportunity for us to work with our customers to ensure that they achieve the expected value. Product skills focus on how and why the features and functions contained in our portfolio provide operational capability that differentiates us in the market. Offerings knowledge provide skills such as diagnosing a customer's challenges, understanding the associated impact, demonstrating to a customer how we can address their challenges, helping a customer understand the path of adoption, and helping a customer understand the value. In order to be effective with these skills, there is a strong dependency upon the credibility skills as well as the "soft" skills mentioned below.

Credibility skills. These skills represent the expertise that our customers see direct value in, and are accordingly willing to pay for. This means having a track record -- i.e., relevant experiences with both the problem and the solution space -- effectively applying Rational's offerings to different types of customer needs. This expertise demonstrates to a customer that we have been there and done that enough times that they can trust us to effectively help them improve their abilities and achieve their results in a timely manner. This expertise comes from years of experience in the trenches with our customers, and in most cases it can't be taught. Our enablement strategy assumes that people have a strong foundation of knowledge, skills, and experience. This varies somewhat with the segment or domain; however, it's important in that there is no quick fix for lack of experience and competence.

"Soft" or non-technical skills. These are foundational professional skills that allow our people to effectively engage with our clients to develop trust. These include skills such as listening, negotiating to win/win agreements, communicating effectively, mentoring, facilitating, problem solving, and consultative selling. These also include reinforcing IBMs core competencies.

The overall technical enablement strategy that was developed consists of three types of enablement to provide focus on these three domains of skills:

Launch Driven Enablement. Focused primarily on the base technology knowledge and skills associated with new products or offerings, enabling people to fully understand the new customer needs that we are addressing and how the launch (combination of tools, process, and expertise) can address their needs.

Community Driven Enablement. Focused primarily on building expertise, providing opportunities for people to gain the right experiences within the context of our customers through connections with experts from across the community.

Management Driven Enablement. Focused primarily on the professional "soft" or non-technical skills. The enablement efforts are targeted at the management team with the expectation that they in turn facilitate local workshops, mentor and coach, and provide day-to-day feedback on these skills with their teams. In addition, this provides managers with skills on how to effectively build a business.

In the same way that these skills are not mutually exclusive, these three types of enablement must be applied and considered together as one unit, as shown in Figure 2. Each part does not work separately or alone.

Shows three types of enablement under discussion

Figure 2: The three types of enablement work together as one system with a core focus of building trust with our clients.

Launch Driven Enablement

The dramatic increase in the number of product changes that the IBM Rational organization is bringing to the market, coupled with the fact that customers need expertise on how to apply the tools to address their needs, means that changes have to be made in the approach to enablement related to our product releases. Launch Driven Enablement includes a process (see Figure 3) put in place to formalize building the enablement collateral, the initial knowledge and skills, and the initial foundation of expertise in concert with the development of the product. This allows us to demonstrate a level of expertise in our initial customer opportunities and enables us to build an initial track record of success.

Designed to develop the base knowledge and skills associated with new offerings, Launch Driven Enablement is the segment of the overall enablement strategy that focuses on:

  • Aligning our understanding of new capabilities with the key business value proposition provided by marketing, which ensures all marketing, sales, and technical enablement are synchronized; thus assuring our customers receive consistent messaging at all levels.
  • Forming a starter team to collaborate with the development team early in the Integrated Product Development (IPD) process on understanding the practical application and usage models of a future offering. This group forms a foundation of real expertise that can be used to accelerate building the next group of experts.
  • Building a group of localized experts called regional mentors.
  • Bringing all of the intellectual capital (IC) and building a consistent set of collateral based on those early experiences, leveraging regional mentors as participants.
  • Leveraging the IC built to establish a well-designed course architecture that will be used to iteratively build different "courses" targeted at multiple audiences.
  • Providing the initial level of enablement to the appropriate audiences.

The result is a core set of regional experts along with a base set of knowledge, skills, and enablement collateral -- all within reach as close to the general availability date of the offering as possible. It's important to note that this is not the end of the enablement surrounding a launch. This is intended to provide a launching point for the credibility skills that only come from experience.

Shows launch driven enablement phases

Figure 3: The Launch Driven Enablement phases deliver enablement collateral and skills in parallel with product development efforts.

The Launch-Driven Enablement phases are:

Readiness (Phase 0)

Many months prior to the anticipated launch date, before the beta testing phase, a decision is made as to which community or communities will find value in applying the new technology to the problems and opportunities their customers face. A launch Core Team is formed with membership from the appropriate community leaders from different parts of the organization. By connecting all the players in collateral development with a common process (connected to the Integrated Product Development -- IPD -- process), we ensure that the same scenarios used to drive product development decisions carry through as a common thread, to all enablement material built around the technology (see Figure 3 above). In the past, new and differing use cases were developed for product function decisions, for demonstration scripts, for online help, for classes and tutorials, for partner enablement, for customer courses, and for many other purposes. By simplifying scenarios to one common thread, we achieved a dramatic reduction in work required to create the material, a reduction in the overall quantity of material to create and review, as well as a dramatic improvement in its quality and relevance.

Initial knowledge transfer (Phase 1)

The launch Core Team, in collaboration with product development, builds the initial set of enablement collateral by drawing from their own background and early experiences with alpha and beta customers. This collateral might include drafts of white papers, documented case studies, sample presentations, early prototypes of training modules, and sample usage models. This phase produces the first iteration of a "course" that is sufficient for initial enablement to the advanced audience -- which implies mostly self-directed project and customer work (learning by doing). Nevertheless, as we began to understand this phase we realized the importance of treating this as an iterative course development effort with multiple variants. As a result, we have started using the same infrastructure (the IBM Learning Portal) to deliver as planned for future iterations to multiple audiences including our customers.

Develop intellectual capital/regional mentor program (Phase 2):

While all phases of LDE are important, the success of our enablement efforts for a launch hinges on our ability to build out the existing collateral to develop the initial library of sales, technical sales, and customer-facing collateral, as well as to establish a group of regional mentors. It is extremely important for the integrity and relevance of the launch that the experiences and innovations of senior experts from around the globe become integrated into this process.

More than a simple "train the trainer" model where people learn to cascade a set of slides and labs to their peers, the regional mentor program is an advanced, multi-week program designed to build expertise. As a critical part of their learning experience, the regional mentors collaborate with the launch core team to build labs, case studies, and other collateral needed to build initial knowledge and skills. The program consists of self-study assignments, a face-to-face workshop with the Core Team and experts from development labs, participation in small-group projects to build or update specific intellectual capital artifacts, participation with experts in early (beta) customers, and supporting initial online launch courses delivered as part of the general enablement. Upon graduation from the program, regional mentors are expected to lead workshops in their regions, if needed; and to mentor others while leading in initial customer engagements, as driven by the business needs in their region. In addition to building the skills of the regional mentors, this phase delivers the second iteration of the "course," which now contains multiple variations of a "course" targeted at the different field audiences and business partners.

General enablement (Phase 3)

With the volume of launches, business pressures (including travel costs and the need to minimize time away from customers) forced us to re-think the old "training" paradigm in which face-to-face enablement was considered the only option. In doing so, we discovered that in some cases, distance learning, if done right, can actually result in improved learning over traditional face-to-face. As a result, general enablement leverages the latest distance learning and collaboration technology to fit the specific enablement needs. From a student's perspective, the course is a combination of on-demand modules (recorded Webcasts and podcasts featuring the most senior experts, whitepapers, case studies) along with interactive sessions with experts including virtual hands-on labs that allow for "shadowing" as well as small group interactive discussions facilitated by local regional mentors. The regional mentors act as a global support structure providing convenient access to local experts, thus reducing the challenges with time zones and languages. By delivering in this manner, the course can be taken over a period of several weeks, allowing people to learn in smaller. more consumable increments that are easier to fit into their hectic schedules. The feedback from the initial delivery to the field is then applied to create a third iteration of the courses that can be used to enable our customers.

Deep skills enablement (Phase 4)

As "book or classroom knowledge" is not enough, in this phase local teams engage with their regional mentors in the context of initial opportunities. This provides a steady growth of skills in the territories as members of the community gain real customer experience with the technology. This phase is the transition phase from Launch Driven Enablement to Community Driven Enablement as the members of the community engage with customers and each other to improve the overall practice in this space.

The value of Agile and iterative collateral development and enablement is never more obvious than when applied to Launch Driven Enablement, as each phase builds additional collateral depth and granularity while broadening understanding. Like Agile development, this approach allows Rational to start building skills early and quickly through a series of smaller iterations and releases.

Not every product launch requires the full complement of collateral and investment as described above. Some product launches require less enablement investment for both our technical people and our customers. Determination of this relative importance is part of an overall governance initiative for our technical enablement strategy.

Community Driven Enablement

Community Driven Enablement is focused on learning together and building expertise based on the collective experiences of the members of the community. Once the base knowledge is gained from Launch Driven Enablement or some other learning activity, it's critical that our technical people continue to build their skills and expertise through interacting with others in real-world situations and applications. Indeed, the majority of effective learning comes this way, contrary to the conventional wisdom that most learning comes from a book or a class.

While mentoring and apprenticeships within real customer engagements are necessary and essential to accelerate building expertise, the heart of Community Driven Enablement is the small groups that are formed to respond to specific needs within a community. Within a community, there exist pockets of common interest that unite people around a shared goal or problem. In fact, small groups help to spark mentoring and apprenticeship opportunities based on increased trust and understanding between members, as shown in Figure 4.

Shows relationship of small groups to core team

Figure 4: Launch Study Groups are led by regional mentors and provide localized learning opportunities where people can discuss relevant challenges.

Small groups

Small groups come in many different shapes and sizes. The following are just examples of different patterns of small groups that we have seen so far. The possibilities are endless as people find new and creative ways to leverage others within the community.

Launch study groups. Regional mentors working with people in their local region to complete parts of the virtual launch course together with interactive discussions about local customers and needs. In this way, they leverage experts worldwide using recorded sessions, yet, are able to bring local relevance to the local group.

Learning study group. People who need to learn about a common topic; could be formed around a new industry regulation, a new process model, or a new technology trend.

Problem solving study group. People who need to understand something that isn't well-understood within the community. After reaching a level of understanding, the group shares their findings with the rest of the community.

Project groups. People who work together on building a reusable asset that will be part of the practice. For example, they may work on a Proof of Technology, a course, a case study, a framework, or process guidance. In many cases, these also involve collaboration with members from the development organization.

Customer project or review group. People come together around a specific customer issue, such as reviewing an architecture document or building a complex usage model.

Launch Driven Enablement regional mentor groups. These people are part of a group nominated by managers to attend an advanced, multi-week program to learn about the new launch prior to the rest of the field. As such, a large part of their learning is project work where they collaborate with others in the group to contribute to assets like labs and case studies that are used in the iteration of the launch course for general enablement

Local small groups. People who work out of the same office get together regularly to discuss common issues with specific customers.

Topic or domain study group. People who interact on a regular basis and are focused on a specific set of customers in a common industry, domain, or geographical region.

Rational residency program small group. These people are part of a group nominated by managers to attend an accelerated, multi-week program in which the residents participate in many different types of activities including onsite work with customers, working along side senior experts as apprentices.

Informal discussion forum groups. People rally around a specific topic, sharing ideas and experiences using a discussion forum as the vehicle to communicate

By acknowledging and highlighting these different connections, Community Driven Enablement cultivates the sharing of knowledge and experiences needed to build real expertise. Compared to traditional large group training classes or seminars, small groups tend to have higher interaction and application (and retention). From a return on investment perspective, we are finding that small groups yield the applied skills and knowledge needed to build expertise.

Small groups can be spawned by the leadership Core Team in response to a specific need within the business such as a new launch, or be born from individual initiatives within the membership itself, such as a new customer challenge. Together, these provide a unique "sense and respond" mechanism for the benefit of our customers, as we need not wait for a new product launch or formal enablement initiative to take action and start building the necessary expertise. The reason that people participate in small groups is to interact with others concerning something that has direct relevance to their job.

Small groups "meet" either virtually or face-to-face throughout the year. Face-to-face meetings that require travel and significant time away from customers are considered a business investment and as such are managed with an eye on the expected return. In most cases, they tend to meet a few hours every week depending on the group and their schedules. One of the reasons for keeping these groups small is that it's easier to synchronize a few peoples' calendars than trying to do the same for a large group. Project groups usually need an online collaboration workspace -- a wiki or teamroom -- that can be created as part of the initial small group setup process. Other types of groups have the option to capture their purpose and goals on the community Web site small group page.

Assets created

Traditionally, being involved in a project has not been considered enablement, but it is perhaps one of the strongest forms of learning. Beyond the immediate value of new skills and the contribution to the practice, the network built through participation in small groups speeds the access to resources, perspectives, and community assets long after the group dissolves. In addition, the small group online structure captures the names of the participants and artifacts for permanent reference by the broader community. This is an excellent way to access what is known as "tribal knowledge" -- the written or unrecorded knowledge within an organization. By knowing the names of the group and what they worked on, people on the periphery may connect to ask questions and gain valuable insight into this largely untapped knowledge source.

The assets created by the small groups form the foundation for the practice library. Community members can add to the library material created individually or harvested from some experience, such as expert speaker podcasts, or the results of and artifacts from a successful customer engagement.

On-demand learning within the community

While connecting with others and participating in a small group is important, there are times when people prefer or need to learn in other ways. Community Driven Enablement leverages the community infrastructure to provide easy access to different types of learning, such as:

  • Listening to IBM Rational chats and podcasts. Experts share their experiences and knowledge with others in the community. These are very similar to seminar type sessions with minimal interaction. We leverage podcasts as much as we can as a delivery vehicle to allow and encourage people to listen to these while traveling to and from customer sites. If the person has a question, there are connected discussion forum threads available.
  • Downloading and reviewing assets that others have successfully used in customer engagements
  • Attending recommended Web-based training or other instructor-led training
  • Finding answers to questions on the discussion forums.

The Community Jam

Community Jams are our premier, face-to-face events. Unlike more traditional approaches to enablement that rely on large events as their primary education mechanism, the Jam is a foundational component. Jams not only yield immediate business value from the small-group interactions, but also they provide fuel to the rest of the enablement efforts throughout the year. This is especially important to the success of our approach since the majority of our skills-building relies on effective small group interactions, where face-to-face is not an option. While it is possible to have small groups in which participants don't know each other, our experience has showed that people who know and trust each other are much more effective as a small group. Consequently, it is extremely important that the entire worldwide community gathers occasionally as a single community for the purpose of building trust and relationships in the context of their domain and improving their practice.

The Community Jam is the event where this occurs face-to-face. It is structured to provide multiple ways to interact and share real-world experiences, such as:

  • Town Hall Meetings where community members have the opportunity to voice opinions and ask leaders probing and difficult questions
  • Small Group Working Sessions where ongoing small groups can find time to interact face-to-face
  • Pedestal Expo to showcase small group initiatives and their progress, to recruit participation, or simply to find others working on similar problems

Given the fact that most members are unable to attend more than one Community Jam, it is important for people to understand that all of the components of the Jam are realized in some virtual form throughout the year. This allows the community a certain drumbeat of connections to maintain of level of community unity. While small groups happen throughout the year, it is important to have Virtual Town Hall meetings regularly to discuss important community topics and allow for access to leaders.

The Jam is, in fact, an "inflection point" in the life of the community. While small groups continually start up and complete their work, the Jam is the chance to bring the community together on the "same page." Trust and relationships are at the core of everything done within the community, and face-to-face interactions accelerate the construction of strong, trusting relationships, and thus increase the effectiveness of important virtual collaboration and learning throughout the year.

It is important that we invest our time and resources in the most effective methods that provide the most return on that investment. Sending someone to a four-day, face-to-face training class without a well thought-out plan as to how that person is going to apply the knowledge and skills is no longer an option. Overall, learning that can be effectively done remotely should be done remotely regardless of whether there are travel expense constraints. There continues to be new and innovative ways to make remote learning even more effective than face-to-face. In addition, distance learning allows for enablement budgets to be used for critical connections that require face-to-face interaction such as Jams, regional mentor workshops, residencies, apprenticeships, and other critical small group workshops. Unlike most traditional enablement programs confined to a project plan and set of PowerPoint slides, Community Driven Enablement provides a dynamic, collaborative learning ecosystem in which community members work and learn together every day as they strive to react to the constant changes in the market and in turn improve their overall expertise and their practice.

Management Driven Enablement

Management Driven Enablement fosters foundational skills beyond technical knowledge and expertise. Commonly referred to as "soft skills," these include capabilities like listening, communication, negotiation, collaboration, and establishing and maintaining trust, as well as territory management and consultative sales methodologies. These skills are required of those who work in a customer-oriented organization, as they help people become better advocates of change and improvement in a customer's enterprise.

The management team plays the pivotal role in developing and reinforcing these skills through daily guidance and continuous hands-on coaching and feedback. It is insufficient for an "enablement team" to drop in and teach these skills, as they must be reinforced every day. Thus, the target of Management Driven Enablement is the management team itself.

The initial program within Management Driven Enablement was a management program in which the entire leadership team learned a common methodology for strategy and planning at the business unit level. One of the keys to this program was the fact that the focus was on running the business as one management team with three legs -- sales, technical sales, and services -- with a common set of goals and measures.

In addition to actually working with the teams to build these non-technical skills, managers are essential to making this approach work. This alignment is essential to the success of the overall approach. Their responsibilities include:

  • Hiring people with the right foundation: a combination of character, motivation, knowledge, skills, and experience. It is extremely time-consuming and inefficient to enable those who don't have the necessary foundation to build from.
  • Working with the Communities of Practice to provide a ramp-up program for new hires.
  • Treating expertise as a business asset that needs continual investment.
  • Coaching their teams to constantly learn in different ways.
  • Investing in brand offerings. Nominating regional mentors and effectively leveraging these resources in their territories.
  • Investing in critical skills. Nominating residents and supporting their participation.
  • Setting the expectation that technical professionals are responsible for their own enablement.
  • Supporting and highlighting individuals whose contributions to the communities impact both short and long term business goals.

The approach in action

From a blog from a Sarah Dramer (An imaginary member of the Change and Release Mgmt Community)

This is a true-to-life example of a blog, created to illustrate how members frequently use different types of learning opportunities within a Community of Practice:

  • 01/06/08 - Read my CoP news feeds to understand what is going on with key product announcements, enablement events, etc -- 10 minutes. I have an RSS Feed to the community site that makes this an easy way to stay up on important news from across the community. I noticed that there is a Rational Chat on Agile Development. This is something that my customers have been asking about.
  • 01/08/08 - On my way to eFone, my customer site, I listened to a recorded Rational Chat on Agile Development. It was really good. I jotted a note to myself to ask a question when I got home. When I got back home, I posted a question to Scott Ambler, the presenter, on the discussion forum. Scott is one of the leading experts on Agile. I noticed that this was part of a podcast series. I subscribed to this series so that I won't miss any future talks.
  • 01/11/08 - Posted a question on the forum about how to get around a specific customer issue. Got the answer from Burt Schmidt in Singapore from Belgium that has experience with the same problem. He pointed me to a link to the artifacts that he had used.
  • 01/16/08 - Completed module 3 of the Rational Team Concert Launch Course -- this was a virtual hands-on lab assignment that is the Proof of Technology that I'm going to need to present to my customer in the next couple of weeks. Using the shadowing technology allowed me to get instant help when I got stuck. Very cool technology. I called my regional mentor, Jimmie Ray, with a question about how this would work with my customer. He answered my question. He'd seen a similar problem when he was working with one of the beta customers during the Regional Mentor Program. I also am planning on listening to the 2 customer case study recordings (Modules 4 and 5) on my way to my customer tomorrow. The next release, I want to take on more of a leadership role. I'm going to talk to my manager about being a regional mentor.
  • 02/07/08 - It's been a few weeks since I posted last. I've been really busy with a customer engagement that is really challenging. I've learned a ton by working as an apprentice to one Jimmie Ray -- our regional mentor. We also connected with other regional mentors from Germany, India, Canada, and Spain, and Raj from the development lab. We worked for a couple of weeks (off and on) and finally solved this problem. My job was to document what we discovered and put it into the community asset library. I've never done this before and it's using Rational Asset Manager. I can definitely use some more time using Rational Asset Manager -- I hate it when I don't understand our tools.
  • 02/14/08 - Attended the Change and Release Mgmt Jam in Rome. I met several people from other parts of the world and our development team that I now know. I actually had a couple of beers with 2 distinguished engineers ... they gave me some great career guidance. We talked about an opportunity that I'm working on ... they had some great suggestions that I think I can use. They also said that I can contact them if I have problems. Over the 3 days, I met so many people (who I had seen their names on email lists). We shared valuable experiences from our customers. I am going to reuse the scripts that they've used with their customers.
  • 02/20/08 - I joined a small group with some of the people who I met at the Jam focused on building out a case study for adopting Rational Team Concert. I've been looking for these. One of the people in the group is from development and he has lots of experience with early adoptions … I should learn a lot from him. I was already thinking about doing this on my own so the commitment level of an hour a week for the next 4 weeks will fit with my priorities. This doesn't sound so bad and am looking forward to working with this group
  • 03/05/08 - Read my CoP news feeds to catch up. I noticed that there is a Virtual Town Hall Meeting next month. Looking forward to getting back together (even if it's over the phone) and being able to ask some pretty hard questions about how Rational Team Concert fits into the Telelogic picture.

Summary

Together, Launch Driven Enablement, Community Driven Enablement, and Management Driven Enablement provide a solid framework for effectively tapping into and maximizing each individual's expertise potential as it relates to our business. These approaches combine a sufficient level of planning and structure with a dynamic, collaborative learning ecosystem in which community members from across our organization work and learn together every day as they strive to stay relevant and respond to the constant changes in the market. This allows us to build trust with clients based on relevant expertise that they value: with our products, our process and method guidance, and the skills of our people.

This approach to technical enablement outlines a continuous improvement effort. We've only scratched the surface in terms of what we can do. At this point in our journey, we've realized that the following are critical to our success:

  • Experts are everywhere, and there are no organizational or geographic boundaries.
  • Investing in Communities of Practice allows our organization to be Agile and respond to the needs of our customers. People learn from working with each other in ways that traditionally might not have been considered enablement.
  • Leverage technology to make learning and collaboration easier and more effective.
  • Constant collaboration between product development and the people working everyday with our customers -- finding new ways to address new challenges.
  • Applying modern concepts of iterative and Agile development and applying those to enablement planning, development, and delivery.
  • Individuals taking ownership of their own enablement.
  • Management setting the expectations and measurements aligned with constant improvement, innovation and collaboration.
  • Active management involvement in all aspects of enablement.
  • The right level of leadership and governance -- making sure that investments are relevant to the needs of the market.

Unfortunately, change is not easy and can create significant discomfort within an organization. Change is inevitable, by definition, in a dynamic marketplace, and those who refuse to adapt will get left behind. As General Eric Shinseki, U.S. Army Chief of Staff, once put it: "If you don't like change, you're going to like irrelevance even less."

The reality is that people and organizations who embrace the idea of continuous improvement and being able to adapt to changes in this new global economy are going to be the leaders.


References

  • Stephen M.R. Covey, The Speed of Trust, Free Press: 2006.
  • Stephen R. Covey, The 8th Habit: From Effectiveness to Greatness, Free Press: 2006.
  • Stephen R. Covey, Principle Centered Leadership, Free Press: 1992.
  • Thomas L. Friedman, The World is Flat: A Brief History of the Twenty-first Century, Picador: 2007.
  • Etienne Wenger, Richard McDermott, William M. Synder, Cultivating Communities of Practice, Harvard Business School Press: 2002.
  • Don Tapscott, Anthony D. Williams, Wikinomics: How Mass Collaboration Changes Everything, Penguin Group: 2008.
  • Etienne Wenger, "Communities of Practice: A brief introduction." Whitepaper at http://www.ewenger.com/theory/

Acknowledgments

Thanks to our colleagues who reviewed and provided helpful input to this paper:

Robin Bater, David Bellagio, Bob Bogan, Tim Bohn, Giuseppe Calavaro, Celso Gonzalez, Andreas Gschwind, Michael Hartmann, Stephen Hunt, Saif Islam, Scott Kirven, Bret Kramer, Per Kroll, Peter Luckey, Mary Ellen McElroy, Patrick Mancini, Roque Martin, Mark Meinschein, Yukiko Nishiyami, Bob Noble, Bill Norris, Roger Nutt, Peggy Pechan, Mike Perrow, Tom Pietrcollo, Luis Quintela, Greg Rader, Walker Royce, Rick Slade, David Thompson, Kei Tonomura, Alfred Tse, Michelle Ulrich, Rick Weaver, Judy Wells, and Matthew Wilde.

Resources

  • A new forum has been created specifically for Rational Edge articles, so now you can share your thoughts about this or other articles in the current issue or our archives. Read what your colleagues the world over have to say, generate your own discussion, or join discussions in progress. Begin by clicking HERE.
  • Global Rational User Group Community

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Rational software on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Rational
ArticleID=351893
ArticleTitle=The Rational approach to technical enablement
publish-date=11122008