Almost any company you ask will say they want to empower their employees. But what does employee empowerment actually look like for technical teams and how does it affect everyone within the company?
To find out, we spoke with Michael Gruen, the VP of Engineering / CISO at Cybrary.
Mike is responsible for software development, data science, infrastructure, IT, and security at Cybrary. Along with his technical expertise, Mike has extensive experience in managing, having built and managed multiple engineering teams. It was evident in speaking with him that he actively thinks about how to be a better manager.
We asked Mike how he sets his team up for success with so much on his plate.
What is Cybrary?
Cybrary is a workforce and career development platform, focused on cybersecurity and IT professionals, with over 2.5 million users around the world.
Enterprises use Cybrary to identify and address skill gaps on their teams by providing access to hands-on learning and training activities. Teams also use the platform to on-board, upskill, and provide career development guidance to team members. Individuals use the same tools to assess and improve their own knowledge, skills, and abilities as well as receive career guidance from a community of professionals and mentors.
What is the engineering culture at Cybrary?
At my previous job, we were building enterprise software that needed to work in a multitude of environments. For regulatory compliance reasons, it couldn’t be multi-tenant so we had to have a separate deployment for each customer, even the ones we were managing.
When I came to Cybrary, I was excited to have one platform I was responsible for supporting.
Agile methodology has its uses, but I prefer feature-driven development or Continuous Delivery. The whole idea is that we want to get a feature into production as soon as possible. If there is something that needs to be supported or changed, we can do it right away.
It may create problems as the team grows because there is a point where there are conflicts as to how many deployments we can reasonably do in a day and how much time they’ll take. But right now, we’re not anywhere near that problem. Plus, other companies have solved that problem as they’ve grown. We’d rather get an idea out there than have a bunch of features stacked on each other resulting in a problem such as: “these five features have a dependency on these three, and these three aren’t ready to go because we found some bugs.”
This way, it’s easier to get a feature out and support it. The engineers that worked on that feature immediately move to a support role when it’s in production. While they plan the next feature, they monitor how things are going and if a bug is found, they hop on it right away. They fix it, get a patch out, and then get back to the next set of features.
What’s the biggest downfall of the Continuous Delivery method?
If you push out something that’s not working, it can have some big impacts.
In the early days, if we made a change and it prevented a form from being filled out, it might not have mattered. But now we have a whole sales staff. If that form isn’t filled out, they’re sitting there twiddling their thumbs because they’re not getting the leads they need.
Teams always test before they deploy, but risk increases as you increase the speed of deployment. I think that risk is offset because the people who deployed it are then on high alert to monitor and fix things. We’re also able to move faster because testing is less complex and isolated to much smaller changes than traditional major/minor releases.
How do you make sure things get done on time?
We define the problem and then immediately start working on it. We don’t spend a lot of time estimating or having meetings to make sure everyone on the team understands every particular feature.
There are some benefits to that method like identifying and clarifying any misalignment. However, our methodology values speed over predictability.
Every company has to make that decision for itself.
We might someday have to revisit that as we get larger. There are certainly times when there are features or work that needs to get done and an accurately estimated delivery date is important or expected. In those cases, we take a little more time to make an estimation of when that delivery will be. But, for the most part, we skip over all that and get to work.
You’ve said that you think it’s important to empower engineers. Why do you think that’s so important?
Enabling engineers and Continuous Delivery goes hand in hand. It’s not very efficient to have Continuous Delivery with a product-heavy, top-down approach.
Enabling engineers is about defining the problem we’re trying to solve and why we’re trying to solve it. What is the user trying to achieve?
Once engineers are armed with that information and understand the general strategies for how we solve problems for our users, then leadership doesn’t have to get into the weeds about how everything gets implemented. Product Managers can be looser with the requirements and acceptance criteria and focus more on upcoming work. The right engineering team with the right information can make a lot of decisions on the fly.
That’s real empowerment.
Engineers are the ones making the decisions. They’re the ones that have to maintain the code once it goes live. Empowerment requires having a good pulse on users to make good decisions. It means the developer takes ownership – not just of the feature, but the entire platform and company.
My role is not to dictate what gets done. My role is to approve.
Engineers might make the wrong decision, or sometimes have the wrong information, but at least a decision was made. It was pushed out the door and we can iterate quickly to fix it.
A book that has inspired me in this area is “Turn the Ship Around” by L. David Marquet. It’s about a submarine captain who takes the worst performing submarine in the United States Naval Fleet and turns it around to be the highest performing sub in the fleet. He does this through his own methods of empowerment. The book really reinforced and helped me understand why these empowerment principles are effective.
The other thing I learned from the book is that you want to avoid creating a cult of personality that comes from a top-down approach. Even if you have a great VP of Engineering or CTO making those decisions, you’ll find everything falls apart when that person leaves. No one else was in that position or made those types of decisions.
As the VP of Engineering at my previous company, I wanted to transition into a product role. I brought in another VP and the handoff went smoothly because the engineering team had been empowered to make decisions and take ownership of their work. They were able to keep going while the new VP got up to speed. After I left the company, everything continued to go smoothly. And because the developers owned parts of the product roadmap, onboarding new Product Managers was easier, as well.
Want to learn more about Cybrary? Check out their company page to learn about their company culture, product, and more!
