In many organizations, moving into management means moving away from hands-on work.
The software engineering field highlights this dichotomy acutely: Engineers intimately familiar with code must focus on putting others in a position to succeed. At runZero, though, every engineering leader is also an individual contributor enjoined to wade into the code and get their hands dirty.
“I like to describe my role as ‘director of engineering, runZero-style,’ because this reflects our company’s roll-up-your-sleeves attitude that empowers leaders to remain hands-on contributors,” Dan Kaslovsky, director of engineering, said. “I have a leading role in shaping and growing our engineering organization, but I’m also a technical contributor who writes code that is shipped to our customers every day.”
Kaslovsky’s responsibilities include ensuring overall engineering execution and delivery, recruiting and hiring, managing direct reports and guiding technical direction — all while owning hands-on engineering work.
“The combination is fulfilling because I enjoy leadership and am also an engineer at heart.” Kaslovsky said. “This sense of ownership is part of what makes working here such an engaging opportunity.”
What runZero does
runZero is a network discovery and asset inventory solution that helps organizations find and identify managed and unmanaged assets connected to their networks and in the cloud.
runZero is currently at a stage in its growth where Kaslovsky and the team that once launched the company’s flagship product are now leading in the effort to overhaul its code as the company scales. It’s a process that he describes as at once a testament to the success of the team’s initial implementations, “a clear sign of healthy growth” and an “exercise in humility” as the team continues to improve, refine and rewrite code.
Read on to learn more about runZero, its engineering team and the ways in which the company is servicing its clients, keeping it simple and generating excitement as the organization grows.
What role did you play in developing and launching runZero’s network visibility and asset inventory solution?
As part of the initial engineering team, I got to be a part of a small team writing a lot of code to launch new parts of the product. It’s amazing just how much we’ve added to the product in a relatively short amount of time.
Fast forwarding to today, a lot of that code is now in the process of being rewritten as the team and product mature. In my experience, reaching the point where initial implementations are being replaced is a clear sign of healthy growth — although it is an exercise in humility to watch as your hard work is refactored into something far better.
Our technology choices are exciting because they are, in a word, boring — and intentionally so. Keeping our tools and tech choices simple enables us to work, innovate and deliver quickly.
Our backend is written entirely in Go and interfaces with a PostgreSQL database. This means that the entire application can be compiled to a single binary for any platform. We get a lot of mileage out of this. For example, this makes it possible to run the entire SaaS product on vanilla cloud virtual machines, support a self-hosted offering and test our product on a byte-for-byte replica of what our customers use, all without any extra overhead. The only additional requirement is PostgreSQL, which is open source, freely available and an industry standard relational database. Our backend developers find this type of engineering simplicity to be a force multiplier.
Things do get a little more exciting on the frontend where we’ve fully embraced Vue.js as our JavaScript framework. We consistently hear feedback from both our engineers and applicants that this choice of modern framework is a compelling aspect of our stack. Digging a bit deeper, it is usually the simplicity that Vue.js allows that excites engineers. So it is fair to say that for runZero engineering, keeping it simple means keeping it exciting.
What obstacles did you encounter as you developed and scaled runZero? How have you successfully overcome these obstacles and kept team members motivated and aligned?
The biggest obstacle that we face is adapting to change as we grow. Things that worked when we were a team of five or a company of 10 no longer work today — and certainly won’t work in the future. We are constantly needing to reinvent ourselves, our processes and how we develop our code. This has a way of sneaking up on you. Change is difficult, and it is hard to account for the time it takes to adapt.
We stay motivated and aligned by being honest with ourselves. We call out when something is no longer working. We are willing to try something new. And we stick to a firm motto: “If this isn’t working for us, let’s throw it out and do something different.” The trust we build when we are willing to admit that a new idea for, say, how we track work-in-progress, just isn’t panning out goes a long way towards our team cohesion and mutual respect.
“We are constantly needing to reinvent ourselves, our processes and how we develop our code.”
What teams did you collaborate with in order to develop runZero? What strategies did you employ to ensure that cross-functional collaboration went smoothly?
When I first started, we were small enough that cross-functional collaboration didn’t require strategy. If I needed input from the content “team,” I could just DM them, since it was just one person. Same for the product team. Coordinating across teams was easy — all it took was a simple @here in the #company channel for an informal chat. Today that would be poor form.
As fun as those days were, we are too big for that to be a productive model. Part of building this company has been working with others to build our strategies for cross-functional engagement and alignment. The strategies I use are still very much a work-in-progress and likely always will be. I am fortunate enough to have gracious, generous people as colleagues and counterparts, and we work together to figure out how to improve and grow. In times when this has been more difficult than we would have liked, I have found the best way to move forward is through conversations that build empathy for the daily experiences of those on other teams. This alone has directly led to improvements such as our team’s Kanban board, a backlog grooming process with cross-department input and a much more engaging company-wide demo for each release.
When you think of other companies in your industry, how does runZero compare when it comes to how you build and launch new product features?
What stands out to me about runZero is the same thing that initially put the company on my radar and made me want to be a part of it. Our product provides a foundational capability in the ecosystem of security products. We discover and collect ground truth data about a network and its assets. The idea that we are building a product that people trust to be a source-of-truth guides how we think about, build and launch new aspects of runZero by placing a premium on getting this data — sometimes in raw form — in front of the user.
As you might imagine, when collecting data from any environment into which we are deployed — whether scanning the entire public address space of a country or the network of a large corporation — it’s often the Wild West. I really like the approach we take; first and foremost we get the information into our system and accessible to the user because that is what our customers rely on us to do. Once it is in the system, we can always clean it up, make it more searchable and build new use cases on top of it. But we think about getting it into the system first because we place a premium on providing a source of truth.
This differs from other products I’ve been a part of building where collecting the data was step one or a prerequisite in order to then begin building the algorithms and analytics that would become product features. Here, collecting the data is the product.
Another unique aspect of how we work is that our entire engineering team is also the support team. We all round-robin customer support tickets so that engineers are communicating directly with customers every day. This means that we are continually learning about what our users want the product to do, what pain points they experience and why they love runZero. More than once I’ve fielded a bug report from a customer, found the issue, and shipped the fix live within the hour. It is incredibly rewarding to then hear back from that customer that they are blown away at how quickly we responded, thanking us for our time and effort and telling us that this is one of the reasons they love working with us. I haven’t had another engineering role where you get this type of unfiltered feedback directly from the people for whom we are building the product.
What’s different about the runZero workplace?
Despite being — or maybe because we are — a 100 percent remote company, runZero is one of the most positive environments I’ve been a part of. I like to say that our positivity comes “baked in,” but this is doing us a disservice because while it seems to come naturally for us, we all work hard to keep it that way.
It makes me proud that we do the little things. We have a Slack channel for saying good morning to each other. We take the time to call out our colleagues for a job well done — because the small things add up to something bigger. Listening to myself say this, I feel like I’m talking in clichés, but it’s all true. The positivity was easy when we were a company of fewer than 10, but to myself and others, it still feels this way today now that we are approaching 100 people. This is something that I am incredibly proud of and grateful for and is one of our defining characteristics.
