Delivering feedback that lands
Build vs Buy and Deconstructing monoliths
 |
Hey everyone! This has been a busy week! I'm glad to announce I decided to join the Bridge team as a Backend Engineer - which means lots of great challenges ahead. Even though it wasn't planning on working this year, joining a small startup working on a great product (at least I think so) really sparked my interested, so I decided to join. Not to mention I get to work with Ben Bennitt again! Thanks for the referral, Ben!
Article of the week
This article is a summary of what I found most useful on the topic of feedback. I hope it can be helpful for new managers (or experienced ones) looking to improve their feedback game.
I wrote it about 2 moths ago but it never made it into the newsletter. To be honest, I was a little nervous publishing it as I've seen so many very smart people also writing about feedback. I thought I should link to it anyway, and find out what people think. I'm looking forward to your feedback on my feedback article! (meta feedback?)
Delivering feedback that lands →
Build vs Buy
I’ve faced this dilemma 83 times in the past year.
The (not always applied) consensus is, organizations should only outsource or buy software that isn't strategic to their businesses. That makes sense. Companies should be working and iterating on software that provides them the most leverage until they get it absolutely right.
My beef with that is, it’s not always clear what software components are “strategic”.
That's where the Wardley mapping method comes in. I found that Wardley maps helps organizations to identify what can be bought.
It all seem to be as simple as: strategic software can't be bought. If any software components give you an advantage, it has to be built in house. If it can be purchased off the shelf, your competitors could buy the same software, and the advantage would no longer exists.
Yet, one could argue that all software is strategic for the business, only on different levels. Value is created by the overall system, which includes core and auxiliary software.
Let's use Uber for example. They absolutely had to build their own app to match drivers and riders - that gave them a significant advantage over the taxi industry. But they bought Zendesk as a customer support tool. The business impact of building their own CS tool would be low - but certainly not insignificant. A great CS tool allows a company to provide excellent service to their customers at scale, which isn't a negligible advantage. So, when their internal economies of scale allowed, Uber replaced Zendesk with their own custom-made solution.
So organizations should build the software that has a high impact in creating their competitive advantage. For everything else, prioritize buying what makes sense, while it makes sense (see below) and build the rest.
If a software component isn't high impact for the business, I fall back to a "should I buy?" decision criteria very well described by Will Larson:
Risk. Vendors get acquired, change pricing, get hacked, or simply go bankrupt. If no vendors offer an acceptable level of risk, we simply can't move forward. Build it is.
Cost. On top of the financial costs (currently and projected contract prices), factor in the integration (upfront costs, before value creation), operation (mandatory upgrades, dealing with outages and degradations), and evolution (future use cases the vendor might not support).
Value. Estimate the value a vendor provides by comparing their offer to what you'd be willing to build. Remember to include infrastructure, maintenance and opportunity costs.
After the Cost and Value estimation are done, compare the two and go with what makes most sense. Will makes one very interesting addendum:
"I've found that many companies are quite bad at vendor management and are quite good at building things. As such, their calculations always show that vendors are worse than building it themselves, and that's probably true for them in their current state."
Links of the week
Shopify has recently published two articles about the process to deconstruct their monolithic Ruby on Rails application. Their technical plans are impressive - kudos to the Shopify team. What caught my eye was the magnitude of their efforts. They mentioned they've been working on it for 3 years, and Shopify has a team of 1500+ engineers. Of course they don't have their entire workforce on this project, but their internal scale allow them to throw significant resources at it.
Rails is a great tool for quickly getting a product to market, iterate on features and quickly pivot until product-market fit is found. However, as much as DHH likes his monoliths, I believe product-market fit is the time when companies should start thinking about their current and future scalability needs. That's when teams should take a long, hard look at their monoliths and start thinking about how they will re-architecture for scale. The more they wait, the larger the effort will be.
As a last note, if you know someone who would be interested in the contents of my emails, I would be super thankful if you shared 🙇🏻♂️ - just hit the Share button below.
That’s it for this week! As always, I hope y’all have a great weekend, and I’ll see you again next Friday.
Create your profile
Only paying subscribers can comment on this post
Check your email
For your security, we need to re-authenticate you.
Click the link we sent to , or click here to log in.