In my About Me I mentioned that I made the transition into DevOps and that I considered myself to have come into the field from a “non-traditional” path. I thought that perhaps I should explore this a little more and discuss what I mean by non-traditional, what implications this had, how I finally made the transition, and what I learned along the way.
TL:DR
- Be inquisitive
- Develop technical excellence
- Dig deep to understand the underlying systems and operations
- Be self motivated to investigate tools and solutions yourself
- Work on your human skills
- Tell people what you want to be doing
- Own your journey, invest in yourself
Background
A little about my working background first. I started off in retail in the auto industry, selling car parts. During that time I decided that I wanted something more for myself and that IT felt like the right place for me. Initially I thought I should get into Development, so I took out a loan and bought myself a course on C#.NET. The salesman who sold me the course gave me a piece of advice that was probably just to make an extra sale but actually was one of the best single pieces of advice I’ve had; “before you learn how to code, learn about the platform you’ll be coding for”, and with that he sold me a Microsoft Desktop Support Technician (DST) course as well! I think this advice sums up my approach to my career ever since; no matter what you are doing, understand the supporting infrastructure and systems too.
After I completed the DST course, I found a job as a junior IT Support Technician at a school. Here I got to experience not just Windows desktops but servers, networks, and telephony too. I enjoyed it so much that I actually never completed the C# course! Instead I completed a whole range of certifications on Windows Server instead. I also got to design, implement and maintain server, network, and telephony systems. This eventually lead to an opportunity in Technical Support. My time in Support opened my eyes to a wide range of new experiences, such as my first real exposure to Linux, and the value of including Support and through them the customer in product development discussions . It also gave me the opportunity to rise to become a leader within my teams and take the voice of the customer experience on to become a leading voice within the wider company. Through taking the lead I was able to learn skills outside of just plain tech; I learnt leadership, communication, influencing and persuasion and how to work with all levels of the company from juniors engineers, to the executive and sideways to partner teams from Professional Services, Sales and whole lot more. So, another top tip, build your human skills as well as your technical ones.
Where did DevOps come in?
The obvious question comes; from this pathway how did I even get to know about DevOps, let alone find my way into it?
While I never did finish that C# course solving customer issues while in support brought me to dabbling with PowerShell to scrape logs and automate actions. I even ended up writing some PowerShell scripts to be packaged in one of our products! I wouldn’t call myself a real Dev or code jockey but I could do a few bits when I needed to, given enough time. A role change during my time in support exposed me to Linux by giving me responsibility for a Red Hat (RHEL) based appliance that we sold. Having never worked with Linux before I needed to learn a lot, and very quickly! So I turned to YouTube and started searching for Linux content. I focused initially on basics with a skew towards system administration and soon found a great video series, The Linux Basics Course: Beginner to Sysadmin, Step by Step by someone called tutorialinux, real name Dave Cohen. It proved to be a great introduction to Linux and I really engaged with Dave’s style. The more I watched, the more I picked up clues from his videos about this thing called DevOps, and from there my inquisitiveness kicked in and I started to research more. The more I read, the more I felt like it was an interesting field in which I could find a place. In addition to YouTube I also started following the community on Twitter.
I could sum up a lot of this stage as be inquisitive; find a thread that interests you and keep pulling. Linux led to containers, led to kubernetes; knowing Cloud was important led to investigating Azure, and then AWS. Similarly my support roles time again came back to server performance and so performance led to monitoring, and knowing what could be monitored then drove me mad that so many customers didn’t automate response actions. As I said, keep pulling that thread and see where it takes you; don’t accept the quick answer, dig deeper and become the expert.
Preparing for the change
Here is where I should recognise the gatekeeping that much of the industry can have at times, “you don’t have experience in X technology, so how can you do this job”. It’s as if nobody ever learns anything; but it is considered safe to hire the individual who has touched it before, even if the inexperienced candidate may bring more to the table over a longer term. As someone driven to keep learning and developing and who strives to develop their career and not stagnate this can be really frustrating; “I have a track record of learning new things and then taking them to a new level, maybe let me try your thing?” Also, I had reached a senior level in the support world and so had to consider a likely need to step down a few levels to make a change. If you’re making a career change this is something that you need to be aware might happen. How did I combat this gatekeeping and make the move? A two-pronged approach…
The first can be described as technical excellence; both in the current toolset of my actual job but also in exploring and learning about the tools of the field I was heading for. What do I mean by this? I built a reputation for myself of knowing the technologies I was supporting and the tools I used to support them inside out. Over the years I found novel ways to solve problems with the products which others missed but were based on nothing more than a deep understanding of how the product worked and how various components interact together. Don’t just settle for the easy route and the quick solution, understand how and why. Added to this experimentation with new tools; I researched new tools, or using existing tools in new ways during quiet moments in the day/week and also during some of my free time. This helped me to see new solutions and also to keep building thar reputation for innovating and technical strength, while also solving immediate problems. Finally, I took the time to learn about the new tools I needed to know. For DevOps this is Cloud (AWS, Azure, etc.), Infrastructure as Code (IaC) tools (I looked mostly at Terraform), Ansible for configuration management, and tools for monitoring such as Prometheus, and Grafana for monitoring. I invested the time to build a lab environment on some old kit I had available and it was a great place to experiment and learn. It also further enhanced my ability to talk about these tools and cement my reputation for technical excellence. My advice would be look at your current role and see if any tools might apply; Ansible might be a perfect fit if you work as an IT Admin, knowing monitoring tools can help as a Support engineer perhaps. As I built my skills I could be more confident when talking to the teams who used those tools regularly. In some discussions I could be a technical authority and provide ideas and guidance, however mostly it simply allowed me to speak on a level with those teams and by extension show that I understood what they did (and therefore what I wanted to do eventually). It all gave a solid baseline of knowledge and paints a picture of someone self motivated enough to go out and find out.
The second part of the approach is to work on your human skills and interactions with the teams around you. I can’t recommend this enough for anyone working in tech, but if you want to change lanes at a senior level, it’s vital. Without these skills I’d either still be in Support or would have taken a significant step down to make the change. By having these skill I was able to sell myself sufficiently well that what I did bring to the team outweighed my areas of weakness such that I was fortunate to move over at a similar level. Don’t underestimate the value of human interactions even in a technology world. It’s not all about sales, it’s about being able to build relationships such that the teams around you trust you. There’s little benefit in being technically excellent if you are not able to engage with people; especially if you want them to help sponsor a change of role. I built skills in simple talking with people (particularly of a higher level to myself), empathy, presentation skills (I did a lot of presentations), persuasion and influencing (I used to think I struggled to persuade those senior to me a lot), and knowing when to push for what you want vs. conceding some ground. I was in a role where I both needed assistance from development teams but also development teams required my Support teams to undertake work for them. By learning how to balance the give and take it really helped to build trust and partnership. Also, I would recommend understanding how Development and DevOps work flows and project planning works. Understanding tools such as Jira or Azure DevOps and what Scrums, Sprints and Retrospectives are can help a lot in putting yourself on the same level of a discussion, it helped me a lot.
I would strongly recommend looking at, and investing in courses while you’re preparing for a change like this and do look at courses for the human as well as technical skills. The technical skills are “easier” to find and secure courses for if you like; a simple subscription to sites like Pluralsight or individual courses from Udemy are easy to come by. Courses don’t always need to cost, for example Microsoft Learn has a huge wealth of material available for free. I’ve used all 3 of these sources myself and I recommend them without any benefit to me (other than the skills I have gained of course!). They can even cover some of the human type skills, particularly around understanding project planning and Development/DevOps planning tools. The true human skills like presentation or persuasive skills can be harder to find. I’ve been fortunate to have a previous manager who was willing to sponsor in person courses for me. I suggest do some of your own research here.
Making the change
OK! I’ve decided that I want to try my hand at DevOps and I’ve been preparing; so how did I make the change?
Well like many things, hedging my bets and exploring a few angles was my approach here. Doing so helped me understand what different organisations wanted and where my strengths and weaknesses really lay. Side note here; it’s easy to judge ourselves and assume that the world judges us the same way. it’s easy but it’s wrong! Often areas I thought I couldn’t possible be strong enough in my knowledge of I was actually able to talk through in sufficient details to impress and pass that point of discussions, other areas would catch me out instead.
I updated my profile and made myself available for work on LinkedIn. I emphasised as much as possible, possibly even over sold my knowledge on areas which made sense for DevOps roles, all of which was to try and get some interest from recruiters. This worked and led to some interesting conversations. I tend to not oversell my experience during discussions and be open and honest with what I know, what I’ve done and what I expect; I find this builds a degree of trust during any exploratory call or interview.
I also told people around me what I wanted to do and where I saw myself. By telling my manager and other colleagues that I was interested in DevOps they were actually able to help start some conversations and secure me time with the DevOps manager and other engineering leadership. My time spent building the trust and expertise I spoke about earlier helped to get that time too; my manager may have helped suggest a conversation but without being known and trusted for being a good operator in my current role and for being a good partner to the engineering teams I don’t think discussions would have been more than quick and cursory. Instead my time investing in my reputation in my current role meant I was given time to sell what I had learnt and what I could bring to the DevOps team even if I lacked the standard experience. Telling people what I wanted gave them the opportunity to see how I might fit or tell me where I needed to focus. It can be scary to tell people, particularly at work, that you want a change but think of it and communicate it as “I want to grow and do X” not “I want a change and don’t want to do Y”.
Eventually, the DevOps team at Vocera decided that they valued what I brought to the table as a senior engineer in terms of my communication, leadership, knowledge and proven track record to learn more. They had a possibility for a role and decided to accept my application for it. And so, here I am today.
What I learned
- You’ll notice that the background and preparation is much longer than how I made the change, this isn’t by accident. Putting the work in upfront in terms of improving your skills and your standing in the community takes time but can pay back significantly more when the time comes
- You have to enjoy what you do and what you want to. The journey can take time, you need to enjoy it if you are going to stick at it. While I am glad I made the move I know I had found several more years of worth of work to do and projects to contribute to that I would have continued to enjoy my old roles as well.
- If you want to make a change, for whatever reason, own the change. You need to make the investment in you, nobody is going to just open the door without a good reason why
If this article helped inspire you please consider sharing this article with your friends and colleagues, or let me know via LinkedIn or X / Twitter. If you have any ideas for further content you might like to see please let me know too.
