77 Human Centered Devsecops
We are joined by Aidan Feldman(https://twitter.com/aidanfeldman), freelance technologist and former Technology Director at Technology Transformation Services at GSA(https://twitter.com/GSA_TTS) to dive into a conversation about the space where human centered concepts meet with devsecops.<br><br>Resources and shoutouts:<br>- https://99percentinvisible.org/episode/curb-cuts/<br>- https://blog.thepete.net/blog/2019/10/04/hello-production/<br>- https://www.youtube.com/watch?v=0wIvXfhWpx0
Top Keywords
- folks 0.006
- trying 0.006
- make 0.005
- might 0.005
- work 0.005
- team 0.005
- security 0.004
- using 0.004
- tech 0.004
- devsecops 0.004
- prioritize 0.004
- much 0.004
Transcript
Hello. I'm Ryan Cook, and this is Civic Tech Chat, a show that looks at the way technology, politics, and policy impacts the world around us. The tools we use, the way services are delivered, and how we talk about and set policy all shape our society. We'll gather around and have a chat about these things together and more. Before we get started, I do wanna let you all know that we've started a Discord for the podcast. There will be a link with an invite down in the episode description. Do feel free to go check that out. It's a small community right now, but hoping to grow it. It's a great way to reach out to me and let me know things that you might want us to cover or to just hang out and talk about civic tech. Anyway, let's go ahead and start the show. Aiden, thank you so much for joining us here on Civic Tech Chat. Could you introduce yourself and tell us a bit about what you do?
Sure. Thanks so much for having me. I am a freelance technologist. Been starting doing that this year, working with, nonprofit and government customers. So past seven years before that, working as a federal employee at a couple digital service teams. So first, 18F, and then a small team in the Census Bureau called XD and then back to TTS, which is also in the General Services Administration. So that's been, like, my tech life for for the past while. And outside of that, I teach people to code and also am a modern dancer.
I was gonna go to the next question, but with the end there, I kinda have to ask, what what do you mean by modern dancer?
Yeah. So I have been dancing longer than I've been doing tech work, and went to college for both and pursued both in parallel since and been able to, yeah, keep it going as, like, a, you know, thing I do outside of my day jobs and work with a few dance companies and perform pretty regularly. And, yeah, we, did our it's a nice balance to, like, kinda have the very cognitive work and then the, you know, very physical work, to balance it out.
Oh, that that that is, that is very cool. I think it's a it's a good thing to be able to have those kind of things to balance out like that.
Totally.
And, Ian, what would you say is your personal why? That thing that drives you to get out of bed each morning and do all those things.
Yeah. I mean, I have those, you know, kinda three areas, that I do professionally. So, you you know, I think we're just mostly talking about the tech one today. So within that, I really enjoy, like, making things work better. That comes up as, like, tools and process and, automation and documentation, things that, you know, end up being pain points for people, finding ways to, like, kinda reduce that friction and all that. So the civic tech interest broadly came from, you know, backgrounds and interests in engineering and teaching and also, open source and, like, transparency more broadly. So that brought me from, you know, the tech companies into into civic tech back in, like, 2014. And, yeah, the the the work in government is been a thing that I've liked way more than I thought I would, starting out. The, you know, kinda no one no one's there to just, like, get rich or or that kind of thing. Like, people are there because they want to be. And, yeah, there's, you know, just so much room for improvement. So, you know, any any sort of impact you can make, either making the other staff's lives better or, you know, the end end users' lives better is a huge win.
Are there any pieces of media, or they were talking a podcast, a book, video, or some other such thing that you would recommend to the folks out there listening?
Yeah. So I am a huge podcast, addict. I have a whole spreadsheet of recommendations, that I send to people. So if you're interested, reach out. One episode I really like that kinda touches on or is adjacent to, like, civic tech is, an episode of 99% Invisible, which is a show about kinda design and architecture. And they do a show on curb cuts. And so, for those who aren't familiar, those are, like, the ramps that go, like, onto sidewalks from streets. Those were not always around. That was, like, a past fifty years kinda thing. And that came about because of, like, advocacy of, wheelchair users, but ended up being really beneficial for people with strollers and grocery carts and bikes and had all these, like, positive spillover effects. The development of those, like, led to the Americans with Disabilities Act and then the concept of universal design, which is, like, designing for the greatest number of people possible. And, you know, if you make things accessible, then and it's being better for kind of every category of of users. So I really love, you know, that that physical analogy to you know, it's very applicable to, like, digital products as well. As we hop to our kinda main topic area,
let's start off by defining a term we're probably gonna use a fair number of times, or at least have it written in this question sheet a bunch of times, which is the the term, DevSecOps. When you're using that phrase, what what are you describing?
Yeah. So it's really common in, you know, probably the enterprise IT world, certainly in the government tech world. Not something I came up with, but a lot of my work kinda falls in there. So it's a compound word of development, security, and operations. This was sort of the successor to the term DevOps, which, you know, was focusing on bringing those two practices and and types of teams together because historically, like, they'd operate sort of in isolation, and the development team would throw their software over the wall to operations folks and, you know, never kinda see it once it hits production. And, you know, so that that compound word is literally, like, overlapping those two concepts and teams and kind of making it more of a blended thing. DevSecOps just sticks security in there and very intentionally in the middle, I think. So this is, you know, ensuring that security tooling and processes and security expertise are all part of, like, building and operating software. And, you know, practically this can mean things like automating dependency upgrades or doing some sort of intrusion detection or other things like security focused code reviews, right, the more human part. So, you know, anything that kind of that glues those people with those different sets of experience together and, you know, tries to break down, like, the silos.
Folks looking at the title of this episode also probably noticed the mention of the phrase human centered. Often, we discuss that when we're talking about things like inclusion of UX research techniques and processes for software to help ensure that stuff getting built is actually useful to the human beings that ultimately, like, wanna use the thing. How does that fit in with this DevSecOps space?
Yeah. So focusing on that end user, which is, you know, often the public for government services, that focus is great, and, you know, I I very much applaud that. Where I see a big gap is when you're talking about internal systems and internal policies and this kind of thing. It often does not get the same kind of care and attention, that the external stuff does, and the external stuff doesn't even necessarily give as much attention as it should, get. So, you know, there's questions that you can ask to, you know, kinda start thinking this way, which is, like, what's frustrating for the staff or, you know, whoever your support or your teammates, right, whoever you're thinking about. And then, you know, there's also things like what keeps them up at night. Right? So you can have like, security experts, come in and do, you know, penetration tests and things like that. But your your team is also probably has, like, a decent sense of, like, where gaps are, and so you can ask them. So, you know, with these kinds of questions and then, you know, so subsequent planning and and fixing of them, like, you can address those frictions and fears and, through that improve productivity and morale and retention. So it's it's all actually has, like, positive effects beyond just, like, addressing the issue. So listening to internal staff and making the right thing the easy thing, I'm sure that's gonna come up again today. But, you know, all these things can be applied to kind of the external facing processes. Right? Your your forms that you present to users or processes you make them go through to get benefits or what have it what have you. Then it can also apply to your technical systems and and platforms and things you offer internally, but it can also apply to stuff like HR or training or or anything else. So it's just that mindset of, like, you know, what does this person want to do? What's preventing them from doing it?
Okay. I think what I'm hearing from you there is effectively that, like, you know, UX techniques, like, research techniques don't just have to apply the things you're you're building. Right? Like, I think early in your answer, you mentioned the idea of, like, well, policy sometimes can, like, get in the way of of folks. And so it's kind of I guess, what you would suggest is when you're coming up with, say, an organizational policy, the first step might be to start by asking those questions, like, conducting those interviews with folks it would affect. Am am I kinda hearing that correctly?
Absolutely. And just teach you you know, treating your staff within your organization or whoever your, you know, whoever your thing affects, like, treating those people as users, like, with respect and and understanding, like, what they're trying to get out of it or or what they would want changed and that kind of thing and and try to address their needs.
In a talk, you go into some detail about ways you can utilize processes and tools to run projects. I gather a fair bit of it seems to fall on the theme of really trying to, like, keep things somewhat simple. Is that a principle folks should be actively trying to follow as they go to manage these projects?
Yeah. There's a quote by the, mathematician, Blaise Pascal that's, I I made this longer than usual because I have not had time to make it shorter. So I think it's awesome. I like attributed to Mark Twain and and that kind of thing, but it's actually Pascal. It's not an easy thing to do. Right? Like, simplification is not, you know, usually the first way that something happens. Right? You you have to you have to refine and refine in order to get there. Technology choices, you know, architectures of systems, policies, and that kind of thing. Like, any simplification you can find can save you pain later because it reduces the number of moving parts and, you know, or or the clarity of what you're trying to express if it's a policy, that kind of thing. And that's important because, like, in technological systems, for example, complexity leads to bugs, leads to, you know, edge cases that you didn't think of, and those can sometimes be security vulnerabilities, or other problems. And so, you know, the the more that you can remove moving parts is a is a good idea. It's easier said than done, of course. So a a way that I suggest thinking about it, and this also, you know, sort of parallels with, like, what do you build versus what do you buy. So it's kinda the same thinking, which is, like, what's your what's your differentiator? What's your, like, thing that you're trying to do that's unique here as opposed to what's a commoditized need? Right? What are what are problems that other organizations have had and solved? And, like, can you just use whatever they're using, which will often be software as a service or or whatever. Right? So so differentiating between those two can go a long way to cutting out complexity and sort of offloading it to someone else.
You've also talked about how humans are inherently bad at making estimates, which leads you to advocate for estimates that are less granular, which might be somewhat counterintuitive for for some folks as they, like, come across that. I think the guideline you mentioned is to say it's either days, weeks, or months, but without numbers for, you know, prepending, any of those things. Can you talk a bit about the the advantages of of going that way?
Yeah. I once went to a budgeting meeting, and I brought a jar of jelly beans. And I had people guess, like, budgeting people that, like, do budgeting professionally for for information technology. I had them try and guess how many jelly beans were in this jar, and the answers were all over the place. And, you know, what I said to them is, like, you you could see everything that's here. Right? This jar is in front of you. Nothing's changing. There's no surprises. And still, we were, like, way off in terms of how many are there. Like, this is the same thing for software projects, but for some reason, we think that, no. This time, if we, like, really, really concentrate, we're gonna figure it out. Out. And the truth is, there's a concept from, I believe, pragmatic programmer of sort of, outdriving your headlights. So, you know, you're trying to, like, guess at things that you that are out of your line of sight, and it's just not possible. So, you know, whether it's guessing in points, in terms of, like, estimating tasks and that kind of thing, like, people argue about what the points mean. If you are in teams that do exact estimates, like, you know, this number of days or this number of months, like, this particular day will be done, those are gonna be wrong, and that leads to tension. So days, weeks, or months, no numbers, strikes a balance of being specific enough, to give a, like, rough order of magnitude. Never kinda knows what you're talking about, but then also is vague enough to give reasonable amount of wiggle room as, you know, things come up. So sometimes there's hard deadlines and there's nothing you can do. And then in that case, it's a matter of being ruthless about the priorities and, you know, determining what constitutes your minimal minimum viable product and then, you know, what are nice to have.
Yeah. In in some environments where this might apply, including government projects, there can kinda be a a tension around this where it's like, oh, we wanna be agile and adapt and learn the things. Basically, I I think the headlights analogy maybe fits here. It's like, you know, adjust the things that you can see. But then also, as we're talking about estimates, they also want these, like, long term projections, those more exact estimates that I think you're pointing to as being, usually folly to to to try to do. How should someone go about trying to balance these kinda competing concerns when you're working with a partner?
I think it's important to keep empathy, you know, to to remain empathetic. Right? If there's a reason that your boss is asking for a lost long term estimate, like or, you know, if they are asking for that, like, there's probably a reason. So what is that reason? Like, can you investigate that and actually figure out why? So as an example, like, this came up, in that in that budgeting team that funds IT projects, and they were asking for, you know, projects to estimate multiple years out. Well, they weren't just doing that because it turns out that, the office of management budget wanted financial projections five years out for the overall fund. And so to get projections for the overall fund, they have to give projections for all the things that they're funding. So it is entirely, like, reasonable that they are requiring that of projects because of things being imposed on them. But you then you know, once you once you sort of understand root causes, you can then find other ways to address. Right? Is there a way to, like, meet that need and yet, like, structure things in a way that, you know, leads to good results? So, for example, instead of, you know, everyone guessing what their what their project costs are gonna be five years out, could we flip it on its head and say, hey. We're gonna give this project $1,000,000 for three years and, like, do whatever you can for $1,000,000. Right? You this is, like, the agile principle of, like, you know, fixed cost, flexible scope, or fixed resources, flexible scope, that kind of thing. So, you know, if you get two major features done this year versus three major features done, like, you know, that just depends on things that come up that you couldn't have anticipated. And, yeah, those, you know, those long term medium term goals you agree on, like, those can be fixed, and you could even, like, fix the cost, like, as I just described. But, you know, the the day to day and week to week can kinda be up to the team to prioritize.
It it sounds a bit by flipping that you're kind of instead of asking, like, how much time and energy will it take to do x, it's more like, well, how much time and energy are you willing to invest in x to see, like, where things end up? Is that kind of is that I guess, is that effectively the angle?
Yeah. Because you don't know how long it's gonna take to build x given feature. So we can say, alright. We want five people working on this for a year, and here are our goals. Let's see how far they get.
In a talk focused on this same topic, you make reference to a piece written by Pete Hodgkin. I probably mispronounced that, and apologies to Pete. But it's called Hello Production, which advocates advocates for trying to deploy something useless as early as you possibly can. Why is that a a a good thing to advocate for?
Yeah. I like this article a lot. A big driver for this approach is to avoid surprises, and that applies to both the team, like, trying to deliver whatever system or, you know, kind of this can apply to policy and that kind of thing. Both, you know, sort of internally on the team working on it, but then also the people that it affects on the other side. So developing, you know, system or policy or whatever in isolation avoids interacting with all those people that might crop up along the way. So for a technical system, this might be the security team. This might be enterprise architecture people. This might be lawyers. This might be the end users, etcetera. The sooner that you get something out of production, the sooner you can, like, force these problems out of the woodwork that might appear later and, you know, reveals those blockers early. That's great because you can now have like, start to address them sooner and do that in parallel with good iterations of development and hopefully, like, strike balance and, you know, kinda negotiate, like, an understanding with with the stakeholders of, like, okay. What are the things that they want to know about? Well, they wanna know if there's a change to the encryption that you're using, or they wanna know if there's a change to, you know, the the types of personally identifiable information that comes up or whatever. But you can know that by going through the process. And, you know, once you have that agreement, that allows you to, like, sort of get in the cadence of delivering, more quickly as opposed to, like, a big bang release, which is, you know, we've worked on this for months or years, and now we're trying to finally ship to production and all this stuff, you know, that we didn't know about happens at the end. It gets that out of the way sooner.
It it sounds a bit like going through this process early is, in a way, almost kind of a like a UX research step in in and of itself. Right? You know, when you try to deploy something, you mentioned stakeholders. Right? In a way, you're kind of figuring out who they even are by, like, who, you know, who who ends up being concerned and wanting to show up to meetings when there's questions about how to deploy, different things. It sounds like that's probably pretty crucial to figuring out, how ultimately, like, your system should be set up at the end.
Absolutely. Yeah. So, you know, if you can just deploy a landing page, that's kind of the system equivalent maybe of, like, a UX researcher doing, like, wireframe diagram or or a a paper prototype. Right? It's like the simplest thing that someone can use that, like, demonstrates the thing. This is the the equivalent for a sort of functional system of, like, can we get like, if we're building a web app, like, can we get it up at a URL? Like, what does that take? Right? It's it's it's the, that's the through line. It's, also been referred to as, like, a walking skeleton. Like, what's the, yeah, what's, like, the simplest thing that demonstrates, like, we've developed some code even if it is just a landing page and, like, deployed it and that thing is, you know, operational and has security things in place and whatever.
Oh, I like your mention of it being like a like a wireframe, like that, comparison or analogy. Because I think that's something that, a lot of partners can kinda, like, grok and get their heads around. Like, it's something you can usually see. But saying it's it's like that, but for these systems, may maybe that's, like, an effective way to to describe it to folks that are, like, less familiar, say, with the deployment process.
Yeah. I I had not really put that together before this conversation. But yeah. But yeah. I hope so.
Folks folks listening might be aware it can be rather difficult to try to prioritize, work in the DevSecOps space, especially if you have to weigh it against other concerns, whether you're talking about, like, you know, energy being put into, like, different features and things or, like, basically different competing things that are going on on a project. What approaches have you found effective in tackling that kind of problem?
For this, my mother would say, like, take my advice. I'm not using it. So it's something I wanna get better at. But an approach that, I've used and I've seen others use that seems to be really effective is, kind of playing amateur psychologist and figuring out what all the stakeholders' motivations are. Because then you can speak to those motivations or, you know, use that to influence your your decision making and avoid surprises and also, you know, get people on your side. So that might happen through, you know, finding their what their hopes are, what their frustrations are, what their fears are. Right? And this could be bosses, CIOs, like, you know, legislative, people, you know, who whoever might, like, impact the direction of the project. So if you can't address those things, right, then you're you're probably not gonna have an issue getting prioritized because they want you to succeed and they you know, this is good for them too. So, you know, earlier I mentioned, like, asking team members about things that annoy them or keep them up at night. The the way I did this with a couple clients is this exercise where we list out their, hopes and frustration and fears. I'd sort of get that through, like, doing one on one, interviews, but you could do it in a group, as well. So we sort of get those all up and, you know, combine them and and that kind of thing, and then map them to underlying problems. So okay. The the thing that keeps me up at night is, you know, what if our site goes down and there's no one to, you know, no one knows about it or something? Well, alright. The underlying problem is that we don't have proper monitoring in place, so we don't have a good, like, you know, fallback, you know, for system downtime and that kind of thing. Alright. Then we can come up with solutions, and that that in a way is easier once you identify the underlying problem. So with those, you can the team can prioritize and come up with, like, okay. What are the actual, like, problems we wanna solve, not just prioritizing the solutions? And, you know, if everyone agrees on that, then you you have your list and and that you know, you prioritize the things at the top. And you might need to choose whether, you know, fixing this potential security risk is more important than than a feature, but, you know, that's how priorities work. You have to deprioritize some things or prioritize others, and that's just something you have to accept.
And having those priority conversations, I imagine, can come into scenarios where there's a lot of noise around it. You know, sometimes there are the even potential, like, stakeholders that are prescriptive in their in their nature. I think I think of what that phrase is like, authority to operate kinds of requirements or, you know, processes and things that are can be a bit difficult to maneuver around. But we've also, in this conversation, talked about this, you know, wish to try to remain human centered and, like, how we go about designing these systems, implementing or designing and implementing policy. How can a team either kinda keep focus or return focus in these conversations to that, like, centering principle of, you know, trying to be human centered and also, like, maintaining things with these stakeholders.
Yeah. So there's a few ways to answer that, I think. One is to remember that the people involved in maybe Byzantine processes, they're people too. And, you know, maybe they're running it that way because they feel pressured to do so. And so, you know, it kind of goes both ways. So that that goes back to, you know, what I was talking about of, like, what are people's hopes and frustrations and fears and pressures? You know? Like, why are things the way they are? In order to, you know, address them, I'm gonna go back to, like, user research and usability tests. I, you know, was on teams where even as an engineer, I was, like, kind of brought in and, assisting, like, running these with, you know, UX professionals. And you just learn so much, watching people, like, try and struggle with the thing you built or the thing you're you're planning to build, that kind of thing. Yeah. Those practices, are thankfully becoming a lot more common, in government. I'm I'm sure beyond the government with, you know, external facing offerings, so, you know, sort of public facing products. But the same can be applied to internal systems and policies and processes. You know, this can be either, like, user research, which is often, like, done kind of beforehand, the usability testing, which is, you know, as you're building the thing, and, retrospectives, I think, are really helpful even just within the team to kinda get people to air their pains and and frustrations and that kind of thing and kinda help everyone work better together because you're not gonna get anything done if if people are fighting. So, you know, all those things can help you reflect on, like, what your medium and long term goals should be. Like, what are the user stories we're trying to address? Right? What are, like, the top line, like, problems and everything else, like, folds in under those? And then, you know, looking at okay. Our our tasks that we see on our project board or whatever, like, are those actually moving us towards those goals? If not, maybe we shouldn't do them. So last thing I'll say about it is, you know, in terms of treating everyone as a human, like, hammering on people to, like, you know, this has to be, like, directly related to this user. Otherwise, like, it's complete waste of time. That's not that's not a good way to approach things either. So there's actually a balance, and I I think it's healthy to give staff, like, time to work on things they want to work on. Just something they're excited about even if it doesn't, like, meet the, you know, threshold of, like, is this moving us closer to our, like, handful of top line goals? So this can be hackathons or 20 time, bug smash days, like, however you wanna do it. Giving them time to learn something new, experiment, you know, fix an annoyance, that kind of thing. It can be a nice relief.
That last bit you mentioned there, I, I I think something I'm hearing there is effectively, like, you can kinda almost go too far on the, like, the spectrum to a point where, like, you're too rigorous in the other direction, which sounds like maybe it creates some of the same sorts of stresses that the other end of the spectrum might have created, through that rigor. Is that is that is that so?
I think that's right. It's important to remember that, like, people are only gonna do their best work if they're happy. And a way that, like, a lot of people are going to kinda, you know, let off steam or maybe get to work with someone they don't normally get to work with or, you know, scratch an itch, like, that kind of thing. It's it's, like, give them a little bit of room to explore or to, you know, have some self determination. So that that's another way of thinking about it is, okay. Instead of, like, the stakeholders are dictating everything to us and we just have to do the the things that have been prioritized, I actually get some agency, and I get to pick something I wanna work on. And that that could just go a long way to to building up people's, you know, kinda trust in each other and, like, excitement about what they're doing and that kind of thing.
In some of your work, you you talk about this idea of trying to create a golden path that is kind of preferred for folks to use, but not something that's, you know, maybe explicitly required. You describe an idea that, probably seems familiar to folks who enjoyed their game theory classes. I know when I was reading this part of your work, I was having flashbacks to grad school about, like, the little the little charts and trying to figure out, you know, best perceived payout. But, ultimately, like, the idea is you you wanna make the desired behavior easier and more rewarding than the alternative thing that maybe you don't want them to do as much. What advice would you give folks that are trying to emulate the this model that you're you've described?
Yeah. And maybe I need to take a game theory class. I have not done that. But, the way I think about it is that, you know, people are going to there there's a gravity to whatever someone's trying to get done, and they're gonna find a whatever they need to do that. You as maybe a person offering a centralized platform, right, is is sort of the classic example, like running, like, the enterprise level tools. You want it to be the thing you're offering, but that's not always gonna be the case. People, you know, go off and use, like, shadow IT, right, which means kind of the things that aren't approved and, you know, aren't desirable to the people running the centralized things. So if you want to make your product desirable, I'd say that's half the battle, actually. Like, just getting people past the well, we said you are supposed to use it, so you have to use it. The end. If if you can get past that too, you know, okay. How do we actually make this, like, easy if not actually a pleasure to use? Just that mindset goes a huge a huge amount of the way. But, you know, so the the remaining bit of actually getting it there is, I think, treating it like a product and a product that, like, needs to win customers rather than having a sort of captive audience. So there's a great, blog post by Sean Boots, called, if you want enterprise services to be good, make them optional. And, you know, it it it's it's a really nice way of thinking about it of, you know, what what would it take to make this something that the target audience would would choose over alternatives versus, you know, being forced because forcing someone to use something is a losing battle. So, you know, you can you can look at look at the alternatives, look what else people are doing, and and figure out, like, okay. If there are people that are choosing not to use it or being resistant, like, why are they choosing to resist it? Can we can we go beyond just our ability to kind of lay down a rule of, you know, this is our enterprise policy and and entice them. So, like, someone might not be using it because they're not aware of it. They might have experience in whatever tool they're using right now, and they would have to, you know, do a bunch of learning in order to move over. There could be actual transition costs of, you know, okay. We have to migrate all this data, and, you know, that's a pain. And they could also, you know, have tried what you're using and not liked it. And so, you know, can you address those issues? To do all these things, it really, really helps to have your internal systems leverage people with, like, product and design and content experience. Right? Like, make documentation good. Make the make it visually appealing, right, as opposed to kind of the, you know, crappy internal software that we've all seen. And, yeah, like, how can you make it, like, alleviate their pain points so that, like, if they're on your side, they're excited to to use this thing and get feedback and all of that.
I I think I'm hearing in your answer there that a lot of the core of, like, figuring out this golden path idea comes back to, like, doing that effect, like, UX research that we've been talking about kinda throughout here. It kind of applies also just to, like, even trying to convince folks to use, like, their preferred set of tooling. Is that is that is that so?
Absolutely. I've gotten a ton out of working with, UX people and, got just the idea that, you know, you are you're trying to get something done. You meaning, like, your user in this case, is is trying to get something done. What are their options? Why are they choosing one versus another? What's you know, what do they wish they were able to do? What is, like, prevent preventing them, from being able to do it? That kind of thing. It it's applicable in so many places, and it really is, you know, so much about incentives and resources, and there's equity elements in there as well. Yeah. It it the the principles apply all over the place once you, like, start to learn about that, and I just love that.
If, if an organization's kind of found itself maybe, a bit into where shadow like, the shadow IT, like, as the phrase you used, is kind of already happening. You know, folks are already kinda finding ways to to do the task that aren't preferred by the organization or that they see as maybe inherently more risky. Are there are there ways that folks should attempt to kinda try to act to pull that back? Does it is it basically the same, like, you just go back and start doing that research at that time, or are there other things you might suggest folks do if it's, like, a little further along?
I think understanding what what people are using for what. Right? So can you sort of bucket the tools that people are using? And, like, ask yourselves as the, you know, maybe enterprise IT people, like, do we actually care? Like, like, how big of a deal is it that this team is using, you know, project management tool x and this team is using project man management tool y? Do we actually care? Well okay. Maybe that doesn't matter so much, but, like, we do wanna make sure people are using, like, a a safe email system. And so, like, let's make sure that everyone's using the right email system. And maybe instead of focusing on the tools, like, you know, okay. Why do we want everyone on a on the same tool? Well, we need to ensure that, like, data is being, like, shared and protected, safely. Okay. Can we kinda teach people just enough about that and that could be applicable to any of the tools? And would that go, like, most of the way? Maybe. You know? Can we if we if we, you know, have a principle of, like, we don't put sensitive information in our project management tool, that doesn't matter what project management tool they're using? Because, you know, if it gets hacked or something, like, it's not the end of the world. So there there's yeah. I I think it's useful for the centralized folks to sort of question, like, well, what do we actually care about, and and can we prioritize? Because trying to, like, set up walls around, like, what people can't do is is going to make people upset with you. And so let's prioritize what's gonna make the biggest impact in terms of, you know, cost savings or or security or that kind of thing. Focus on those and, you know, maybe decide we're we're okay with people doing things that are outside of, you know, kind of the centralized offerings and, just make sure that they understand the principles of, like, what is it that we're concerned about, and can they incorporate that into their day to day.
Aidan, thank you so much for joining us here on Civic Tech Chat. I have no doubt folks are gonna find some nuggets of wisdom to take into their day and learn from as they listen.
Thank you so much for having me. It's just fun.
You can follow us on Twitter using the handle at civic tech chat, visit us on the web at civictech.chat, or subscribe to us for content updates wherever it is you download your podcasts.
