Ship on day one
Why Buy-in Is Just as Important as Build-outs for DevOps
The former lead GIS analyst for the Seattle Police Department discusses the importance of relationship building in software development.
Prior to his current job as a solutions architect at AWS, Brandon Bouier put in a lot of work in the public sector. Most recently he was an engineer at the Department of Defense, but before that he spent a little over six and a half years at the Seattle Police Department, where he was responsible for developing the department’s crime and spatial analysis capabilities. Oh, and he did it at the height of the Great Recession. Before speaking at the Get Ship Done! Workshop, he took some time to explain to us the importance of building relationships on your way to building mission-critical systems.
You had virtually nothing to work with when you started at the Seattle Police Department. What kind of support did you have?
It was a bit of a mixed bag. I put together my proposal to take up the chain-of command and said, “This is what needs to be done if you really want to be effective with increasing your ability to do analysis. And this is what I need.” Of course, they came back and say, “Nope, can’t do it.” This was in the middle of the recession, so there were no resources for that. So I took advantage of the fact that I was the only one there doing this work. I got to define what needed to be done. So I said, “Okay, give me a server. Just give me a server.” They found an old one they weren’t using, wiped it clean, gave it to me with access and a blinking cursor, and said, “Here you go.” And that was the support they gave me.
Did you give them what they asked for?
No, it was above what they asked for. This was a classic case of the old Henry Ford quote: If I’d asked the customer what they wanted, they would have said a faster horse. If you ask an officer what they want, they might say, “Can you give me something better than Excel?” They’re looking at the work right in front of them, instead of the long term vision. So you have to figure out how to solve their immediate problem and help them get their job done better, but also figure out what steps to take to improve the entire process.
If someone wants to be better at that, what do they need to do?
You need to understand the entire needs and responsibilities of the organization. I’m talking about this from a government perspective, and governments aren’t profit-driven. They are trying to appease shareholders, but their shareholders are the public. So figure out who your customers are, based on what your role is. My particular customers were the police officers and the police chief – and the general public. So what are their needs? What are their expectations? What is it that they need? And then I have to relate that to what my technical role. Sometimes people in the technical industry get too fixated on the tools they’re using and the technical work in front of them, as opposed to the actual larger organizational or business use case. Do you understand how that widget you’re building or that code you’re programming is going to affect business if you get it done?
What kind of access did you have to your customers, the police?
At first I couldn’t talk to the crime analysts. They couldn’t be bothered. When I came on, they had a bit of a contentious relationship with the folks in IT. So I bridged that gap by offering to train them. I knew the GIS and I knew they used it, so I said, “Hey, just wanted to let you know that you could do this. Did you know you could do this?” And they’d say, “Wow, that’s pretty cool.” And then I said, “If you guys are interested, I can come show you a few more things when you have some time.” That turned into quarterly training. I kid you not — because analysts go to conferences and talk to each other — we actually had analysts from other police departments show up. So that builds the rapport and gets them to the point where they come to you for information. Because you solved their problem. The technology was just a tool to do that. A large part of DevOps is about building relationships. It’s actually more about the relationships than it is about the tech.
Give me one more takeaway from your job at SPD that could be beneficial to people reading this.
Buy-in is important. The best way that I’ve seen to get buy-in is by appealing to the person’s or organization’s particular incentives. Police officers don’t care about the technology. When I was at the DoD, military commanders and generals and colonels didn’t care about the technology. They have business problems they’re trying to solve. Your job is to care about the technology. So when you talk to them and try to convince them that your solution or your proposal is the way to go, you have to explain to them why it’s worth doing, in their words.
Learning that language can’t be easy. How do you do it?
You have to develop domain expertise. When I was at the police department, I would sit in on the 9-1-1 calls. Then I understood what they were trying to do. Then I tried to figure out how they were doing it. And then I would try to figure out how the technology could improve what they were trying to do. But it all starts with what they’re doing and why they’re doing it. Figure out the reason they’re doing this in the first place, and then work backward from there.