Hello and thanks in advance for reading Lessons in Engineering Leadership! Thank you to the 3,685 of you who have subscribed. Please share with your friends!
If you’re new here, Lessons in Engineering Leadership is a weekly newsletter covering a variety of engineering leadership topics that can be read in under 5 minutes.
If you find value in these newsletters and would like to support this publication, you can become a paid subscriber.
I’m glad you’re here!
Some personal news: I will be running my first-ever marathon at the 2024 Bank of America Chicago Marathon on October 13, 2024! I am raising $5,000 for St. Jude Children’s Research Hospital to support their important mission and research and I would be honored to have your support. Make a donation here. I’m now almost two-thirds to my goal! Thank you so much for your support.
The great Build vs. Buy debate
If you’ve worked in engineering for any reasonable amount of time, there’s a very strong chance you’ve encountered a build vs. buy scenario. For the lucky or for those who have no idea what I’m talking about, the question is straightforward: do we build this software in-house, or do we use a third party software product? The answer, however, is anything but straightforward.
We all encounter this scenario several times in our career, and every time this scenario needs to be considered with care. This week I’m presenting my rough framework for discussing build vs. buy with your team and stakeholders. As in, you don’t make this decision on your own. As in, PLEASE involve everyone necessary to make a decision.
1. Assess needs and goals.
Define your specific requirements, long-term goals, and constraints. The problem statement needs to be super clear; there shouldn’t be any confusion around what you’re trying to accomplish and why. Use this as an opportunity to evaluate if existing solutions meet most of your needs. You should be especially careful here to leave any bias out of your assessment. I’ve seen on several occasions a clear bias for a particular solution.
Determine the level of customization needed. Can an off-the-shelf solution be tailored to your needs, or will attempting to customize an off-the-shelf solution result in greater debt than it would to just build it from the ground up?
Also evaluate scalability - how well does the solution accommodate future growth? Outside of the cost implications outlined below, how might this solution scale from 500 to 5,000 to 50,000 to 500,000 customers using it?
Don’t think just in the short-term either; consider the future roadmap of the software and how updates, enhancements, and support would play into this in the long run.
Lastly, assess the urgency of deployment and how quickly you need the solution. Obviously buying an existing solution will often result in an earlier delivery time, but at what cost? There’s always the option to buy now to build later, so consider a short- and long-term delivery timeline here.
2. Run a cost-benefit analysis.
Calculate the total cost of ownership for both options: initial purchase/build costs, maintenance, support, and scalability. If you were to build, how many engineers are required to architect and develop the solution? How about to support it thereafter? Beyond the cost and time of engineers, what about hosting and server costs?
If buying, how much is the solution now, and how much will the solution be down the road? You can often swing a discount in your first year, but what about the following years? How much do you expect the cost to increase as usage scales? Consider potential savings in time, resources, and future updates as well. I also tend to think about who built the software we’re considering. What’s the stability status of their company? Are they an early-stage startup or more mature? I take serious consideration towards using a product that’s still in its infancy, especially if it’s going to be supporting a core function of our own software.
3. Assess the technical experience of your team.
This one also falls in line with overall costs and timeline. Needing to pick up a new skill means a longer delivery timeline to build and support, especially if it’s a large enough feature requiring the involvement of multiple engineers.
There’s also a learning curve for adopting an existing technology. If building on top of someone else’s solution, what is the expected ramp time to feel fully comfortable supporting the technology?
—
This is a simple framework, but these questions cover a lot of ground. I always encourage my team when evaluating potential software solutions to dig and find several “buy” options to eliminate some bias and ensure proper research has been done. The engineer in charge of this then presents to the key stakeholders to discuss the pros and cons of each option, ultimately ending with a general conclusion on build vs. buy. These live review sessions are incredibly useful as you’ll get questions you weren’t thinking about.
I end this newsletter with two final points:
Don’t fall into the trap of “buy, then build” and never actually get around to building. Commit to a build date and make sure it remains on the calendar. It’s helpful when you’re signing a fixed contract for a service (e.g. 1 year) so you can use that deadline minus 1 month for some wiggle room as your build launch date.
If you don’t agree with the decision made, disagree and commit. If you build and you were urging to buy and it turns out buying was the better option, don’t say “I told you so” – it’s not beneficial. Just move on and move forward as a team.
What I’m reading
I haven’t been reading for a little while as I’m still getting caught up on work so I’m still reading Wiring the Winning Organization by Gene Kim and Steven J. Spear.
Check out the full book list for recommendations and an ever-growing reading list.
Note: Links to books in this section are affiliate links to help support the purchase of the rest of my books :)
What I’m working on
End of year is among us, so between closing out projects, planning for Q1, and getting together an organizational plan for our new IT organization, I have my hands very full!
If this email was forwarded to you, be sure to subscribe to receive weekly emails in your inbox that can be read in under 5 minutes!
Thanks for a good article that outlines an approach and some guidance on how to make this decision.
A couple other considerations that I've found important:
- Is this a strategic capability? If it's core to your business, you may value owning the intellectual property or the ability for the solution to evolve as your business evolves. Those may cause you to lean more toward "Build". If you need it to meet payroll or something else that is important but not a competitive advantage, you may lean toward "Buy".
- Are your requirements flexible? It's likely that no "buy" solution will meet your requirements exactly, but if you have the ability to change your requirements to match the capabilities of an existing solution, you'll require fewer customizations and lower support costs for the "buy" solution in the long run.