5 less-known ways to manage dependencies in the workplace
This one comes out a lot. “I need something done from team Y over there, and they’re busy. They say they’ve added it to their roadmap, but it looks like a couple of weeks before they even get started on the work. How do I get them to build what I need for my customers?”
This results in backlog persuasion battles, or worse, super complicated models to help teams prioritise work. That’s when it happens. We ship something we’re not super proud of. And because we learn that adding more work to (that other team) results in weeks if not months more of waiting, we give up. We don’t do it. We ship work that’s lower value while we wait for others to come through. And sometimes they don’t. Other urgent issues popped up. How can we ever win like this.
Well, you can’t. You’re solving for the company instead of solving for the customer.
This doesn’t just happen between software teams. It’s the product manager that’s waiting on brand to approve copy. Or the designer that’s waiting on final screenshots to update the store description. Or the campaign that’s waiting on legal to review. But ultimately it’s the customer that’s waiting on all of it to make sense.
So what can you do?
- Create a Pull Request. Our engineer friends have figured this one out a long time ago. If you have work that you need pushed in another team, have a way to create a pull request. A pull request is a collection of actual work, that the receiving team reviews and agrees to merge if the review is positive. With engineers, this means code. But the same principle applies to other work types. There’s a challenge with this approach. You’re not an expert. Stay with me. That’s ok. That’s right – it’s ok. You’re not an expert, and that’s ok. As part of reviewing a piece of work the other team will help you through the distinctions. Most of the work we do around here doesn’t need Super-A player expertise to do or a degree in mathematics. If it does, then we need to rethink hiring. Most of the work only needs good enough understanding of the domain. It doesn’t take a computer science degree to change the copy on a page, or a user experience degree to suggest an change to how a screen works. It doesn’t. Do the work, create a pull request, and learn from the integration process.
- No fixed teams. No big stories. Every functional silo will default to optimising for things they know how to do. Doing non-default things feels awkward. Doesn’t feel like work. So if you’re a technical person, you default to go deeper into the details of the code and find a problem worth solving. Or if you’re a designer, you start taking issue with some part of the flow that’s not perfect yet. Or if you’re a product manager, you find a roadmap for your product. That’s how backlogs get filled. Those things are probably true and worth doing. But they might not be the big rocks. What if, instead of filling your backlog with stuff inside your comfort zone, you were to leave the current team, whose people and assignments only change once in a blue moon, and you were to join another team and swarm towards the next big rock. What if, and here’s the real kicker, everyone else around you did this too. Crazy right? Changing teams every week, certainly that causes other problems right? Let me cut to the chase. It does cause other problems, but the key thing is this – all of those are company problems, not customer problems. Solve for the customer. You can mitigate most of them by keeping your stories small (1–3 days) and owning outcomes instead of outputs (e.g. customer metrics instead of released features). Swarm teams, and do it often. Do it around the most important customer problems, instead of product lines. Even if that’s uncomfortable. Especially if that’s uncomfortable. The first time you do it, you won’t have knowledge of the system, the people you’ll be working with are not the ones you’re used to, and it will feel awkward. Learning always does.
- Optimise for response time. Inevitably some people are experts at stuff. It might be a developer that knows a piece of code closely, or a product person that has been involved with the customer from the very beginning. The problem here is that most companies optimise for usage, as opposed to response time. Let me use an analogy. Fire extinguishers and fire trucks. Fire extinguishers are a quick way to decentralise command. Giving everyone basic training on how to use a fire extinguisher ensures that situations don’t get out of control should they emerge. For that effect, there’s a lot of them spread throughout the building. You’re ok with that, because even tough it costs more, it also makes everyone safer. On the other hand, fire trucks are scarce resources. It wouldn’t be ok to have a fire truck in every part of the building. So you have only one. You store it away until it’s needed. That makes sense. The exception being, that when it’s needed, you turn on the lights and make it so the fire truck is actually able to take priority over normal traffic and get to the fire on time. The same should apply to experts. Companies have a tendency to optimise for utilisation, so when the expert is busy doing something else, there’s no lights turned on, no precedence over normal work and the result is lots of hot emotions flaring around, teams waiting and fires escalating. When you have an expert, and you do, by all means have him occupied with other things. But when he is required to work, accept that it’s hands of the keyboard, turn the lights on and come help.
- Codify your SOPs. So if experts are the equivalent of the fire truck, what’s the equivalent for fire extinguishers. The equivalent is SOPs. SOPs stands for “standard operating procedures”. They’re the list of steps people follow to do things. Checklists and stuff. So - you have an expert. And she does expert things. That’s great. But is everything this expert does a result of innovation? Or maybe, just maybe, there are parts of her work, that given enough consideration, could be codified in a template. Again, our friends the engineers lead by example here. Back in the day, developers and operations used to hate working together. Why? Developers handed off badly put together code that ended up in the hands of an operations person that was responsible for deploying it to production, at four o clock in the morning. Inevitably, things went wrong, and developers blamed operations (“works in my machine”) and operations blamed development (“you didn’t specify all the configurations needed, your code kept crashing and I couldn’t know why”). So what did they do? They codified their SOPs. From setting up each environment, to installing dependencies, to configuring every variable, installing code, to running the service, everything was written down in a way that was reproducible. They then went the extra mile and made a computer understand those instructions, and now most of the work is actually automated away completely (read more about it, devops). What’s the lesson? Codify your SOPs. Sounds laborious? It isn’t. First, think about them like fire extinguishers (cost of operation < cost of incident). Second, don’t overthink it. Grab a wiki page, and the next time you need the experts help, ask her to document what she’s doing. The next time it happens have someone else follow the instructions while pairing with the expert and fine tune. After a couple of iterations, revisit and check if a) you’re having success and b) you can automate away part of it. More importantly, don’t apply this only to developers or software. Apply it to designers, marketing, sales, legal and more.
- Provide a services and data contract. One key reason dependencies occur is that there’s hard coupling between the service/data provided and the thing we do. Mmm that sounded jargonish, let me try again. If every time you needed to change the wallpaper on your phone, you’d need to disassemble and assemble the phone itself, you’d change wallpapers once or likely never. But you don’t. You can change it without affecting the rest of the system. And because it’s easy, you do it more often. The lesson here is that the same enablement is possible between teams. You might have to build it, or design the way you work thinking about it, but it’s certainly possible. E.g. Maybe it’s developers making all product copy available in a google spreadsheet that automatically gets imported with every build. Or product that enables marketing to change the copy and run ab tests with all push notifications and emails that get sent to customers. Or a terms and conditions section that uses an external URL instead of hard coded conditions. When depended on, find ways to decouple. Build or buy, doesn’t matter. Unrelated note, tools like segment.io abstract the service and data contracts of tracking user events and properties in each product to great success. Unaffiliated, check them out, they’re great.
- Or just, you know, don’t do it. This stuff is hard. One can have a million ideas, turn them into brilliant experiences, only to ship a three legged chair. So this can be an argument of values. You can say – I don’t ship things that don’t work. Not because of some epic love for the craft, but because customers really hate it when we do that. I have a rule for not wanting to do something, you have to have done it three times perfectly. Not half assed, not doing just enough and grumbling all the way, but really committed (even tough you disagree). Three times. Only then – you’ll have built both the necessary distinctions about why things are working like that in the first place and gained the capital of trust to say “you know boss, I’ve been thinking, what if we…”. Do it three times well (not well, perfect) Gather the facts, tell us (the team) a story. Don’t show up with problems, but suggest a solution (maybe even one you tried) and capitalise on your track record for knowing what you’re talking about to get things changed.
That’s it. Dependencies are organisational bugs. Its either skill or priorities. Defining it as a capacity issue encourages solving for the company. Having a dependency means you, not others, have to do the extra work. That’s how you take extreme ownership for the result. Don’t solve for the company. Solve for the customer.
Got a second? If you found the above interesting, and would like to know more about this, just drop me an email at rcclerigo [at] gmail [dot] com. I’m here to help.
You can also hit the applause button and follow me here, on Medium.