Designing for Public Safety

Karsten Rowe at UXDX Community: Simplifying Design Processes for Team Efficiency. Video: https://youtu.be/4pday_XSMXg

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Introduction and Axon's moonshot

[00:00:00] Hello folks. We've only got about 25 minutes today, so I'm going to move quite quickly, but if you want to follow up with questions at the end, that's great, or just find me on LinkedIn or wherever you want to find me. I'm happy to answer questions at the end. Very quickly, here's a quick agenda. I'll do a quick intro and background about me, where I've come from, where I'm at today, and then I just wanted to share some hard lessons I've learned when changing industries. Public safety is an interesting space to design in. It somewhat has its own conventions and rules, and some things are more important in that space than maybe building sales software or consumer software or software in different industries. That's what I want to cover today.

[00:00:44] Quick intro. A long time ago I was from a little town in England called Harriet [?]. It's very pretty there. When I was four [?], I was either going to be a soccer player or a designer; those were the only two things I was good at at school. I got my first computer and fell in love with it, went to design school, went to London, worked there for 10 years, then moved to San Francisco, and now I'm in Seattle. This is just a quick flip book of lots of things that I've done. I'm not going to pause for too long on any of these screens, but it's really just a flip book of all the things that I've done.

[00:01:22] What do I do now? As I mentioned, I'm at Axon, and our company moonshot right now is about cutting gun-related deaths between police and the public by 50% in 10 years. We're in the second year of that moonshot, and it's really what motivates me to get up every day. I think as you get a bit further in your career you need to find that mission that really pushes you on to do your best work, where you really believe in what the company is doing and what we're all about.

[00:01:54] Here's our CEO, Rick Smith, very much a visionary guy and awesome to work alongside. Here are some videos. I'm not going to play these in this setting, but if you want links to them, maybe I can send out my deck afterwards and you can have a watch of some of these videos. I'm just going to skip over them for now, just for time.

[00:02:19] To give an idea of what we're doing at Axon, it's these four themes or areas. Detecting what happens out in the field: where do we need law enforcement, fire, medical? Then managing those resources smartly and efficiently. Then situational awareness: when I'm driving to that event, how do we give enough data up front so that officer, or whoever that public safety person is, has enough information up front, so they arrive on scene with the right information and can manage the event effectively? And along the way there's a lot of communication that happens, from dispatch, from the command staff, from a real-time crime center, to the officer in the field on foot, all those kinds of things. That's the area that I work in today. Here are some personas and some capabilities of the things that we designed. Not super interesting; I'm just going to flash it up.

Things I wish I knew when I was starting out

[00:03:13] To get on to some of the lessons that I've learned and some dos and don'ts, I've broken this down into three areas. When I was starting out as a designer, what do I wish I knew that I know today? Then when you become a manager, what does that look like, and some of the hard lessons I learned there. And then specifically around designing in the public safety space, and what makes it challenging but interesting.

[00:03:37] Things I wish I knew when I was starting out. I was very competitive, and I was competing against other people in my team. It wasn't helpful; it definitely held me back. Just focus on being that team player, focus on being your best self, and don't measure yourself against anybody else. There's always going to be somebody smarter, faster and better looking than you, so just take that on the chin.

[00:04:03] Another thing is around picking a job. There are all these blue chip names and glamorous companies you can go work for, but I've found it's about picking a manager. In that hiring manager conversation you have when you're interviewing at that company, I'm always going to lean on picking a manager that really inspires me, somebody who motivates me, somebody I look up to and I think I can learn from. I'm always going to lean on that rather than the company itself.

[00:04:30] Everybody talks about talent. I always say it's overrated. Oh, there's a phone ringing. I don't know how to stop that; I'll just keep going. Hopefully you can hear me. To get good at anything, you just have to practice a lot, so don't think that you can't do it because you're not born with talent. I really think that's a fallacy.

[00:04:51] I think a lot of designers early on just focus on pixels and glamour and something that's sexy, and where they fall over is they don't really have that grounding of what problem they're solving for, for whom, and in what situation. That's something that I've learned the hard way. The visual, slick design and that animation or motion, whatever you want to do to make it sexy, that's easy to do. Truly understanding the problem and setting out in the right direction is much harder.

[00:05:27] It's a marathon, not a sprint. I do a lot of running, and I think this is just about finding your own pace. There's no point working a 12 or 14 hour day if for the next two days you're useless and you're tired and you're angry and you're grumpy. That just doesn't work, so find the right pace for you.

[00:05:44] Measure the design against business objectives. In a lot of companies you'll have OKRs, or we call them missions and metrics. Always understand what that piece of work, that project, is rolling up to. That's how you're going to be able to somewhat measure the design and judge the success of the design. You want to roll that piece of work up to the highest-level mission and metric that the business is chasing, and measure the design, and the impact of that work, against that.

[00:06:14] Another thing is to focus on your strengths. I know leveling guidelines and stuff like that are somewhat challenging; they expect you to be good or great at everything. When you're building a team, it doesn't mean ignore those weaknesses, but you're always hopefully going to be really good at one or two things, and I wouldn't shy away from being really great and being a standout candidate for a role or a job based on those strengths. Just a little bit of balance there.

[00:06:48] When I say focus on the problem and the people and the users: just spend time with customers. This was a driver appreciation day at KeepTruckin. Every time I was designing something, I was thinking about one of these customers or users that I'd met and saying to myself, "Oh, what would Bob think about this?" and really grounding my thinking and working in users.

[00:07:10] This is a quote about golf. We're not going to read it today, but it's really about practice makes perfect. It didn't come easy, and I think all the best people in the world, in whatever industry or discipline they're in, it just takes a lot of work to get good. Just be okay with the quantity of work. Yes, you want quality work, but the quantity of work, especially in an early career, is very good to get under your belt, and learn by doing.

Things I wish I knew when I became a manager

[00:07:44] Next up we've got things I wish I knew when I became a manager. This might be relevant to some of you folks who are either in management or thinking about becoming a manager. It's a hard job. The first thing is about leading by example. You are the culture. You can't blame other things; you set the tone. Every Monday morning have the right attitude: be well rested, be positive, be energetic. You can't ask your team to do that if you're not doing it yourself.

[00:08:19] Set expectations. That's when you're onboarding a new hire, or expectations with your partners, PM, engineering, those kinds of things. Doing that documentation up front and setting those guardrails, the routines and the systematic way that you get through a week and the systematic way that you actually ship work. It's just important to get them documented and get buy-in, and everything is easier after that.

[00:08:44] This is re-evaluating the definition of perfect. As a youngster you're a perfectionist, but in reality, in the real world, one, you've got to make money, and two, there are deadlines, there are customer commitments that you've got to meet. Perfect to me now is the highest quality work that me and my team can do in the time allowed. "Time allowed" is the important piece. There is always that constraint of time, and on any project I've done over the last 10 or 15 years, if I was given an infinite amount of time, the quality would be higher. Just keep your expectations in check and redefine what you think is good enough and perfect. Good enough is the best quality you can get to in the time that's allowed.

[00:09:33] Focus on top performers. This is a really hard one, and I still struggle with this. In every team there are going to be top performers, and there are going to be people who don't quite meet the mark and don't quite meet expectations. I think I've spent too much time getting the underperformers up to par, rather than spending more time with the top performers and making them even better. Making those top performers brilliant is better for business. I know that sounds cruel and brutal, but that's just the reality of the work. It doesn't mean I don't care about everybody on the team, but don't spend 80 or 90% with your lower performers and only 10% with your high performers. Try and make a better balance there, so everybody gets a fair chunk of your time. That's a hard one to learn.

[00:10:25] The other one is hiring bar raisers. I've slipped into, "Oh, we're in pain and we need to hire, and this person can do the job." But are they better than the people you've already got on the team? If they're not, they shouldn't get the job. The bar should always be rising for you and your team, and it's amazing what happens when you hire somebody who is a level up from the current performance of your team. It brings everybody along. It makes people look around and say, "Wow, that new person's great, I'm going to level up my game too." I think there's a knock-on effect of that.

[00:11:01] This is one of our values: being adaptable. In tech and in design, things are going to change. Projects are going to change, scope's going to change, management's going to change, the general direction of the organization could change, people are going to arrive on the team and leave the team. Just embrace that change. That's something that's always going to happen, and I think being flexible and adaptable to that change will make you more successful in your career.

[00:11:32] The last one is, as a manager, I try and be nice every day, but really your role is to be fair, so somebody can understand where you're coming from. I want to be everybody's friend, sure, but that isn't a requirement to be a great manager. A great manager can just be fair, and that's all you can really ask for.

[00:11:57] We talk about the team at Axon being a high-performing sports team. They're not a family, because that's unrealistic. They wouldn't pay you a lot of money if you were a family member; they would just expect you to work for free and all those kinds of things. So we use the analogy of a sports team: you've got to earn the right to get on the team, and you've got to earn the right to stay on the team, and there's always going to be that person below you who wants your role and wants your job. I know that sounds quite brutal, but that's the world we live in, and that's what we should embrace. If you want to work in technology and design on the west coast of America, that's just the culture, so accept it. A quick picture of the team, all those kinds of things.

What it's like to design for public safety

[00:12:41] Just moving a little more quickly now. What's it like to design for public safety? A couple of things have changed the way I build products. In public safety, the products have to be super reliable and stable. If Facebook goes down, it's like, "Oh, that's annoying, that's frustrating, I can't see my friends post about something," but that's not that important. If you try and call 911 or 999 and it doesn't work, then lives are at stake.

[00:13:19] That engineering excellence, and being very thorough with your design process, making sure you're shipping the right thing: you can't do so much testing of "let's do a little experiment and see if it works." It's not that environment. The quality bar is a lot higher in public safety, because if things fall over and things fail, or somebody finds the UI unintuitive and can't complete the task, it can actually put lives at stake. That's the big one that has been a bit of a game changer for me in terms of how I approach things.

[00:13:56] Measuring design in public safety: the key metric is often time on task, the success rate and all those other things. As a dispatcher or call taker or an officer, time is at a premium, and the main metric for a department or an agency is reducing that response time. Somebody calls 911: how do I dispatch the right unit to the right place as quickly as possible, with the right situational awareness, so that they hopefully can de-escalate that event? That is a key metric in the experiences we're building.

[00:14:33] You have two customers, and this is what makes it somewhat controversial. I have to do what's right for the public, meaning do we use facial recognition and be invasive? And also my paying customers are police departments and public safety departments. You've got that balance between the two. We have a value at Axon that we say: win right. Winning right is always right. We're never going to build or ship something that puts the public's trust in jeopardy. We talk about it as two customers. Even though the public aren't paying us, we never want to break their trust in the things that we put out into the world.

[00:15:25] A couple of things here: environmental factors. We sit in offices in front of our shiny MacBooks. Let's just say a police person, a cop: they're at the station, they're running to their car, they're driving 90 miles an hour with lights and sirens on, they're chasing a suspect on foot. There are all these different environmental factors, and the form factor of the hardware and the software needs to play into that and might change depending on their situation. So really optimizing for that.

Change management and the Watch Me feature

[00:16:05] There's a little bit of a typo here, but: change management. Things in public safety move a little bit slower, and the quote here is, "The only thing cops hate more than how things currently are is changing how things are." Embracing change: a lot of this software has maybe been used by that dispatcher for 20 years. They know every hotkey, they know every shortcut, they're hyper efficient, so any change and any disruption in that workflow is problematic for them.

[00:16:39] Another thing in this space: there's a lot of training. As a call taker you go through weeks of training. If that person goes through weeks of training and then you do a massive overhaul of that UI or that experience or that workflow, it's very disruptive to that individual, and you just have to be very careful. We want to move the industry forward, but you have to do a lot of handholding, do it in baby steps, and make sure that you don't break something in the middle of somebody's shift.

[00:17:14] And just lastly here, this is a feature that we built recently. It's called Watch Me. On the body camera today, an officer can press a button that sends a notification to their supervisor, saying, "Hey, I want you to jump into my live stream and help me with this situation." It might be a new hire, it might be somebody who just doesn't know how to handle this situation, it might be somebody who needs somebody to help them with translation. Thinking of maybe Spanish: I'm not a Spanish speaker, but if a suspect's Spanish, how am I going to have that conversation? It might be a mental health expert or somebody else that can jump in through the body camera, watch the live stream and talk the officer or individual through a situation.

[00:18:03] With that being said, imagine what the cop thought of that. Let's be specific: a police officer. Imagine somebody being able to watch over your shoulder while you're designing or writing code or whatever you're trying to get done, and your manager is just watching everything that you do. From the cop's perspective there was a lot of pushback: "I don't want that big brother. I know how to do my job, I've been doing this for 20 years." What we had to do, the way we designed it, was allow the officer to reach out for help, not that the supervisor automatically has permission to look over their shoulder into their world.

[00:18:41] That's what I mean when I talk about two customers, and what's right for the public, or what's right for a supervisor, or what's right for a patrol officer out in the field. You're always looking at the two sides of the coin; there's always the other person. Even though we thought this was a great feature, we got a lot of pushback from patrol officers saying, "I don't want that. I'm going to quit my job if my manager can look over my shoulder and see how I'm handling the situation." So we had to flip the control of power there and empower the officer to ask for help, rather than the supervisor just being able to jump into any situation.

Set big goals

[00:19:23] I'm not really going to talk too much about the UI of the design, because I don't think that's super helpful. A couple of parting comments and then we can move to questions. Another thing in my career is I've always set really big goals. As I said, from a small town in Harriet [?], I got all the way to San Francisco, which was my dream: to be head of design at a billion-dollar company. I didn't think I would be able to get there, but because I committed to that goal, I wrote that goal down and shared it with family and friends, and it really pushed me on.

[00:19:58] My next goal is to go and work for NASA. I don't know if that's too unrealistic, but designing that in-rocket experience, to hopefully get to the moon and Mars, is what I would really like to do, and all my friends know that that's what I want to go and do. Over the next 10 years I'm going to be working towards that. I'd encourage you just to set those goals, however lofty they feel right now. If you chip away at them year on year, you'll hopefully eventually get there. You'll definitely not get there if you don't have the goal.

[00:20:33] And then, just Ted Lasso. I've been watching it recently. I thought it was funny, and I'll share this deck out so you can read them, but these are just some leadership lessons from him. It's a very funny show, but I think there's this clever undercurrent of really interesting and quality leadership skills, things that are said in the series that I think can resonate with anybody in a leadership role. All right, that was me. We've got about six minutes for questions, so Katherine, over to you.

Q&A

[00:21:03] Katherine: That was fantastic. I personally have a lot of questions, but there are other people that I'll let go first. I should introduce you at some point to Mara [?]. She's head of human systems integration at NASA. She's spoken at UXDX before, and she's a really interesting character and absolutely loves what she does, and they're doing some phenomenal work there. Going back to Axon and working in public safety: you broke it down into a few different core areas. The management one has the most questions for you. How much documentation is over-documentation, versus efficient to establish expectations?

[00:21:52] Karsten: That's a really good point. I think you can't do it all at once. At Axon we have a thing called the Book of RTO. It's the book of real-time operations; it's like our playbook. I own the UX edition of that book, like a chapter of that book, and I have about, I don't know, 30 or 40 documents. Most of them are templates that designers will use on nearly every project, but then I have a wish list, and one of your team will hopefully help you with that documentation over time.

[00:22:25] I think it's setting your cadence out for the week: what does a Monday, Wednesday, Friday look like? That way everybody arriving in the team knows what my expectations are, and if you follow those expectations of me and the leadership team, you get a longer leash. It's to your benefit: follow the rules to a certain degree and then you get more freedom over time. I think for every team it's different. I'm happy, after this meeting, to maybe provide the top 10 documents I would write as a new manager arriving in a new team. I'm happy to probably print out that list, if that's helpful. But it grows over time, and some things go stale, and that's okay too. It's never finished. The Book of RTO is very much a living thing, and the list of to-dos and the wish list is probably longer than the things that we've actually done.

[00:23:19] Katherine: And what happens when people are not up to the same scratch as your top performers? Should they be let go? I don't know how to interpret that. Is there a difference? Should people not be the top performers, and that's okay, they keep the lights on?

[00:23:43] Karsten: That's a hard one too. You are going to get those people who are more steady, and maybe, I would say, slightly less ambitious. They're not workaholics, but they're very steady and contribute across a year in a very fundamental way, so you can't ignore those people. Not everybody's going to be a high performer, and high performer is basically related to your level. You can be a really high performing L6, but once you get to L8, L9, it's harder for them to maybe break out of that ceiling and get to L10, L11, a VP kind of level. A lot of people have ceilings.

[00:24:22] I think number one is really spending time on those performance reviews. We do mid-year and end of year, and they have to be really thoughtful. You can't go in there and break somebody, but you really have to focus on those misses, those areas of opportunity, setting those goals for the next six months, giving them a career template, something that they fill in on a weekly basis of how they bridge that gap. That way they have evidence and documentation for when they come back to the next performance review, and you can really see how they've taken on and digested that feedback, and whether they've really gone above and beyond to bridge it.

[00:25:01] For many tech companies on the west coast, you have four ratings: your top 25%, which is obviously top performer; you have achieves; doesn't meet expectations; and least effective. If you're in that least effective bucket for more than 12 months, you're probably in the wrong company. That might just be because of the situation, maybe it's the industry, maybe it's the culture, maybe it's just not a great fit for you. It's not always the individual. Sometimes it's the company and what's needed at that time to do what you need to do at a business level, because if you're not successful as a business, nobody has a job.

[00:25:44] It's not anything against the individual. It's not like I don't care; I truly care about everybody. It's more that if the business doesn't work, nobody has a job, and you have to really consider that in terms of performance. And if we decide somebody does have to leave, I'm the first one there helping them find that job, doing a portfolio review, helping with the resume. It's not a nice thing to do, but as a manager that's something that you're signing up for, and if that's too cold and too hard for you to do, you shouldn't be a manager.

[00:26:16] Katherine: It's a really interesting point. And what's the concept of, let's say, you as Karsten? You're saying stuff as a founder, an entrepreneur in that instance, versus at a large-scale company. You are thinking of both the business side as well as the management side, and yet you stick with more traditional NASA or government types of roles. Just curious.

[00:26:43] Karsten: It's just childhood dreams, isn't it? I was always interested in space. I've done a lot of things with telematics and maps and communication and in-car experience over the last few years, so I'm just taking that car, flipping it, turning it into a rocket. I'm like, that's the job for me. And I think once you tell your niece and nephew you're going to be head of design at NASA, you have to commit and get after it.

[00:27:09] Katherine: Love it. And I'll ask one more question quickly. How do you move fast when mistakes are costly? You did touch on this a little bit.

[00:27:20] Karsten: That's a good point, and I would say you don't move as fast. I've worked at startups, and if it's just a bunch of guys and girls in a basement and you all say, "Yes, it's good to go," you ship it that afternoon, and you probably break something. We have a notion, a process, called definition of done, which is a very thorough checklist from the design and engineering side, and the product side to a certain degree. You have to follow every step before you're allowed to ship something. It's that level of scrutiny around shipping that allows us not to break stuff. But you don't move as quickly, is the honest answer.

[00:28:01] Katherine: That's a lovely way of framing it, with the definition of done. That's almost packaged that piece. Thank you so much, Karsten, that was really fascinating. Loved meeting you, and hope to see you again.

[00:28:16] Karsten: Thank you.