This article is a reflection of my observations from DevOps Days DC 2018 (June 6-7), which observations seemed to be a manifestation of a repeated pattern and a theme, rather than a fluke.
This was my first time attending a DevOps Days and my immediate impression was that the conference was a lot different from all others I have attended before. It had that cool, less-curated (i.e. less-manipulated), grassroots-driven, ears-to-the-ground vibe. There were more T-shirts than ties, very limited and time-boxed vendor pitches, talks based on real experiences with lots of candid stories of failures and success. The best part of the conference was the Open Spaces segment – self-organized discussion circles on topics raised and facilitated by the conference attendees. Most of the topics were naturally very technical – “Experience with Serverless”, “Microservice Best Practices”, “The Future of DevOps”, “Test Automation Best Practices”. There were a few contrarians, as well, wanting to talk about – “Monoliths, No Microservices”. But what surprised me the most was the healthy number of non-technical topics such as “DevOps and Raising Kids”, “Continuous Learning”, “Hiring and Retention of DevOps Staff”, “Diversity in DevOps”, “Remote Teams”. It was even more surprising that the respective sessions were really well attended by engineering and management folks alike, commercial and government representatives, and the discussions were very vigorous and passionate.
This experience reinforced the notion that DevOps is defined just as much by organizational culture and people behaviors, as it is defined by the new technologies and techniques.
Regretfully, at the big-vendor conferences, we hear mostly about the technologies and the nuts and bolts of DevOps. We hear a little about the organizational changes and new processes, but we hardly hear about the People of DevOps. At present, I would argue that the People aspect is the most crucial aspect of a successful and sustainable DevOps transformation.
The technologies had significantly matured. There is a significant body of knowledge in forms of books, articles, blogs, and training classes on DevOps best practices. The know-how of DevOps had been largely commoditized, however, the demand for the skillset still significantly outweighs the supply of qualified engineers. Organizations, and especially government contractors (rapid staffing of large programs, lower-than-commercial rates), are facing great challenges in acquiring and retaining skilled personnel. The problem is multiplied by the velocity of change and knowledge turnover.
People are having a hard time keeping up with the avalanche of new tools and technologies to learn. Organizations are having a hard time finding and retaining enough qualified personnel.
No one has the silver bullet, but here are a few practical considerations, especially for organizations without the High-Tech Unicorn brand-name hiring pull:
Hire For the Growth Potential, Not for the Current Skills
Experience and good foundations do matter! However, with the current rate of knowledge turnover, I’d rather hire a smart, curious, self-driven Junior engineer than someone who had been writing the same Java applications for the past 10 years.
See my other blog post on harnessing the potential of the Millennial Generation.
Create a Continuous Learning Pipeline
Akin to CI/CD pipelines pushing new features from code commit to production, managers and organizations need to, can and should create pipelines for training their staff. It is more cost-effective for organizations to invest time and effort in training existing and loyal staff than hiring from the market and losing to the market within a year. Learning Management is one of the most critical functions of a manager in an Agile/DevOps organization – identifying the strategic new skillsets for the organization and creating the environment and incentives for their acquisition. The team can take care of the rest.
Learn on a Kanban
Old CMMI-style Training Management Plans are just as useless as the old-school Project Management Plans and Business Requirements Documents. A Learning Plan can be as simple, transparent and effective as a Kanban board with a card for every book, training class, seminar, conference or training dojo planned for each team member (I keep a backlog of books or anything requiring more than 1 hr of reading/research on my personal Kanban in Asana). Good organizations set aside training budgets and monitor the actuals to stay under budget. Better organizations track training and certification completion and ensure the training budgets are maxed out the most efficient way.
Embrace MicroLearning
Again, doing as we preach – while we strive to reduce the batch size of our product deliverables, we should also reduce the batch size and ensure the continuous flow of our learning. Old-school, 3-day, classroom classes are no longer needed nor they should be encouraged or accepted by managers. Such classes are expensive, removed from context, and ineffective. After 3-day-long brain crunch learning something new, one doesn’t remember what they had for breakfast, let alone what they learned in Chapter 1 three days ago. I find a lot more effective the new style of low-production-cost, micro-video-stile training. It is a lot easier to commit 15 minutes here and there than full 3 days. Content is current because it is so easy and quick to produce. And the subscriptions are dirt-cheap. The caveat is that one should have the discipline to stay on track and keep taking the video classes. This can be easily visualized and tracked on the Kanban board above.
Yearly Performance Reviews
… are a big pet peeve of mine. They didn’t really work in the past, but they are even more antiquated now. On one hand, my team and I are working on 2-week sprint objectives and driving toward daily deployments, but on the other hand, my reports and I need to come up with yearly goals, and assess them at the end of the year?! That’s too long of a period in the IT time & space continuum. A talented DevOps engineer can change jobs twice (with 10-20% salary increase every time) before it is time for the next Year-End review and promotion conversation. There is a huge disconnect and HR consultants and organizations need to seriously reconsider this process and embrace Lean!
Promote Team Players as Opposed to Individual Star Performers
This is another reason why the typical performance reviews don’t work – they single out and reward the overachievers on the team, as opposed to promoting the teamwork and collaboration so essential for DevOps. There will always be people who try harder and work smarter, and we as managers should, absolutely, reward them! However, as additional performance objectives for everyone (regardless of seniority) are implemented, we should have metrics for knowledge sharing, experimentation, new ideas, learning, and acquisition of new skills.
Groom Generalists as Opposed to Specialists
Agile has been preaching for a long time having “teams of multi-functional generalists”. I have never seen a person who is equally diligent and detail-oriented for business analysis work, as skilled in coding, and patient for testing. People naturally gravitate toward a particular skillset, with which comes the superficial label – “BA”, “Developer”, or “Tester”. This is even more challenging in DevOps where people who used to know hardware, operating systems, subnets and reverse proxies, now need to know code (beyond the shell scripting) and vice versa. The learning curve is a lot steeper. One of the best ways for a Manager to work around it is to periodically rotate team members and change their roles and responsibilities (Referring you back to the Continuous Learning Pipeline section above). It builds both knowledge and empathy. A developer carrying a pager for 1 month will write a lot better code afterward, and an Ops engineer reviewing a pull request will have a lot better understanding of the next deployment impact in production.
In conclusion, it may sound counter-intuitive and controversial, but as the technology evolves in complexity and pace of change, people and talent management (continuous learning, career growth, soft skills, team dynamics), not the technical skills, will become the most important traits of the new Leader of DevOps.
Bella Trenkova