vasabii - Fotolia

It's not only OK to steal DevOps ideas, it's encouraged!

DevOps requires a different way of thinking, organizing and communicating. Nowhere was that more clear than DevOpsDays Boston, where DevOps ideas burst from every session.

It's good when employees steal, at least according to Simon Wardley and his Pioneers, Settlers and Town Planners model. No, Wardley doesn't advocate raiding the office supply closet; he encourages organizational theft -- specifically, new processes and ideas.

In his DevOpsDays Boston keynote, "Settlers of DevOps," Rob Cummings, solution principal at Slalom Consulting, applied Wardley's thoughts to large and complex organizations, outlining how they can establish a "pull culture," free from mandates that might stymie DevOps ideas and innovation.

"I want to deliver customer value faster and more humanely," he remarked. "When we talk about faster, that's code for peak value, or cycle times, or make more money, or do more good. And then humanely: Don't burn people out while you're doing that. … How do you combine all of that to do better?"

Bimodal IT is one way. But it's split into modes: one is process-heavy and rigid, incentivized to focus inward on stability and not outward at customer need, and one is wholly separate trying out cool DevOps ideas and DevOps tools, but still limited by the former mode's inflexibility. 

Settling on DevOps

The problem: Bimodal IT is too simple for complex systems and large organizations. Complex systems require inputs, outputs and feedback loops, while bimodal IT restricts flow between the modes, resulting in stagnation.

"In summary, bimodal is an overly simplistic way to organize," Cummings continued.

And that's where the thieving comes in.

Better than bimodal

Rob CummingsRob Cummings

Wardley breaks individuals into three roles: Pioneers, Settlers and Town Planners.

Pioneers bring new ideas into an organization. They don't mind failing and often "live outside standards," Cummings explained. "Maybe think of this as shadow IT." They are driven by gut, not guided by metrics.

Settlers selectively improve upon the Pioneers' work where it makes the most sense and build trust through the organization. They adopt ideas but customize to make them their own, while focusing on continuous improvement.

If what the Town Planners are building isn't being used, they are not building the right thing and they need to re-examine that.
Rob Cummingssolution principal, Slalom Consulting

Town Planners focus on scale and creating commodities. They are driven by metrics and operational efficiency, and they build the services Pioneers rely on for future experimentation.

"It's a theft-based pull model. Nowhere in this model are things being pushed or mandated. In all cases, it's being pulled," Cummings told the crowd.

Each role steals ideas to make them their own, with reuse serving as feedback. According to Cummings, "If what the Town Planners are building isn't being used, they are not building the right thing and they need to re-examine that."

Finding unicorns

Pioneers, Settlers and Town Planners all bring valuable DevOps ideas and are all equally important to an enterprise or team. Each role requires excellent people with different skill sets. Perhaps unicorns, as described by Franklin Mosley, principal application security engineer at Ellucian, in his DevOpsDays Boston presentation "How To Make A Unicorn: Finding Cybersecurity Talent In The Real World."

What's a unicorn? Mosley claims a unicorn:

  • Does what needs to be done
  • Has true grit
  • Knows his own value
  • Thinks big and small
  • Isn't limited by job title

Wardley would also like them to steal. And while Mosley specifically addressed cybersecurity talent, his advice looking outside traditional tech backgrounds for self-learners willing to mentor, while offering training, is applicable to any shop looking for DevOps engineers with DevOps ideas.

Context and knowledge

For Pioneers, Settlers, Town Planners and Unicorns all to flourish, it requires a nourishing company culture and communication structure -- two ever-present themes at DevOpsDays Boston and something Yulan Lin, software engineer at Valador Inc., touched on in her day two keynote, "The Curse Of 'Common Knowledge': Communicating For Clarity And Inclusivity."

"What does good communication look like? What does working with people well look like?" she asked.

According to Lin, four broad elements affect clear and inclusive communication:

  1. Curse of knowledge: Particularly, insider acronyms, jargon and processes. It's really hard to remember what it was like before you knew something.
  2. Code switching: Jumping between contexts and recognizing "my context" might not be the same as "your context." The same word can have different meanings depending on the context.
  3. Culture and norms: Understanding your shared contexts, which are not immediately apparent to outsiders.
  4. Power dynamics: What does it look like for people of power to create a shared context?

In regards to culture, Lin asked, "What are things you find cultural or normative for your particular organization or team that are in some ways unique?"

Going back to Wardley's Pioneers, Settlers and Town Planners, it's easy to see where cultural norms come into play. What kind of organization encourages thieving and pulling, but frowns upon pushing?

Here, Lin's advice for those with the curse of common knowledge rings particularly true. "Context is huge; questions are huge; both how we ask and answer them, as is trying to be precise in our communication, because we understand context."

Dig Deeper on DevOps Team Organization