Why I joined RunX? — The issue with hiring DevOps teams

Recently, I started a new job at RunX, a startup which provides tools to automate cloud infrastructure. I thought it would be an interesting post to write about my motivations and why I decided to join this team.

1. What are my motivations?
2. What is the main issue with the DevOps market?
3. Use Lego blocks vs do-it-yourself
4. Why do I believe RunX has a bright future?

What are my motivations?

Every engineer would have their own criteria when evaluating the fit with a potential employer.

Here is my list:

• Leadership
• Engineering team
• Company mission
• Company culture
• Interest & Impact of the work
• Growth opportunities
• Work flexibility
• Total compensation

The importance of each one will depend where you are in your career and what are your goals.

One common mistake is to not understand the interdependencies. For example, a great leadership team will attract talent and this will result in interesting work and deliver a great impact. This would eventually lead to growth opportunities and higher compensation.

It is also not uncommon for DevOps engineers to have some relevant experience in one specific area which becomes their differential skill. They end up taking on similar challenges over and over, but at higher scale each time:

• They have solved it for X, now they are looking to solve it again for 2X or 10X.

In my case, I have worked on various projects to improve Developer Productivity for hundreds of engineers, and my new personal goal is to have an impact for thousands of engineers.

What is the main issue with the DevOps market?

On one side, you have some DevOps engineers that have really specific aspirations and on the other side there are many companies in various stages that are competing for these engineers. To stress it even further, the cloud computing market is growing rapidly and the pandemic has only accelerated the trend.

What nobody will tell you is that having each company to build their own DevOps engineering team is not scalable. There are just not enough engineers.

Get Remy DeWolf’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

To make the problem worse, some small or medium sized companies might not be able to attract these DevOps engineers for various reasons.

• Engineering team: They might not have a DevOps team yet, or their existing team is subject to attrition. It makes joining their team a challenge.
• Interest / Impact of the work, Solve it again for 2X or 10X: Due to their size, they might not appeal to these engineers that want to experience the next level.
• Total remuneration: It could be hard to compete with Tier 1 startup or FAANG.

You could consider becoming the first DevOps engineer at a new startup, but unless it comes with a plan to grow the team quickly, it might create new issues.

• There are many specialities involved in Cloud Computing: Networking, Security, Scalability, Storage, Big Data… Even the smartest individual will have to make some choices on where to spend their time, and expose the business to some risks.
• For the business itself, the dependency on one single individual might become a risk, especially if the plan is to target a multi-million dollar market.

So to recap, we have:

• High competition to hire DevOps engineers.
• The cloud computing market growing very rapidly.
• Some risks associated with having a small DevOps engineering team.

Use Lego blocks vs do-it-yourself

Instead of having each company building their own DevOps team to solve similar problems, RunX’s goal is to synthesize years of expertise in DevOps teams and package it as a service. RunX has already open sourced Opta, an Infrastructure-As-Code framework which provides high-level constructs to manage cloud infrastructure.

Think of it as a Lego block pattern. A business can configure their cloud infrastructure to their needs, without having to mold each block and wonder if they would fit together.

Being a DevOps engineer, I have experienced the complexity of working in the DevOps space. I wanted to answer the question: Would I use Opta if I would start my own business?

• Option 1: Do not use Opta: I am confident that I could maintain a Kubernetes cluster, configure it following best practices and scale it to a certain level. But I am not as confident with Networking and Security. Having worked in bigger companies, there are already some existing teams that would set the network stack for us and maintain it. Because these areas are critical, they can’t be ignored. I would need to spend a lot of time to figure this out. I will create some tech debt, make some errors and learn from them. Also my experience is mostly with AWS, if I would have to use a different cloud provider, there will be a learning curve.

Pros: Learn a lot.

Cons: Slow rollout, expose the business to new risks, create some tech debt.

• Option 2, Use Opta: By selecting the modules I need, I can get a quick head start to setup my cloud infrastructure. It comes with best practices, such as proper networking configuration and is Infrastructure as Code (IaC). I don’t need to become an expert in each area. I have more time to focus on the technical challenges that are unique for the business. The first time I tried Opta it took me 15 min to have a VPC with a functional Kubernetes cluster and 5 min to deploy my first app (see Opta documentation). Just recruiting a DevOps engineer would take months, and probably a few weeks worth of work to have a similar infrastructure.

Pros: Fast rollout, follow best practices.

Cons: Use a new tool (Opta), which can be seen as a risk.

The advantages are evident, but I would also need to address the part that Opta is a new tool and here are my findings:

• Opta can output Terraform code, the leading tool for Infrastructure-As-Code.
• Opta is fully open source: the code, the tests, the documentation, the contributors can be seen on Github.

Why do I believe RunX has a bright future?

At this point, I am convinced that the companies using RunX will greatly benefit from it. But coming back to my original list, how does working there would align with my motivations?

• Leadership & Engineering team: I am lucky enough to have worked with some members of the RunX team before. I have seen their leadership and engineering skills in action and the huge impact that they have.
• Company Mission/Culture/Growth opportunities: RunX is hyper focused on their mission and their customers. The engineers have a lot of autonomy and work on things that they enjoy. The culture promotes inclusiveness over intolerance. With these values, we, engineers, can unlock our full potential and grow with the company.
• Interest / Impact of the work: In a traditional DevOps role, the impact is internal. You build a new tool or fix a bug for the in-house engineering team. But at RunX, we provide open source tools, every new feature or bug fix is available to the community. As RunX will grow, so will the community of users. It will reach a point where it would just make sense to use RunX for managing your cloud infrastructure. That’s how impactful this will be. This aligns well with my personal goal of improving Developer Productivity for thousands of engineers.

There are many more reasons why RunX is a company to watch for in this space. If you are curious about joining or want to learn about our values, check the careers page. If you want to try it yourself, have a look at Opta, the Infrastructure-As-Code framework.