388: Empowering Other Departments Within a Company

Joël has a bike shorts update; Stephanie has a garden one. Often, power is centralized within the dev team. This is usually because they are the only ones able to execute. Sometimes this ends up interfering with team processes and workload. Joël is a fan of empowering other teams to do things themselves. Strangler Fig Pattern What Being a Staff Developer Means at Shopify by Rose Wiegley End-User Programming Transcript: STEPHANIE: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Stephanie Minn. JOËL: And I'm Joël Quenneville. And together, we're here to share a bit of what we've learned along the way. STEPHANIE: So, Joël, what's new in your world? JOËL: So, in a recent episode, I had mentioned that I was going to go on vacation on a bike trip and that I had purchased a pair of bike shorts to try out on that trip to see if that would help. And, wow, that was a great purchase. It literally saved my butt. STEPHANIE: That's awesome. I'm really glad that they worked out for you. JOËL: Still sore. This was a five-day biking trip. And I think day two was the worst, but after that, things got better. But the shorts definitely helped. STEPHANIE: I think my favorite part about us talking about biking and bike shorts is that we're finally living up to the name of our podcast. [laughs] Turns out that bikeshedding is actually even more, bikeshedding when it's about actual bike stuff. And a listener named James even wrote in with some pro tips about, you know, how to care for your bike shorts and, you know, have a comfortable biking experience. And gave some good tips for me on some longer rides to check out near me in Chicago. JOËL: So it sounds like there's some crossover between the software developer community and bike enthusiasts community who also tune into this podcast. STEPHANIE: I do think that we have gotten tweets before from, I think, like, the motorcycle Twitter tagging us @_bikeshed, perhaps maybe trying to tag a different account but, yeah, ended up in our Twitter inbox instead. JOËL: Now we just need some sweet, sweet bicycle sponsorships. So, Stephanie, what's been new in your world? STEPHANIE: I have a garden update. Last year, we purchased a small fig tree from the internet. It turns out that you can get little fruit trees delivered to your door. And this was, I think, around the fall, so it was getting a little cooler. And here in Chicago, we have to bring some of our plants inside to overwinter. And so we brought the fig indoors, and it's maybe, like, two or three feet tall. And, you know, over the few months, we were just, like, caring for it. And I was really excited to see that it had started fruiting several months ago. And I got to show it to all of my co-workers in a call. I, like, picked up this kind of large pot with our little fig tree, and I, like, held it really close to my camera and tried to point out the fruit to the other people on the call, which I realized was perhaps not a very effective way to show off my plants. Like, you could just take a picture and send it in Slack. And I was like, yes, I could have done that. But yesterday (Now our fig tree has been outside for a little while since it's warmer.) I noticed that they were ripe, and I got to harvest our figs and eat them, and they were delicious. And I got to update the team on my little fig adventure. And this time I did take pictures of the fruits and sent them in Slack instead of trying to bring this tree in from the outdoors. JOËL: That's exciting. Because I'm a fan of the design pattern, I have to ask, is this a strangler fig? STEPHANIE: It's not a strangler fig, though I have seen one in the wild on a trip to Florida. I saw a really big strangler fig, you know, completely, like, enveloping another tree, and that was really cool. If you ever get to see one in person, I think it's just, I don't know, just really amazing how nature works. JOËL: I did not realize they were wild in Florida, something to keep an eye out for next time I'm there. STEPHANIE: Definitely. So, in a recent retro on my client team, we were discussing the one-off requests our team has been getting from the folks over on the sales and client support side. Oftentimes, this involved running a script in our production console to fix some issue that a customer was experiencing. And we were talking about what we could do to make this process a little more automated, make it a little less time-consuming on our end. Even though it would just take a few minutes to run this script, we were seeing that we were getting this request repeatedly. I'm curious if you've kind of been in this situation before where dev work is required and kind of eating into time that we are trying to be delivering on other feature work for similar one-off requests or to support other folks at the company. JOËL: Yeah. I think it's a pretty common pattern that I've seen. And I think sometimes it can actually start from a healthy place. If you're taking very much of an MVP philosophy and you're building a small version of your product to start with, you're not going to have a whole suite of admin tools available. You might not even have any admin people. It might just be a founder and a technical co-founder. And so, for the first few hundred customers you have, maybe the way you make changes is by loading up the Rails production console and making a change. And that's good enough, but that doesn't scale. STEPHANIE: Yeah. You bring up a good point that I think one thing that we get to experience as consultants is seeing many different companies at different stages in their business. And I think I've seen this issue in many different iterations based on the size of the company, right? So you were saying for an MVP product, there's no admin support at all. Maybe you have a project that is now thinking of how to introduce a little bit of admin tooling and might reach for something lightweight like a gem. I've also seen custom admin dashboards, and that being its own namespace and having all of that feature set hand-rolled, and then maybe some other company might opt for a Software as a Service solution. JOËL: Yeah, there's a lot of different implementations that happen at various stages of companies. I think one thing that does seem to stay pretty constant, though, is oftentimes; other teams don't have the tools they need to make the changes they need to. So, if you have a customer service person and they're receiving a complaint or they're having to make a change, they're not always empowered to make the changes they need to. They need to talk to the dev team, who then need to make changes. And the dev team don't really want to spend their day doing admin work. They are incentivized to ship features. And so both sides are unhappy. And it kind of comes from a sort of fundamental, I think, over-empowering of the dev team and kind of a disempowering of some of the other departments within the company, if that makes sense. STEPHANIE: Yeah, that's interesting because I don't think it necessarily is intentional, the way that that happens, right? It's not like you start building a product, and you are saying, "Okay, we only want to give devs the power to change all of this stuff at the production level." It's just something inherent, I suppose, to the work that we do. And there's a lot of active effort that needs to be taken to spread some of that empowerment around. JOËL: Yeah, generally, it is not some sort of, like, nefarious corporate politics that's happening where the CTO is, like, hoarding all the power, or it's a turf war or anything like that. Like you said, it's kind of an emergent property. As developers, we're often used to being sort of ultra-empowered to do what needs to be done. In general, development teams are highly respected within companies, and so people listen to them. But also, in order to do their job, they need to have access to a lot of things. So you often have production access to all the things and the admin credentials. And if there's something that doesn't work, you write code, and you can change the sort of fundamental underlying platform that you're working with. And so you're generally empowered to make the changes you need to make your life better or if you're blocked on something. And that's not necessarily true for other departments who are working in the system that we're building. STEPHANIE: Yeah, it's kind of interesting the duality that you have identified where we do have all of this power or capability to change the system. But you had mentioned earlier that sometimes it actually gets in the way of our work, that it can be a drag to do if we have other competing priorities, and that those mundane tasks end up being something that we also don't enjoy doing. And so, like you're saying, like, no one is quite happy. I wonder at what point you, as a developer, having repeatedly been asked to do these kinds of tasks for other departments when you, would start advocating for building tooling. JOËL: I don't think there's a kind of a clear dividing line, like, oh, after three requests, you must build a dashboard. It's probably more about just general communication with the other teams. I like to think of it from kind of two perspectives. From the perspective of the developers, how can we keep them efficiently working on what they need to prioritize, which is typically new feature development? And then, from the perspective of other teams, how can they be empowered to do the work that you need to do without getting blocked? Because just like the dev team doesn't like to get blocked on all sorts of things, other teams don't like it either. And so, how can we make sure that other team members within the company are empowered to do their work as efficiently as possible? STEPHANIE: Yeah, that's interesting. I think as an IC, I've been in different positions, depending on the context of my work. There have been times when I've been happy to help with that kind of request, right? Because I know that I'm unblocking someone else. I'm facilitating their work. And they usually appreciate it too. And so maybe if that's still the case and that there's not necessarily any pain that comes with that being just the process that it is from both sides, like, that's perfectly fine. But then it's totally fair for, you know, either party, once they do feel like it's blocking other work, to start looking into maybe how much time you're spending on these one-off requests, especially if it's being spread around to other team members. You know how much effort you're making, but, like, a manager might actually be more aware of how it's affecting multiple folks on the team and wanting to figure out, like, how that sits in with the other priorities that the team is working on. JOËL: Yeah, I'm glad you mentioned talking to other people because I might be quite happy to say, "Oh, I'm going to go and, you know, go into the database and make a small change." But just because it's easy for me to do and I can take, you know, 10 minutes out of my day to do it, doesn't mean that that experience is good for, let's say, a customer service person who had to get blocked or had to ask someone else to help to move this ticket forward. When if it was something they could do themselves, that would have been a much better experience. So, even though it's a very fairly, you know, cheap request and because I don't get them a lot, I'm happy to do them, it's maybe not a good experience for my customer service colleague. So, like you said, it is important to get people's experiences on all sides. STEPHANIE: One thing that I have seen a lot is for these things to start as configuration in a YAML file that requires developers to change and then commit to the codebase whenever, you know, maybe it's, like, a list of products or a list of prices, something that is, you know, really the business domain. And yet we are hard coding it and, like, codifying it into our source control. JOËL: Oof, yes. I have been in those projects, yeah. Now, every time you want to make a change, a business person has to reach out to the dev team, and then you have to make a code change, and then you have to deploy it. And that just becomes a whole thing. And then they come back to you the next day and say, "Oh, actually, we talked about it, and we want it a little bit differently." And you have to go through that process again. STEPHANIE: I think we reach for that just because we think it's faster maybe to set up, you know, some kind of, like, lightweight configuration file, rather than if you're working in Rails, you know, setting up a whole MVC for whatever thing you're trying to configure. And I'm curious if you think that's true or not. JOËL: I think it depends. Sometimes it can be because this data feels very static, kind of hard-coded. And so it's not a thing you would necessarily want to have. In a database, it's more like a constant that you would have in your source control, except that then you find out that your constant is not quite as constant as you thought it was. And I think maybe that's okay. Writing software is all about kind of discovering the problem in the domain as it evolves and trying to not over-engineer things ahead of time. So, if we have a small set of values, maybe they're U.S. states that you deliver to or a small list of products or something that you feel is relatively hard coded, maybe it starts as a constant array hard coded into Ruby, maybe it is a YAML file that you load. Then, over time, there comes a point where you decide this should be a database table, and if it needs to be sort of pre-seeded, then there's a mechanism for that with database seeds in Rails. STEPHANIE: Yeah, that's fair. I find it so interesting because most of the time, I've not seen that transition happen, right? It almost feels like some form of the bystander effect where everyone is just, well, I'm adding just one more thing. So I don't want to make this really big change now. JOËL: And that's true for everything in code, right? You say, "Oh, this deeply nested condition, yeah, it should probably be restructured. But I'm just going to add, you know, an eighth nested level in there. And, like, eight is probably the limit, but mine is going to be the eighth, so it's going to be good." And then somebody comes in and says, "Well, you know, nine is not that bad, but the next person probably should refactor it." And then it's a mess. STEPHANIE: Yeah, it's kind of like the entropy of code, I suppose, [laughs] where, you know, we had said it requires a lot of active energy and effort to make those changes to support other folks in different departments of the company. And I think that's, like, one very common area that we see things starting as configuration but then end up being something that you are needing to support in changing. And I wonder if maybe that is a signal in itself, right? If you are getting this information from another team, like, someone external to the development team, I wonder if that's kind of a clue that this is something that should be reconsidered about whether you start with it being hard-coded. JOËL: That's an interesting thought. There's a sense in which I think these always come from places external to the development team because it's a form of kind of product research when you're trying to understand what the features need to be, what this needs to happen. Unless this hard-coded data is purely structural or internal values, but it rarely is. There probably is a broader discussion to be had about the use of any sort of hard-coded data in a configuration file in a Rails app versus just always starting with a database table. One thing that's nice about always having a database table is that if you ever need to connect it to other data in your system, now you can do things like table joins, where you can't join your users on some kind of YAML array, or you have to do some sort of Ruby Enumerable logic. You can't just do it in SQL. STEPHANIE: Yeah. This is a bit of a tangent, I think. But that reminds me of when I worked at a product company where we had a very robust data warehouse, and all of that information was available to teams on the marketing side and on the data science side. And I actually really liked that because they were able to, you know, construct their own dashboards and queries to get the things that they need. And I've certainly seen what you're saying, this pretty important business information being hard-coded, and that ends up being less accessible, right? And less insightful, really. One other area of this topic that I think I've also bumped into before is specifically a QA engineer or, like, a QA team and empowering them to be able to do their jobs. Oftentimes, I've noticed that QA environments are not as well-maintained as maybe they should be, where the data that's seeded or, you know, kind of overtime in this environment is a little wonky. I've also experienced, while working on a feature, kind of having to go back and forth between whoever is helping QA my work telling them, like, "Oh, this isn't finished yet. So, like, don't worry about this that you're testing," or, you know, "Actually, that does look wrong. But let me look into it over on this end." And I found it sometimes difficult to navigate because I want them to be more empowered to test their feature without that uncertainty over whether something is intentional or actually broken. JOËL: In this case, do you think it's more about communication between development and QA, clear acceptance criteria, or clear descriptions of what changes have been pushed up for review and what's not in scope? Is that where you're headed? STEPHANIE: I think that's a part of it. But I actually think there are more technical considerations, especially in terms of whether our environments all align in terms of the data we're expecting, right? Does our dev environment kind of look like our QA environment, which looks like our production environment? Because I've certainly been in projects where that's, like, all over the place, and that really messes up the different expectations we have. We all know the "Oh, it worked in my local" [laughs] response to when things come up in other environments that are unexpected. And I wonder if there is more attention that we should be having towards making sure that just because this environment is not the main one that we're working in as developers, that people who are having to use it have an equally good user experience. JOËL: I like that you brought up the term user experience because oftentimes, as developers, and just, I think, product teams in general, we're trying to make something good for the customers of the application. But there are a lot of other people that have to interact with it in sort of more ancillary roles; like you mentioned, it might be QA. It might be customer support. It might be business development. And they're not the customer. And so because of that, they're often kind of a second thought or even sort of no thought at all. And so they do their jobs as best they can with what they've got, and sometimes get really creative getting around some of the hurdles that are in place. But we can often, with very little effort because the bar is so low, make these people's lives a lot better by applying just a little bit of the same approach that we would use to make software great for a customer to use for teammates in these other roles. STEPHANIE: Yeah, absolutely. Especially because we have that line of communication open with them, and, like you said, they are also our users of our applications. And especially for QA folks, too, in some ways, they're the first line of defense of our users, right? They are a resource for us to know if the customers will eventually have a poor experience or not. And I was thinking about that back-and-forth communication I mentioned with QA, you know, trying to explain, like, oh, this isn't finished yet, so maybe, like, you should not expect this to happen. But, oftentimes, that perhaps is a signal that we haven't thought about the way that we're developing our feature to be able to be released to customers in a more incremental way. Or we might be hand-waving over something that ends up being a bug later on. JOËL: Definitely. For myself, I see that as a... code smell is maybe not the right term here, but maybe acceptance criteria smell. If I'm trying to write out some acceptance criteria, and I'm having to say, like, "Oh, but, like, ignore this, and, like, pretend this doesn't exist. All of these, like, weird edge cases and exceptions we're trying to put in, are oftentimes a sign that maybe the work was not scoped correctly. STEPHANIE: I'm curious, in your workflow, will you just make those improvements if you have the opportunity to? Or do you end up bringing that to the team or creating a ticket for it? How does that fit in when you identify areas that could be improved? JOËL: I think it depends on the team's current workload. Oftentimes, if it's just something small, it's something I can just slip into my day, and it makes somebody else's life easier, that's great. Otherwise, it can be a thing that needs to be brought up with the team in general. And then it's the thing that we prioritize, and we put it in the backlog because, like you said, the main users of our app are customers. But all of these other teammates are also users of our app in other ways, and so they need certain features to get their job done. And so it's worthwhile to, I think, at a product planning level, take those into account and prioritize them with the customer-facing things. And sometimes, because those other teams don't have as much of a voice at the table, it's up to us as developers because we sometimes have that direct communication where we're talking to them and sort of going back and forth about, "Oh, can you change this in the database for me?" or "Can you do this?" And it can be up to us to champion these other teammates' needs with the team and with the product organization in general. STEPHANIE: Yeah, I really like the way you put that. I think you used the word champion. And I've seen this also go the other direction, where we add more processes in place, where the direct communication that needs to be gatekept a little bit through a manager because the manager is trying to protect the time of the team. And that is one way to handle the issue of these requests taking too much of the team's time. But I think at some point, as an IC, you also have the agency to champion or advocate for how you use your own development time. And that reminds me of something I heard from Rose Wiegley over at Shopify about what it means to be, like, a staff or a senior developer, and that is sharing that I'm going to do this, and this is why. And that means that I won't have time to do this other thing that I may be committed to earlier. But you know, these are my reasons. And if anyone sees any problems with that, let me know. And I've been thinking about that a lot in terms of figuring out how to do the kind of work that I value. And for you and me, that does sometimes mean building those tools to empower people who aren't developers. But that is, yeah, just a way that we can assert a little bit of that agency rather than having to get the buy-in to even consider setting time aside for that work. JOËL: Yeah, I think some of the really fulfilling work that I've done has been just sometimes taking a morning and, quote, unquote, "pairing" with, like, a business development or a customer service person and just saying, "Hey, can I just sit with you while you process this kind of request or problem that you're trying to do?" And then just really seeing what they do and all the steps and being able to ask a lot of questions and kind of putting my product developer hat on. And because then I know, internally, all the things that are happening, I can quickly see, oh, okay, you're- having to do these, like, five steps to get around this really annoying thing that's just, like, a rough corner that we have that I can, like, just easily smooth the way, you know, with a 10-minute one-line fix. I'm going to go and do that, and, you know, by the afternoon, that's already done, and that's saved them so much time or so much annoyance because it's not always time. Sometimes it's just annoyance. And their life is better. And I put very little effort into it. Most of it is just taking the time just to talk to each other and to try to understand each other. So I think we brought up the idea in the beginning of trying to empower other teams to not sort of centralize all the ability to execute on change within the development team. And sometimes, you can go to fairly extreme lengths to that. One that I've seen is the idea of end-user programming or end-user development, where the using the software rather than the team developing it has some sort of way where they can sort of customize or build on, or sometimes even script or -code -their experience. Is that something you've ever had to deal with or interact with on a project? STEPHANIE: Yeah, it's really interesting that you brought that up because I had mentioned going with a SaaS solution earlier as something that I've seen before. And that reminds me of when I worked on a client project where we were using Freshsales to integrate with the business domain of the client. And this would eventually be the main software that the sales team would use. And the reason that we went with Freshsales was because it allowed for a lot of that custom configuration and workflows that they could create for themselves for their needs. Though ironically, as we were kind of butting up into the limitations of Freshsales and how it didn't necessarily work for the way we were representing our data, we kind of joked that we almost wished we had to build the tool from scratch ourselves. So I think there are trade-offs there, you know, folks had done a lot of research to figure out the right SaaS solution for this project that we were doing. And yet, you know, inevitably, like, there were some cons with the third-party and how we were able to integrate with it. And it was actually also replacing something that had been built in-house and had become difficult to maintain or something that the company decided that they didn't want to maintain anymore. So I hate to say it, but I really think it [laughs] depends. JOËL: And now you're getting into the classic build versus buy dilemma for chunks of your software. STEPHANIE: Yeah, absolutely. JOËL: I think a way that I've seen, and this happens in a kind of a smaller sense, is providing escape hatches for data. And so maybe you've got a couple of small dashboards, or you've got just a lot of things that happen in your system. And you don't have the development time, or you don't want to prioritize that time right now to build something custom for maybe your business development team. But you provide certain reports that can be exported as CSV or Excel, which then the business development team will load into Excel and do the work that they need. And now they're empowered to do what they want instead of having to ask for more information or just being limited to what was on that web UI. Similarly, sometimes, when you're able to Import a CSV, I've seen this happen a lot, where in software that's not built just right for a customer service team, they'll often export a CSV of data, put it into Excel, manipulate it the way they really want it to be, and then re-import it into the system. And so that can be a great way to temporarily empower people. I think it's also a product smell. Oftentimes, there's a fundamental flaw of the way that your product works because your team is trying to go around it. It's so bad. But as a shorter-term solution, that can be great. STEPHANIE: That makes me think that Excel is the real end-user programming software. JOËL: It really is. It really is. I do really like the idea of end-user Programming, though. And rather than developers or even product people having to decide how our software should work for our users, shifting that to the masses and letting them have all of that empowerment and agency that we're talking about. There's a technology research lab called Ink & Switch, and they build a lot of really cool end-user programming tools. I think I've seen some, like, note-taking software, that they've done, and just other research into why it's important and how it can impact users. And I have read a little bit of their work, and I think it's really cool. So I'll be sure to add that to our show notes. JOËL: I think even as developers, we like some of these ideas of end-user development. We have that a lot in our tooling. But then, even when we interact with other people's software that we don't own...because we're used to interacting with our own software, we own it. We can change anything we want. We've got complete freedom. But the moment we interact with somebody else's software and, of course, it doesn't work 100% the way we need it to, it is sometimes nice to have sort of ways to hook into it so that we can get the things we want and then maybe do some extra manipulation on our own. And APIs are often how we do that. And so the equivalent of providing an API for another developer, well, what is that for our other teams? STEPHANIE: Yeah, great questions to consider. JOËL: You know, it could be a CSV export. It could be maybe there's some easy way to connect to a Zapier plugin. And now, you know, they don't need to ask the dev team, "Oh, we want to receive this notification email internally when this event happens. They can just connect to a Zapier plugin and have it send an email or do something in Salesforce or all these other things that are helpful in their workflows but that we've not taken the time to build into the core software. And now they're empowered to do their work and not blocked on us. STEPHANIE: That's interesting because as you were talking about that, it made me think of development tooling that we get to integrate with and how those APIs are usually very flexible. And let us decide what we need and ask the API for that as opposed to it dictating it for us. And, you know, if that's something that we get to enjoy, then, yeah, we should certainly think about how you can spread that to others. JOËL: I love that. On that note, shall we wrap up? STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at [email protected] via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeeee!!!!!!!! ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.Support The Bike Shed