Women in DevOps: Laura Frank
Women in DevOps: Laura Frank
In this interview, Laura Frank, Director of Engineering at CloudBees, shares her experience in DevOps leadership and her most important values.
Join the DZone community and get the full member experience.Join For Free
The need for DevOps innovation has never been greater. Get the results from over 100 business value assessments in this whitepaper, Digital Darwinism: Driving Digital Transformation, to see the positive impact of DevOps first hand.
In our Women in DevOps blog series, you'll hear from talented women in DevOps. They will share their experiences in DevOps, their thoughts on leadership, lessons learned and also how we can encourage more women to focus on an IT career. This post is about Laura Frank.
As the Director of Engineering at CloudBees and a Docker Captain, Laura has a deep knowledge of developer tools. She has worked on Codeship, a SaaS CI/CD platform designed to streamline testing and deployment of code, since 2015. Before Codeship, she co-maintained several open source projects to support Docker in the early stages of the project, including Panamax and ImageLayers, and came to work on developer tools and open source by way of OpenStack and HP's public cloud offering. She is a member of the Moby Project's Technical Steering Committee and frequent international speaker. She currently lives in Vienna.Hi Laura! What traits are important for being successful in DevOps?
Perspective and persistence, regardless of whether you're enabling DevOps practices for your own company, or writing tools for other engineers to use (or both!).
Working in the DevOps world is really rewarding as an engineer, since you have the opportunity to find solutions to problems that you and your team also face when writing your own software. It's a bit easy to get sucked into the 1s and 0s and kind of lose sight of the problem that you're solving, because the tech can be so interesting. It's important to keep a good perspective and be aware of problems other than your own. What are the needs of the teams that might use your tool, or how will this process impact the team you're consulting with? Are you solving their problem in the best way, or just a novel way? How can other people benefit from your work? Building a feature for a product is rewarding because the consumer of that product will be delighted by it, but I'd argue that enabling DevOps practices in teams is equally as profound and delightful. You have the power to modify people's days, their work, and ultimately how quickly they can be rewarded by their own successes.
Persistence is important because there's no single day you're going to wake up and think "Aw yeah, I am doing all the DevOps and there is no more work to do!" DevOps is a mindset and a methodology, not just one tool. It's a horizon that you're always aiming for, but you'll never get there. That sounds a bit grim, but it's the truth. The world changes around you, and DevOps practices are continuously evolving. "Continuous Improvement" as a practice is just as important as continuous integration and continuous delivery. By all means, set milestones and make sure your goals are measurable. But don't expect to ever be "done."If you could have given your younger self some advice for the future, what would you tell her?
"Don't worry, this Docker thing is going to turn out just fine!" In all seriousness though, I'm a very calculated risk taker, and Docker was a big bet. As I mentioned before, I think one of the challenges of working in a fast-evolving world like DevOps is that there always seems to be a new tool or new solution. It's hard to know what to pay attention to. A lot of times we confuse new tools with new problems, when in fact that problem is well-solved in other ways. Docker was really different though; it was powerful and revolutionized the way teams build and ship software in a profoundly different way than previous solutions.
One other piece of advice I'd offer is that working on new things - tools or practices that are still in the "genesis" or "innovate" phase - is really hard. These things exist in a problem space that doesn't have a great solution, and expect that you're going to be running your brain at 110% a lot of the time. Many things you'll do are going to result in a dead end. When I worked on a R&D team at CenturyLink Labs, we were creating developer tools for Docker long before it was anything other than an image builder and container runtime. We were guinea pigs in a lot of ways, really pushing the boundaries or expected use cases for a lot of features. It was really rewarding to document our investigation via tooling or blog posts to help other developers and teams benefit from the work we were doing.What set you on the DevOps career path?
I've been working on developer tools since early 2012, when I joined HP Cloud, back when there was a public cloud offering based on OpenStack. The idea of DevOps certainly existed then, but it didn't have as much traction, and the principles certainly weren't very visible at a large enterprise like HP. However, our team was able to function very autonomously, and we saw the value in adopting DevOps best practices from the start. We were committed to automated testing and CI, and we gradually automated our release process and got into a more frequent cadence for releasing software (once or twice per week vs. once a month). That team from HP went on to do some pretty cool stuff once we parted from the team; Matt Butcher went to Deis and eventually worked on tools like Helm and Brigade, and another handful of engineering (plus me!) moved over to an R&D team at CenturyLink Labs to work on this new whale tool called Docker, which was new and novel and no one quite understood what it could be used for. We joined up with some engineers coming from Pivotal, and worked on developer tools like Panamax and ImageLayers to make it easier to work with Docker. Since then, I've been firmly planted in the Docker world, getting very involved in the project and eventually being one of the first people to be appointed a Docker Captain. Though my work at Codeship, I'm often thinking about the ways that technologies like containerization and orchestration can help teams be more productive, and develop and ship their software more frequently, and with more confidence. Now that we've joined up with CloudBees, it's interesting to get a glimpse into some of the DevOps problems that larger, more traditional companies are facing, and help come up with a strategy to help them on their DevOps journey.What do you look for in a great company/boss/mentor?
I like working with people who are direct, accountable, and focus on getting things right - not being right. But those attitudes also have to be visible at all tiers of the company, from the CEO to individual contributors.What are some lessons you have learned on your DevOps career journey?
Don't get caught by the shininess or novelty of a new tool. Think critically about the problem it's solving, and whether or not it's truly a problem for you. Better yet, avoid picking a solution before you thoroughly evaluate your problem. I call that "solutioneering" and it can get you into some unfavorable situations with a lot of tech debt and even more bloat in your processes.
Published at DZone with permission of Hannah Inman , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.