Building a Responsive Software Engineering Team
Our Inside Axon blog series is updated every Wednesday and features letters from executives within Axon. This week's post was written by Jay Reitz, Axon's SVP of Software Engineering. Check again next week for more experiences and insight from Axon leaders.
These days, it's difficult to find an organisation that does not practise agile software development. The traditional waterfall process is as hip as a pocket protector, and people from enterprises to embedded and even aerospace are embracing approaches like scrum, test-driven development, paired programming, continuous integration, DevOps and any other buzzword you can think of. It seems that everyone believes that reducing serial, step-wise development tracks can improve outcomes.
At Axon, we're in hypergrowth mode. Our core body camera and evidence management business has grown by 85% year-on-year and our customer list includes some of the largest cities in the world, including the LAPD and the London Metropolitan Police. In addition to building new products like Axon Fleet, our revolutionary cloud-connected in-car camera system, our teams spend quite a bit of time improving the systems that keep Evidence.com available and secure. Very little has been made of how a growth business can strain the limits of agile development and how product teams that already do ‘agile’ can adapt to be more responsive to the needs of the business. All software architecture is temporary and when you're scaling as fast as we are, you're very rarely too far ahead of the current bottlenecks.
There are a few key principles that we have used to guide the growth of the team over the last few years:
Invest in recruiting the best but also the right fit
Saying you have a high hiring bar is as clichéd as agile. So you'll have to take my word for it when I say we have a high hiring bar. Our interview process is not particularly unusual for the software industry. We organise a series of phone screens with recruiters, hiring managers and a technical phone screen where the candidate writes code in a shared editor. Lastly, the candidate comes onsite for 4 - 6 hours of interviews with their potential engineering peers and also with leadership, designers or product managers, depending on the position. The primary focus of the onsite loop is to help understand how a candidate solves problems and to validate that a candidate's knowledge and coding capabilities improve our team. To that end, they are asked to either design a real-world software component and to solve a coding challenge on the whiteboard.
All of this is industry standard for companies like Amazon, Microsoft, Google and Facebook. But at Axon we spend an outsized amount of time evaluating how people identify with our mission and how they will work as part of a team. The products that we build could quite possibly save a life, and we feel a particular pride in our mission and in how our work can improve communities all over the world. It can be difficult to say no to recruiting a brilliant software engineer, but recruiting engineers who strongly identify with our mission and who are humble and team-orientated is key to our ability to execute with agility for the long haul.
Organise into squads
The benefits of empowered small teams are well known. Amazon is famous for their ‘two pizza teams’ (teams small enough to be fed by two pizzas) and studies show that smaller teams are more productive and inspire higher levels of engagement in employees. At Axon, all our software is built by small teams of five to twelve people.
We went through several iterations of team organisation before implementing small teams that we call Squads. Squads are designed to be as self-sufficient as possible. They typically include one product manager, one designer and a mix of software engineers and QA people, all of whom are working to build user experiences within a specific area. For example, our ‘body-worn camera’ (BWC) squad includes embedded engineers who work on our camera OS, back-end engineers working on Evidence.com and mobile engineers working on iOS and Android apps.
As we grow, it's vitally important to ensure that our small teams are empowered with the right business objectives, voice of customer feedback, and knowledge of the broader vision so that they can make great decisions. Our product managers are typically the strongest custodians of this knowledge but we also ask that each of our squad members try to go on at least one agency visit every quarter. Spending a day with agency IT or on a ride-along with patrol officers is one of the unique perks of working at Axon and the program is hugely important to help support our squads.
One of the most important relationships within a company is the one between sales and engineering. It is all too common for these groups to settle into adversarial footing, typically because of mistrust. The best way to build trust is through frequent contact and empathy. We start every department meeting by giving an update on recent sales wins and losses and holding them in our minds. We assign an engineering point of contact to specific agencies and they assist in all customer efforts going forward. And we strongly recommend that engineers interested in the process spend time in the field with our sales reps. This program is mutually beneficial. Engineers can add value during the sales process because they can speak directly to agency IT personnel as peers. And our sales team is the best possible source to represent customer feedback and how our work is being received in the field. For the cost of a bit of travel, our engineers can return with a much better understanding of our customers and a new-found respect for what it's like to be a sales person at Axon.
Leave code better than you found it
One of the most important tenets of our teams is inspired by the conservation movement and was a core belief of Robert Baden-Powell, the founder of scouting. In his last message to the organisation, he famously wrote:
Try and leave this world a little better than you found it and when your turn comes to die, you can die happy in feeling that at any rate you have not wasted your time but have done your best.
The idea of leaving the world better than you found it applies perfectly to software development and has been a guiding philosophy for our team during the last few years of hypergrowth.
The basic idea of leaving code better than you found it is to spend a little bit of time improving a system every time you interact with it. This is important because as a team that seeks agility, we often find ourselves walking the line between sufficient internal system improvement (dealing with technical debt), and building new features for the business. Ignoring technical debt makes every change take much longer than it should and chokes the team's ability to innovate and move quickly. At the same time, spending months or years rebuilding a new system from scratch is totally untenable for our business and for agility.
Examples of leaving code better than you found it includes simple things like renaming variables where they were poorly named or adding documentation in the form of additional comments. But it often takes the form of adding unit or integrations tests to help automate testing and maintain quality. Or determining that a specific component is no longer sufficient for our needs and needs to be rewritten. By amortising these improvements as we're making business progress, we've made significant strides in wholly replacing some old components within our infrastructure.
These are some of the approaches that we have used to build a responsive engineering team. If the idea of working on a dynamic, mission-driven team appeals to you, please consider applying for one of the many openings at Axon. You too might soon be writing code that saves lives.