This post opens a series where we chat to people at Octopus about their role, their challenges, what they're working on to improve the product for our customers, and more.
First up is Michael Richardson, our original product management leader, now Director of Product.
How long have you been at Octopus and what experience did you bring?
After following Paul's journey, I joined Octopus as a software engineer in 2015 - wow, time goes by fast. I came with a decade’s experience building software and leading development teams across many industries in organizations of all shapes and sizes. And similar to many of my colleagues at Octopus, I often happily claimed the responsibility for setting up the build and deployment pipelines for these projects.
Foreshadowing my future at Octopus, I had the opportunity to see and help define the various ways all these organizations released and deployed software, with varying degrees of success. This lets me easily empathize with our customers' challenges and gave me an intuition for the type of problems Octopus could help with.
What are your responsibilities as Director of Product?
I wear the product hat in the leadership team of our Deploy Group. Our mission is to have Octopus deploying as many applications as possible by evolving its capabilities, expanding the technologies we integrate with, and making it as easy as possible to use.
My role is to set the product direction for the group. I’m always hunting for the next set of problems we could solve for our customers, and I work closely with the engineers, designers, and other product managers, to ensure we solve the problems we bet on.
What does a typical day look like for you?
A big part of a typical day is gathering information - analyzing data, reading customer feedback, listening to what other teams in Octopus are seeing, talking to customers, and following industry news. I also regularly use Octopus and other tools to model various scenarios.
On a typical day, I’m likely to meet with one or more of our development teams, where I probably just ask, “Can we ship it?”.
Oh, and Zoom meetings. So many Zoom meetings.
What are the biggest challenges for the Product team at Octopus?
The biggest challenge is always that there are too many things we want to do! When the company was 10 people, we said, “If only we had 20 people, we could do everything!”. When we grew to 50 people, we said, “If only we had 100 people, we could do everything!”. Well, we’re at nearly 200 at the time of writing, and we’re nowhere close to being able to do everything we would love to.
Choosing the right problems to solve, and keeping a balance between maintaining high levels of reliability, refining and evolving the existing features, and building the next big thing, is always a challenge.
What are you working on to improve the product for our customers?
Well… [takes deep breath]
The biggest evolution of the product we’re building at the moment is Config as Code. I’m sure you’ve heard us talk about this many times by now, but Config as Code allows Octopus projects to be version-controlled in Git repositories. It's been a huge engineering effort to lay the plumbing for this feature, with deployment processes version-controlled in the initial release. But we’re just getting started, so stay tuned for version-controlled variables, runbooks, and more.
Another significant evolution, one that’s in a much earlier stage of development, is support for dynamic environments: creating and destroying test environments on-demand. The way many development teams want to work today is not to have long-lived test environments. Rather, they want to create new environments on-demand, for example, an environment for each pull request, and to destroy them the moment they’re no longer required.
We’re also exploring how we can make Octopus a perfect fit for cloud-based teams. This means looking at how teams deploy to serverless platforms and use container images as deployment artifacts.
We’re constantly adding to the range of products Octopus integrates with, and ServiceNow is a notable example that we're currently developing a built-in integration for. ITSM tools are common in larger organizations, and yet we’ve never built a first-party integration with one, so this is a different shape of integration for us.
And if there’s something you think we should be looking at, please reach out and tell us!
How do you measure success internally and for our customers?
Every company is now a software company. Being able to deploy more frequently and more reliably creates a positive feedback loop that can produce huge differences between the best teams and the rest.
Success is helping our customers use this feedback loop to deliver value for their customers. That sounds corny, but it’s true.
Personally, I’m passionate about the technology and practices involved in getting code from developer workstations through to running in production. Being able to play a part in shaping the industry's future and seeing it used by all these incredible companies around the world is rewarding, to say the least.
As just one example of how this has played out, 10 years ago it felt like as an industry we were still battling to convince people of the benefits of automating deployments. In 2022, it feels like that mission has largely been accomplished, and the conversation is much more nuanced now. I like to think Octopus played a part in this.
I’m proud that Octopus is an Australian company. Its growth, across many measures, has been incredible, and I think has stayed true to Paul’s original vision and values. I’d call that success.
