When I was at Microsoft, there was always tremendous tremendous pressure to depend on the work of other teams in building your product. And in general that makes a lot of sense: after all, if you can do less work and get a better and more capable product, that’s a good thing.
The problem was, that sometimes it worked well and sometimes it didn’t. Sometimes other teams delivered what they had promised, more or less on schedule. Other times, they delivered something very different from what was promised, and/or it was very late.
This also happened with to other kinds of dependencies: vendors, software platforms, partners, development tools, you name it. As you can imagine, this was very frustrating, and I wanted to figure out a way to tell in advance whether depending on someone else was a good idea or a bad one. I finally figured it out.
I call it the Law of Dependency Management:
Never depend on someone else for something critical unless they are equally or more screwed if something goes wrong.
Of course, this is just a fancy way of saying “make sure your goals are aligned,” but it’s actually a stronger statement, and it puts the focus on the negative outcome, which is where it belongs in this case. (And in truth, there should be a caveat at the end: “…unless you absolutely have no choice.”)
Let’s look at some examples:
- Non-critical functionality. Non-critical things are different. By definition, you can live without them, even if you’re not happy about it.
- Vendors. Generally speaking, if you check references and perform other due diligence on a vendor, this is a safe bet, because their reputation is harmed if they don’t deliver. But what if you’re just a little guy and they are a huge company? Watch out.
- Partners. These go wrong all the time because people often think about the companies in the partnership and the “synergy” between them, not the products, software code, or people involved. If you think about the failure case, that gives a better idea of how motivated the two companies are to succeed: credibility and revenue are powerful motivators; old press releases are not.
- Open source projects and software platforms. One of the things I look at when considering an open source or platform dependency is who else is using it. Are they using it for the same things? Are they using it for mission-critical things? If your mission-critical dependency is everyone else’s “nice to have” dependency, watch out.
The takeaway? Dependencies are not bad. Far from it: that’s how you get the leverage you need to succeed and scale in business. But consider what happens if things don’t go as planned: if who or what you’re depending on isn’t as negatively impacted as you would be, watch out.
Tweet this: @bill_bliss New post: Don’t Get Screwed by Dependencies http://wp.me/p1pkik-64 #prodmgmt