I'm the Engineering Manager for the Cloud Innovation team at Temenos, where I manage seven senior DevOps engineers. As our company is getting into more cloud providers, we decided to get into Kubernetes so that we can run our solutions across all clouds and save money.
We decided that rather than going to market, we would train everyone internally to up-skill employees, give them job satisfaction and retain them. This initiative was more successful than I thought. Therefore, I would like to share my journey with other managers and tech leads wanting to start a similar process.
The overall plan was to get everyone through the Certified Kubernetes Administrator (CKA). We first set out to do the Introduction to Kubernetes first, as this was the prerequisite for the Kubernetes certification, and a great starter to get into study mode. After my team was skilled up, we would then teach other teams what we had learned.
After we finished the Introduction to Kubernetes course, we found that Kubernetes wasn't as scary as we thought, and we started using it straight away for our Internal DevOps toolset. We had our Jenkins server sitting inside AWS ECS, running Docker, so we decided to put that setup into Kubernetes as a fun project.
Already, we found that we were reducing "new tech debt" as we developed solutions that we wouldn't have to change in two months. Employees could increase code throughput and get more projects to market faster, with increased employee satisfaction.
Here are some tips to make your Kubernetes upskilling journey successful:
Have weekly one-on-ones with your team.
Complete the journey as a team.
Lead by example.
Get executive buy in.
Get your company to pay for the training.
Reach out to the DevOps community for help.
Setup weekly discussion sessions.
Get a real Kubernetes project to work on.
A weekly one-on-one is the most powerful tool you can invest in for this journey. It only costs 30 minutes of your time, with each direct per week. We follow a manager framework called Manager Tools, which has many great podcasts on how to provide effective one-on-ones. Each week, I set a milestone for the engineer to achieve by the next week, and then follow up on it for the next one-on-one and give positive feedback. I found that with two engineers, I needed to set smaller milestones for them to achieve. Otherwise, they would context switch and not meet the deadline of the training.
It is important that the journey is done as a team. I found half the team could finish the first course fast, and the rest was a lot slower. The first people to finish were the tech leads and senior engineers. So, as we waited for the rest of the engineers to finish, I focused on upskilling the ones that finished early on their soft skills, particularly on coaching and mentoring, and then they helped coach the others to get them over the line. This was more successful than I thought, and it completely changed the team's collaboration and performance.
It is important that you lead by example and also do the training yourself. Pushing yourself to complete the training milestones first will help push the others to focus on finishing. This also helped a lot initially to get everyone started.
An important part of this journey is to get executive buy-in. Changing the company culture can be hard, so it's important to do your research and present why you want to use Kubernetes. After you start the journey, it's all about making the work visible. Executives like reports, so it's important to show savings in costs and employee satisfaction. This will help you train other teams and roll out Kubernetes in our next step.
One other key thing to do is get approval to pay for the training. At the start of the training, I hadn't yet asked for the funding, and I soon realized without this, not everyone was going to pay out of their own pocket. If there were some people who didn't want to pay, then we wouldn’t achieve our goal of finishing as a team.
Many companies won't pay for contractors. So, if they are not willing to pay for the course themselves, you have to bring it up as a performance requirement in their one-on-ones. Generally, this won't be a problem for contractors, since they make a lot of money.
The great thing about being in DevOps is the community. As I started reaching out to my network regarding my journey, everyone was excited to help, from our partners helping with training sessions, and advocates that I have met in conferences connecting me to the right people for advice. One of them actually inspired me to write this blog post.
This is important. You need a real-life example, because you can only do so much theory and labs. This will give true training.
In summary, this journey was not as hard as I thought, and doing it as a team brought us closer together. It made our team culture even better than what it was. We are now excited to go out and teach other teams.