Behind the Software Q&A with Plutora Co-Founders
Within the relatively new discipline of release management, teams rely on intricate platforms and complicated procedures to coordinate software releases. Australian startup Plutora is revolutionizing the industry by shifting the focus to end-to-end release management obligations and customer needs. In our Q&A with Plutora, we spoke with Directors Sean Hamawi and Dalibor Siroky — who co-founded the company in February of 2012 — about their relocation to the US and commitment to bringing simplicity and transparency to the now-complex space.
What void did you see in the market space that Plutora aims to address? How would you describe the company’s key goals or philosophy?
LOCATION: Sydney, Australia
Dalibor Siroky: Sean and I have been working together for about six or seven years, and we had worked in a number of financial institutions. During that time we found that the space in release management wasn’t being addressed — different institutions across all industries were having the same problems. We made the decision to focus on that spot, so we left our jobs and started working at building a product [which would become the Plutora platform].
With Plutora, we aim to make release management simple and transparent. The challenge is that in today’s marketplace release management is becoming more and more complex, with more interdependent systems involved. Companies are struggling to manage that process, and we recognized that and tried to return to simplicity and transparency with what we think is a very responsive and customer service–focused platform.
How does Plutora’s product differ from other release and deployment management applications?
Sean Hamawi: I think there are two key items that really make us different from our competitors. The first is that the solution we provide looks at the problem space of release management from end to end, meaning it looks at everything from the planning stage all the way through to the pilot states. Plutora takes the complexity of release management and allows you to manage it in a really simplistic way. With a number of our competitors, you need several different products working together to get the same outcome.
The second area we focus on is in the nonproduction environment management space: managing test environments in the context of what it means to deliver a release. That space has been completely neglected by the incumbent players. Our effort to address that space is part of the reason why we’ve had a lot of interest in our solution; there is no current solution that does that.
Are there any features that your company designed to address users’ release management needs differently than your competitors’ platforms?
DS: We wanted to ensure that our release management product lifted above the engineering layer. We see a lot of competitors that do automation and application lifecycle management, and we wanted our platform to extend a layer above that, because we see release management as being a very orchestrated and engaging process. When we built Plutora, we made sure that the stakeholders’ engagement and the usability were at the forefront. Plutora’s ability to orchestrate across multiple parties and different technologies is where we stand out.
SH: The other thing to add is that what we’ve experienced and what we’re seeing now are large companies like banks and telcos with a lot of teams in different locations such as South America or Asia in need of an accessible solution. We set out initially to make sure our solution was a Software-as-a-Service (SaaS) and accessible by anybody without requiring six months of consulting and setting up infrastructure. It was important to us to build a Software-as-a-Service business as opposed to an on-premise business.
How would you describe your ideal customer? What role does customer input and feedback play when you’re working on upgrades?
DS: We built Plutora for large institutions with more than 200 IT staff members, a portfolio of interdependent systems and potential delivery teams both onshore and offshore. If you are a small community enterprise with a small number of people, our system probably doesn’t make sense. Many of the customers that we work with are banks, telecommunications companies, utility companies, large pharmaceuticals, and engineering companies — a lot of larger companies.
Being receptive to customer feedback is definitely an area that we excel in over competition; as an emerging player in the market, we take client feedback very seriously. We have a vision as to where we think the product is heading and that vision is pretty strong, but we are very responsive to client feedback. We’re also trying to go a bit further this year by implementing a new system tool that allows customers to vote on particular features, and it’s working pretty well so far.
What’s the most common issue you see new clients trying to solve by switching to Plutora to improve their release process?
DS: I think the key one is that the definition of release management is quite broad. When we go to market with release management, some people think it’s release engineering and automation. There is an aspect of that, but our platform involves more. A key issue is defining release management and making sure that aligns with the problem the client is trying to solve. There is a fair degree of education between us and the internal training teams, and we spend a bit of time positioning release management orchestration as something that is between the development and the operations teams.
What brought about your decision to relocate Plutora’s headquarters to the US? What do you foresee being the greatest benefits and obstacles, and how do you plan on juggling the needs of your Australian and US clients?
DS: Relocating to the US was always the plan when we started out: when the tipping point of customers was coming from the US, we would relocate our headquarters to be closer to the customers. After two years running, that shift has now happened — most of our clients are now in the US, and being closer makes sense to be more responsive.
The biggest benefit to relocating is being closer to our clients, being able to spend more time with them, being able to operate more closely within their time zones. The other one will be building up a team of local talent to work with. I don’t think there is a downside, other than having to relocate the family.
We will leave a small footprint in Australia with our account managers, but the development function and the growth engine will be located in the US. We will still have the support functions for our Australian clients, similar to what we have in the UK to support our European clients.
As a relatively new (albeit successful) startup, how does Plutora plan to maintain its position among more established ITSM software vendors?
DS: The way that we are going to stay ahead is obviously to have a better product, which is one thing I think we already do. The other part is that we fill a niche that is quite unique. When people sign up with us, they sign up to solve the problem, not to buy a large group of technologies. I think the challenge with some of our competitors is that you need to buy the entire chain of their tools, which makes it quite difficult for a company to solve their problem at a reasonable cost.
SH: The other thing is that because of our relative newness to the market, the technology that we are using and the way it’s been architected is a number of years ahead of the competitors. Our technology base is quite flexible, and it gives us the ability to innovate and to release to market far quicker than our competitors.
What can users expect to see from Plutora in the near future? Have you noticed any trends in the IT management industry that users should be on the lookout for?
DS: One thing that we have published already and some clients are using is the environment management function that we have added to the application. We currently do release management and deployment management, but we have added a significant investment in the environment management side. Now we can match environments to the release function, where you have that nice mesh between running a number of releases that are supported by these environments and being able to understand what those environments contain so you can successfully deliver the release. I think release management ease is almost half of the problem, and the environment management is the other half. We bring those together by combining both modules in our application.
SH: There are actually a number of things [going on in the industry]. Obviously DevOps is the flavor of the month at the moment, and we’re riding on the small wave in the DevOps space around orchestration of release planning and governance, which fits into our tool. The other thing we are seeing is that a lot of the larger institutions are establishing a release management function within their organization, which didn’t occur before. Coming up there will be a lot of focus around the release management discipline in an organization; currently the focus has been on the BPM discipline, the ALM discipline, the ITSM discipline. We see that a good growth cycle is going to happen around the release management function, and that’s driven by the fact that there are so many technologies being acquired and integrated by these institutions. Release management is the natural evolution to address all of these complexities.