Scaling Good Practices across the Enterprise

If your enterprise is undertaking a transformation, then you will need to help your employees develop new skills. That makes sense—your employees are probably very good at doing whatever you have done in the past, and transformation, by definition, is something new. You could bring in new employees who already have the new skills, but there are a few problems with such an approach. First, your current employees already understand your business and your company’s culture and influence structure. In the transformed world, that is arguably the most important set of skills. I say that because what we are all transforming to is an IT organization that is responsive to the needs of the business and works alongside business stakeholders to deliver value. Second, it is also expensive and time-consuming to hire and onboard a lot of new people, and, anyway, everyone else is probably trying to hire the same people. So let’s get real and figure out how we’re going to transform with our current set of employees.

A great way to start is by training your current employees in the new skills they need to help make the transformation successful. AWS Training and Certification offers a variety of courses, including some free digital courses that can be used to begin bringing employees up to speed. As I discussed in an earlier post, it’s a good idea to spread training broadly across your enterprise as this helps deepen adoption and increase the value that can be obtained from working in the cloud. AWS Events & Webinars are primarily learning events, so AWS re:Invent, AWS Global Summits, AWSome Days, and so on are all good ways to further develop employees’ skills. You can—and should—take advantage of the Solutions Architect assigned to your account, and if you are an Enterprise Support customer, your Technical Account Manager (TAM) as well. And AWS Professional Services and our AWS Partner Network (APN) partners can also help get you going.

But once you have built up a small core of expertise within your enterprise, how can you scale it? Perhaps you have created a Cloud Center of Excellence (CCOE) with good cloud skills, or maybe you have some people with DevOps skills—automated testing, deployment scripting, infrastructure provisioning, continuous integration. Now, how do you leverage those skills to build enterprise-wide competency?

Every enterprise is different, but there is a set of related techniques that we have seen work well. They’re experiential rather than classroom-based, and they all involve pairing people who have the skills with people who want to develop the skills. This constant exposure to good practices not only teaches the critical skills, but also gives the learner exposure to people who consider it perfectly normal to work in the new paradigm—in other words, these techniques help with cultural change as well.

The first model is a fairly straightforward pairing model, similar to the approach used by Pivotal Labs in their consulting engagements—in fact, that is how I learned of it, as one of their clients when I was at USCIS. The concept can be used within an enterprise as well as when working with a contractor like Pivotal. In this approach, a team that wants to learn the skills pairs with a team that already has the skills. The joint team works together on an actual project. Within the teams, they pair one-to-one, using a pair programming approach, with each member of the learning team partnering with a member of the expert team. Pair programming is a common tactic in the Extreme Programming community and elsewhere in the Agile world. It is a very effective way to accomplish work, as well as to transfer skills. At first, it might seem to cut productivity in half, but teams that practice pair programming find it actually increases productivity. There winds up being much less rework from fixing bugs, and the ideas contributed by the two practitioners result in cleaner design. This is not so surprising, given that peer code reviews are a very effective way of ensuring high-quality code [1], and pair programming is sort of like a continuous peer review.

A second tactic is the Dojo approach developed by Target. In this variant on the pairing model there is a Center of Excellence, or Dojo, that takes on one team at a time from various parts of the enterprise to help them improve their practices. They might do pair programming exercises, as in the basic pairing model, but the Dojo may also train the team on the latest tools available, help them solve problems they are facing, or present new ideas and methodologies. Their “30-Day Challenge” offering for teams, like the basic pairing model, pairs Dojo experts with other teams to work on a project, but in order to maximize learning, sprints are shortened to two days. “This intense pace helps teams quickly organize, break down the work, realize success and build muscle memory so they can take their new skills with them when the challenge is over,” according to Target. The Dojo concept is explained more fully on Target’s website.

A third approach is the mitosis technique. Once a single team has developed a deep set of skills, it is split in half, and each half joins up with some less expert practitioners to form a new team. This way one team becomes two, with half of each team starting with expert skills and spreading them to their new teammates. My colleague Jonathan Allen talks about how he used this technique when he was at Capital One in detail here http://amzn.to/2uPrGzR.

A final variation is the—ahem—“promiscuous pairing” technique that I learned of from Arlo Belshee. Here the focus is less on teams and more on individuals. It is also based on pair programming. Each person pairs with another for a period and then switches partners. They keep doing so, becoming exposed to new ideas and working methods with each partner they take on. Belshee used this technique to overcome a problem of scale—how could he make sure good ideas made their way across a huge development organization? Through promiscuous programming, good ideas became “memes” that spread virally. “In general,” according to Belshee, “the most useful information gets passed in every pairing, and nearly all information is passed in a matter of a few pairings. Most of this information is passed in the first hour of a pairing. As such, the primary limit on the rate of transmission is the number of different people that each person pairs with each day.” [2]

What all of these techniques have in common is that they are organic—not a central effort to push ideas down through a hierarchy by writing policy, but rather a way for skilled practitioners to spread their knowledge. This is important, because centrally controlled learning will run into problems of scale. They’re also hands-on learning techniques. And—importantly—they let the people with skills feel good about their abilities and proud to be spreading them—and perhaps vested in the success of the people they teach.

I have used the simple pairing approach in my previous role, and I have heard success stories from people who have used the other techniques. I think these ideas for spreading skills are one piece of a comprehensive strategy for enterprises to scale transformational skills. It is also important to introduce new ideas that can then be spread through techniques such as these. That can be accomplished through external trainings, like those offered by AWS Training and Certification; by bringing in contractors with new skill sets and learning from them; by hiring people with new skills; by attending conferences; and…well, probably lots more ways. Please let me know if you have more ideas to share!

–Mark
@schwartz_cio
A Seat at the Table: IT Leadership in the Age of Agility
The Art of Business Value

[1] Karl E. Wiegers, “Seven Truths About Peer Reviews,” Cutter IT Journal (July 2002), http://www.processimpact.com/articles/seven_truths.html.

[2] Arlo Belshee, “Promiscuous Pairing and Beginner’s Mind: Embrace Inexperience,” Proceeding of the Agile Development Conference (July 2005), pp. 125–131, http://csis.pace.edu/~grossman/dcs/XR4-PromiscuousPairing.pdf.