This article is part two of a series. Read part one.
There are three pillars I consider critical to building a successful DevOps culture, which I spoke about in my presentation at cdCon earlier this year. In this article (the second of three), I will be discussing the second pillar — enabling a continuous learning culture.
Why is continuous learning important?
If you are a technology-enabled business, you know technology changes quickly. Taking advantage of its quick evolution is critical to building amazing products and accessing new innovations to ensure you remain competitive in your existing or new lines of business.
Where do you start when laying the first foundational stones to this key capability? How do you know you are being successful? — let’s deep dive into these two areas.
Let’s start with some context…
Learning can take on many forms. For this article, I’ll focus on continuous skills learning, a critical component in any learning-based culture and paramount to ensure your delivery teams keep pace with innovations in the technical capabilities you can leverage to increase your value velocity.
The guiding principles
Before executing on any strategy, I like to establish guiding principles, which act as sign posts and help empower teams to execute independently while remaining aligned to the overall mission, this is critical if you want to amplify success and foster autonomy across a large organization.
Examples of guiding principles are:
- Multi-channel experience
- Focus on hands-on learning
- Goal driven
Guiding principles define how you will implement your strategy — the guardrails for its execution. Let us step through these examples ‘one by one’ to understand them more:
Learning is a very personal experience. There is no “one size fits all.” Enabling different ways to consume and practice the application of new knowledge is another important area to consider. For example, ensuring your engineers can work independently, in small or large groups, gives a variety of options which can be leveraged at different times — each giving a different experience.
- Mix self-paced individual learning with small and large group learning.
- Ensure a variety of learning engagements, like book clubs, interest groups or technology showcases to provide a variety of learning channels to share tacit knowledge and enable a community-based culture.
- Survey your engineers on how they want to learn and continually assess feedback on your channels. Don’t be afraid to pivot as your learning culture matures.
Instructor-led and self-paced courses are an awesome way of getting started on a topic or practice. As software engineering is a craft, it is important to apply these skills to reinforce the learning, get feedback and improve the base skills. Therefore, deliberate practice needs to be a cornerstone of any learning strategy.
Three activities I have seen drive successful outcomes for hands-on learning are:
- Coding kata’s: This is an exercise where you repeat a practice many, many times, making little improvements in each iteration. Some examples — learning test-driven development, effective testing, etc.
- The dojo: A group of people get together to work on a programming challenge. Keep the dojo’s short — a single day works well. Its fast pace and focused outcome keeps a high level of engagement throughout the day.
- The coding retreat: A multi-day intensive practice event, focusing on the fundamentals of software development and design. Each event has clear objective, with engineers split into several different groups, constantly playing back their work to get feedback and spread ideas on a single goal.
A key tenet to driving your continuous learning culture is to ensure all learning is purpose driven, connecting the outcome of the learning to objectives within your organization.
Aligning learning goals to your organizational objectives provides a clear understanding to how these skills will benefit both your engineers and your organization’s outcomes. This is a really powerful narrative that directly links the value of learning to the success of your business.
- Keep learning goals scoped to short periods of time. I like to have a journey map for an extended period, but keep the goals timeboxed to a quarter or two — progress is a great motivator.
- Relentlessly communicate why key skills are important to your business and how it benefits your engineering teams. This emphasizes the ‘why,’ ensuring a sense of purpose for the learning goals.
- Use milestones to promote discussion with engineers on how they are doing, enabling a check point to pivot based on any changing priorities.
Now that we have our principles which help guide us on how we will implement our strategy — it’s time to switch gears and create the areas of focus for our learning. These areas of focus help drive the type of skills and learning we want to achieve. Organizing your learning into different themes provides a clear understanding of why they are important and the outcome you want to achieve in the particular space. I like to think of learning across four key areas, each area addressing a key need of mastery of the craft of software engineering, which provide the bedrock for our continuous learning culture.
Let us walk through each one.
This focus area is the foundation stone we build our excellence upon. Regardless of where you work in an organization as an engineer there are common skills that are shared across even the broadest of contexts — for example, how to effectively test your application or service, how to construct it optimally, code agility, etc. Although these may seem basic, the practices underneath make your code exceptional and should not be overlooked, they form the bedrock for your organizations product quality, scalability and resiliency.
This area focuses on skills and knowledge needed to excel in the context you work in. If you work on a platform team or a mobile application team, your skills will vary. These skills build on your core competencies and focus on the key skills that you need to master to write awesome software in your chosen domain. Focus on skills which are unique to your area of work — for example, if are you a Kubernetes platform team, you will need deep knowledge of the internals of Kubernetes, understanding how to write extensions, etc.
This pillar breaks away from common skills to skills aligned with the engineer’s personal goals. Everyone has different aspirations and career goals and it’s paramount to support these opportunities in a flexible way and knit these objectives into the overall goals for your engineers. Again, journey maps are a great way to articulate the path, give focus but build in agility to pivot as priorities change.
Use 1:1 time to discuss progress and any changes needed to the journey — engage but not micromanage the process — empower the engineering team to have accountability over their career path while relentlessly supporting them.
The best ideas and solutions to complex challenges often come from a source you did not expect, and as our world of software grows more complex, broadening our skills outside our context of work can bring critical new ideas and thinking into our problem space. Supporting your engineer’s personal interests outside their day to day skills brings the outside in — contributing to a culture of experimentation and connecting engineering communities, all important aspects to accelerating critical innovation.
As a leader, enabling a culture driven by curiosity, experimentation and continual learning ensures your engineers thrive in an amazing work environment, build exceptional experiences for your customers and remove silos that inhibit high velocity of value — all key outcomes for any transformation which DevOps is at the heart of.
Till next time.