It’s Not a Release, It’s a Lifecycle

It’s an old mantra in tech: You either have the right technology or you don’t get anywhere. But is the premise that having the best technology equals success really valid?

Today we know there is more to it. You could build the best technology in the world, but if you haven’t helped people understand how to apply the new concepts and capabilities to their problems, you just have a widget that nobody can use—and no way to know if it’s really even working.

The real job of building a successful product happens when we invest equally in developing that product and in the people who will use it in their environments. As technology evolves, it’s important that vendors actively invest in teaching, mentoring and enabling people—ahead of products—with the foundational skills required to leverage new technology.

By doing this we help create a better, more informed user base that can apply their experience and context. And in turn, that newly informed user base forms a symbiotic relationship with us as a vendor, helping to guide how we develop products and solutions from a position of mature, informed authority.

In this environment the bar for success is no longer releasing a new product. It’s continually engaging and listening to all of the product constituents—customers, partners, F5 engineers, support staff—in a constant lifecycle of innovation and improvement.

Employing DevOps methodologies for training

You can see how this works by looking into the history the Super-NetOps program. As part of F5’s transformation to a multi-cloud application services company, we had to train hundreds of engineers around the world with a new set of foundational skills in cloud, automation, orchestration and DevOps methodologies.

In doing so, we worked hard to build a symbiotic relationship with our own engineers. The cycle looked like this: Develop training content. Test the content with a few users. Determine where the user experience needed improvement. Build that into our product. Repeat.

In bringing a product to market with customers, you can correlate that same DevOps and Agile methodology with this: You build a thing, and now you have a prototype. You need to get feedback, but you’re not going to get feedback until you find people willing to put in the time and effort. And to do that, they need training. They need documentation. They need handholding to get through it.

So, in conjunction with our development efforts, we’re building out the mechanisms for how we train. And part of that is building in the feedback loop—both on the training and on the products themselves. How do we make it so that people using these prototypes can contribute back in an open source manner? How can we learn from that point where a customer gets stuck in an implementation? And how do we leverage those learnings to make our products and support even better?

For the past few years, we have been getting our customers and the community involved, and those efforts have led to today’s Super-NetOps, building from the program's go-live at Agility two years ago.

This was a fundamental change for our NetOps-centric engineers. We’re not just building automation and orchestration solutions, we’re actually aligning to the methodology around DevOps and the software process. We’re designing as if it were a giant distributed software project that happens to run on and integrate with the F5 platform, not network stuff that is shimmed into what looks like a software system.

Creating partnerships

All of this is equal parts embracing and engaging with DevOps, but it’s also about creating partnerships. Now we have the pieces in place to have a new conversation with customers. We’re listening carefully and having an active, constructive debate that is totally predicated on how to get the customer to their most successful outcome. Sometimes that’s by us saying yes we’ll go develop a feature. Sometimes that’s by us saying we recommend that you don’t go down this path.

It also gives us the tools to help NetOps become a true partner with DevOps. They don’t have to be that person who just gets projects that were lobbed over the wall. They can be a partner—the one who can help DevOps and developer teams succeed and make their application, their thing, their creation, sing. If that person doesn’t already exist in your company, in two weeks we can get them there.

Going through this process and making these shifts have fundamentally changed the way that F5 looks at who we’re going to be. We now understand how to go engage with the bleeding edge, with the way container ecosystems are built, the way microservices are built, the way software is developed in the modern age.

And as you’ll see with our release of the Automation Toolchain APIs this month, it’s a philosophy that’s really making a difference in our products too—one lifecycle at a time.