Armory Sees Code Deploys Increase in the Coronavirus Era
At Armory, art mimics life — or, rather, culture mimics product.
The San Mateo company’s roundabout culture mirrors the aim of its product Spinnaker, an open-source continuous delivery platform developed by Netflix. Named after the roundabout traffic control measure — which relies on drivers using their judgment to make decisions — Armory employees aim to embody that same sense of autonomy when developing new features, said Kate MacAleavey, head of culture and leadership development.
“Digital transformation is really what we sell,” MacAleavey said. “But we’ve all realized and come to terms with the fact that culture transformation and digital transformation have to happen at the exact same time.”
Spinnaker now counts more than 8,000 members among its open-source community. Four hundred contributors add 100 commits per day. Many large enterprises are Armory clients, including JP Morgan Chase, SAP, Genesys and more. And as the COVID-19 pandemic sweeps the globe, customers are using the platform more than ever, rushing to deploy new features and adapt to a changed economy and culture, said Alex Bello, vice president of product.
“There’s a lot more urgency for these companies to accelerate the pace at which they’re developing software and at which they’re transforming themselves, especially in this crisis,” Bello said. “We’re definitely seeing some signs of companies actually shipping more software or accelerating their pace of shipping software across our customer base. It’s something we’re tracking on a daily basis.”
How Spinnaker influences company culture
Companies traditionally update products by deploying code to dedicated data centers and cloud systems a few times per quarter. Every company’s process for delivering software is different, and can be fragmented across multiple tools and teams. Spinnaker automates this path to production, implementing a single testing-security-cloud policy and more.
A switch to Spinnaker puts feature distribution in the hands of developers. Often, this can involve a culture change at middle management, since individual contributors no longer need to ask for permission before pressing go. After companies implement Spinnaker, their culture ends up looking a little more like Armory’s — fast moving, and focused on iterative development, MacAleavey said.
“People buy this and they’re like, ‘I’m going to control everything and make it perfect before my developers can use it,’” MacAleavey said. “We’re like, ‘That process and that view is antithetical to the actual software.’ So they have to get really comfortable with ambiguity and releasing control.”
How product development works at Armory
When Armory started in 2016, the company’s software engineers sold software to their software engineer customers.
Having engineers act as sales reps, product managers and more made sense, since it gave developers greater insight into customer needs and helped drive feature development, Bello said.
But after about a year of supporting customers’ digital transformations, Armory engineers reflected on their own development. The seven-person team was always busy but wasn’t releasing features at the speed the company hoped for, Bello said. A quick look at their pull requests revealed where they spent their time: Armory engineers devoted about 70 percent of their day to supporting customers, leaving just a small portion left for actually coding, Bello said.
“Engineers were doing everything,” he said.
The company has since focused on building out its product, solutions architecture and customer success teams. But that doesn’t mean Armory’s now-30-person engineering team is devoted solely to coding. The company’s engineers continue to offer insight on how to work with Armory’s highly technical customers.
“We have software engineers building out software for software engineers. So naturally they also have a lot of opinions on what the problems are and what the solutions are,” Bello said. “So they kind of have to be involved with customers, right? Because they’re almost like their peers.”
Selling to customers blinded by solution bias
When Beth Fuller decides what feature to build out next, she thinks about what she’s been hearing from Armory’s customer-facing teams and clients. A key component of Fuller’s senior product manager job is unpacking what feature actually needs to be built for Armory’s customers, and what priority it holds in Armory’s organization.
One issue she consistently runs into: “The wonderful thing, and the really challenging thing with this group of people, is a lot of times they’re giving you the problem based on what they think the solution is,” Fuller said.
To this end, Fuller asks customers how the problem they face fits into their workflow. She talks to Armory’s solutions architects, and other customer-facing teams, about whether they think prospective customers can be swayed to sign with Armory over a new feature.
The company has invited customers into its instant messaging platform and structured Slack so that any post that includes #feedback is collected into a central, searchable database. But sometimes messages still get mixed up and developers end up working on the same issue, said Sean Korten, manager of solutions architecture. The company has established a five-person team dedicated to establishing best practices for using and organizing its Slack to avoid this problem.
“We have a tendency to communicate so much that it’s impossible to consume it all,” Korten said.
But constantly asking for feedback sometimes leaves customers feeling like they haven’t been heard, Fuller said, since Armory can’t immediately implement every product request received.
“You’re like, ‘Hey, we built this thing’ and [customers are] like, ‘Great, but you didn't do these five other things and now I hate you,’” Fuller said. “So you gotta work through that, which is why it’s really important to have all these teams that you’re working with in concert.”
Customers define how features are developed
Once the product team identifies a feature to work on, Armory’s solutions architects look for prospective and current customers to act as arbitrary design partners. These customers offer feedback about feature design.
Every two weeks, engineers and product teams deliver an update to their customers. The company often posts these iterative updates to feedback.armory.io, a site that lets clients tell Armory what they think of the new item. Fuller said developing and creating product adjustments in this style is much cheaper and easier than spending six months building a new feature and receiving feedback after launch.
“You bring the customers along step-by-step, and internal teams along step-by-step. So even if it does take a little bit longer than what the customer would like, they know that you’re making progress and they’re building software too. They understand that process,” Fuller said. “So if you think about that roundabout culture, you’re creating empathy. They understand that you have empathy for them, and then they also have empathy for you.”