Bringing down the silos in an enterprise can be a challenge. It requires grit along with a solid understanding of organization change management and group dynamics.
I had the privilege of supporting two teams this past year, one that was an operations team learning development practices, and a development team that was discovering operations while introducing continuous delivery. Both approached Chef from different viewpoints, but in the end were united by this common tool set.
This talk will cover what I wish I had known a year ago about leading change (with specific examples), including:
- The ups and downs your team will experience.
- Who to put on your full stack team.
- Why empowering teams is hard.
- Where to focus the adoption of new ideas.
- How to make those ideas stick.
2. Agenda
• Why CD/DevOps?
• Enterprise scale
change is hard
• One way Nordstrom
is driving change
• Lessons learned
3. • Rob Cummings - @opsrob
• Worked for Bose, EMC, Accenture, and
Nordstrom in operations roles over the past
16 years.
• Today – Program Manager, Infrastructure
Engineering, Nordstrom
About Me
4. Why take the roller coaster ride?
DevOps and CD in the enterprise.
5.
6.
7. Changing an enterprise is hard.
And that is ok, it is supposed to be.
(an exercise in empathy)
15. “Innovation may very well signify the
future, but the performance engine is
the proven foundation, and if it
crumbles, there is no future.”
–pg 13, “The Other Side of Innovation”
18. Innovators
2.5%
Early Adopters
13.5%
Early Majority
34%
Late Majority
34%
Laggards
16%
The
Chasm
Rogers Innovation Adoption Curve
http://en.wikipedia.org/wiki/Diffusion_of_innovations
http://en.wikipedia.org/wiki/Technology_adoption_lifecycle
19. Innovators
2.5%
Early Adopters
13.5%
Early Majority
34%
Late Majority
34%
Laggards
16%
The
Chasm
Adopters
Time
Rogers Innovation Adoption Curve
http://en.wikipedia.org/wiki/Diffusion_of_innovations
http://en.wikipedia.org/wiki/Technology_adoption_lifecycle
20. …57 years later
http://www.forbes.com/sites/margiewarrell/2014/03/25/culture-of-courage/
“With the latest Gallup figures categorizing over half of
the workforce as disengaged, and nearly one in five
workers as “actively disengaged,” organizations need
leaders who not only engage employees, but moves
them to think more daringly, to take smarter risks, and to
challenge the very assumptions that may have
underpinned their success to date.” – Forbes, 3/25/2014
33. People's tendency to place an undue
emphasis on internal characteristics to explain
someone else's behavior in a given
situation, rather than considering external
factors.
http://en.wikipedia.org/wiki/Fundamental_attribution_error
Fundamental Attribution Error
35. • Large organizations have been trained to resist large, rapid change.
• Focus on early adopters at the beginning, even if this is not the
highest business value.
• Build full stack teams for rapid change.
• Empowering teams will take significant leadership work.
• There will be rough times in your awesome project, brace for it
ahead of time.
• Watch for bias, especially the Fundamental Attribution Error when
times are rough.
Summary
Spruce goose; largest wingspan of any airplane; 5 stories tall; wood.Howard Hughes answer to the needs of transporting troops and material during World War II. Design started in 1942, one flight in 1947. Highly disruptive technology was taking hold… jet engines. The plane was obsolete before it was finished.
Our answer to this is Continuous Delivery, which almost requires DevOps mindset to be successful.
Imagine your organization as a performance engine. Mandate for predictable performance.Will optimize via incremental change.Change can be disruptive, which goes against the performance engine mandate for repeatable and predictable results. Afraid of mistakes that come from large change. Those past mistakes work against them adopting your major change out of simple risk avoidance, even if they acknowledge it could be a good change. Lets take the Ford Mustang, as an example product of a Performance Engine that was good at incremental change and even took on a bigger change and see what happened:
Your organization is a performance engine, tuned to get the results you are getting today. It has process to ensure everything stays on the rails…and yeah, sometimes those rails have been there a long time.
Still pretty good looking. But now we are coming up on a significant event, the gas crisis. Rapid, significant change and innovation is required.Performance engine steps up to the plate, takes a deep breadth, and comes up with this:
Lets just say this is not my favorite Mustang.Performance engines have a long memory, they remember the pain of bad changes, and they remember how long it took to recover from them. It is only natural to resist anything that might lead back to 1974. Wouldn’t you? So, keep in mind two things when you are proposing your change...They have in the back of their mind the last time the org tried to make a major change that was less than successful. They aren’t willing to bet the Performance Engine on your experiment, and that is ok.
The adoption curve is based on work done in 1957,Joe Bohlen, George Beal and Everett Rogers at Iowa State University Their original purpose was to track the purchase patterns of hybrid seed corn by farmers.
The report summarized the categories as:innovators – had larger farms, were more educated, more prosperous and more risk-orientedearly adopters – younger, more educated, tended to be community leaders, less prosperousearly majority – more conservative but open to new ideas, active in community and influence to neighborslate majority – older, less educated, fairly conservative and less socially activelaggards – very conservative, had small farms and capital, oldest and least educated
http://en.wikipedia.org/wiki/Diffusion_of_innovationshttp://en.wikipedia.org/wiki/Technology_adoption_lifecycleThe report summarized the categories as:innovators – had larger farms, were more educated, more prosperous and more risk-orientedearly adopters – younger, more educated, tended to be community leaders, less prosperousearly majority – more conservative but open to new ideas, active in community and influence to neighborslate majority – older, less educated, fairly conservative and less socially activelaggards – very conservative, had small farms and capital, oldest and least educated
http://en.wikipedia.org/wiki/Diffusion_of_innovationshttp://en.wikipedia.org/wiki/Technology_adoption_lifecycleThe report summarized the categories as:innovators – had larger farms, were more educated, more prosperous and more risk-orientedearly adopters – younger, more educated, tended to be community leaders, less prosperousearly majority – more conservative but open to new ideas, active in community and influence to neighborslate majority – older, less educated, fairly conservative and less socially activelaggards – very conservative, had small farms and capital, oldest and least educated
Full stack teams make sense for moving very fast and proving out innovation. Put everything you need together, operations, development, testing, security, privacy, business. Infrastructure Engineering, Continuous Delivery Teams (which got absorbed into our growing Infrastructure Engineering organization)How do you gather a full stack team of early adopters?You can’t hire a team of change agents. Easier, better to first look within. Don’t be afraid of bringing on the outspoken, the grumpy. They are being grumpy, they are being outspoken, because they have ideas that they can’t act on. Give them space to act on those ideas and whatch what happens.Keep in mind, this requires a lot of engagement with leadership. Empowering is hard, you can’t just throw the team together, and expect them to act differently. This brings us to the goats.
To go fast you need empowered teams that have clear expectations. Command and control might get you going faster in the beginning, but will slow you down in the long run through bottlenecks and limited creativity.We realized this and wanted to fully empower the teams to do what they needed to do, to break rules and ignore guidelines, if necessary. It turns out, just telling people they are empowered doesn’t work out real well. I am going to use our friend the goat to help describe this problem. If you have seen Michael Ducy’s Goat and Silos talk, pieces of this will sound familiar. I learned the goats and fences lesson via Ben Grossman Kahn, who leads our people lab at Nordstrom.http://www.flickr.com/photos/noii/3093367803/
Goats are curious. If you put them in a fence, they will explore the entire fence looking for an opening.
When they find that opening, they exploit it, and suddenly you have goats all over the place. The goats are working on everything but the problem you needed them to solve.
Make the fence too big, and too secure, you run into a similar problem. The goats are spread out, still looking for a loophole, still
Specific example: Jenkins vs. Go discussion.Assume Chef, assume Git, pick a CI/CD tool (this is up a developers alley).
Specific example: Our CD team was getting really frustrated with Chef at the beginning. And they were vocal. They were developers with .NET background where everything is fully documented, fully understood. They had zero operations experience. Created a bit of a rift with the teams already successfully using Chef. We entered the stink.Pushed through by focusing on only the next task, and then the next, and without realizing, they gradually found themselves relying more and more on Chef to solve their problems. They came around, and started working much better with our other teams using Chef, and we have a stronger organization for it.