Like all good things, building a data team is a combo of nailing the right people, processes, and technology. When I first joined Netlify, I was building mostly from scratch with some signed contracts in place. One of the first items on my list was bringing in some of the technology core to the Modern Data Stack that was not yet in place. The very first: dbt Core and dbt Cloud. In fact, I think I had been at Netlify for less than 5 days when we `dbt init dbt` in our data team’s repo. That dbt project no longer exists (We migrated from Databricks to Snowflake), but it was the first of many forays bringing the Modern Data Stack into Netlify.
When I talk to first-time data leaders or single-person data teams, they often gripe about how hard it is to do this. Bringing in an open source project like dbt Core? Not that hard. As a technical leader, you’re the maintainer of your repos and you get to decide what technology makes the cut. Buying technology, though, can be much harder, especially if you’ve never done it before.
In many ways, it’s actually easier to bring new software into a larger company where there are clear processes. As a manager cog in the BigCo machine, bringing in new software can be as simple (not easy) as getting the right signoffs, signature, and budget approved. In a smaller organization, where no one has “Procurement” in their job title, it can feel nearly impossible to navigate a purchase- like you’re trying to get a destination with no map- because, well, that’s exactly what you’re trying to do.
If you’re trying to buy your first piece of software, what follows is my recommendation on how to get it over the line. I can’t give you the map to your organization’s process, but you can borrow from my learnings to help sketch out what your next steps look like and hopefully make it easier for the next leader in your organization.
For growing companies, getting things done is just as much about making sure everyone’s on the same page about what the problem is as it is about figuring out how to solve the problem.
Understanding how to bring a new tool into your organization is an exercise in figuring out who to work with and how to work within your organization. As data leaders, we often sit at intersections- between product and marketing, between sales and engineering- but purchasing is always at the intersection, and figuring out how to navigate it means figuring out who is in the car with you. Anticipate what your partners need as part of this process and deliver on it so it’s easier for all parties involved.
Just because you can’t find the “Purchase Form Checklist” in your organization’s SOP folder on Google Drive, doesn’t mean we need to go right to reinventing the wheel. Ask your peers and managers if they know what the steps are for bringing in a new tool or technology. Your manager is your ally so don’t be afraid to ask for what you need to be successful.
Bringing in dbt Core to Netlify was going to allow the data team to work more effectively by centralizing transformation, testing, documentation, and monitoring in one tool; and dbt Cloud was the quickest way to deploy our dbt Project with CI/CD and orchestrate our jobs without additional infrastructure resources from any other teams from the organization.
It was incredibly important to be able to justify the business impact, including cost savings, business efficiency, and possible alternatives. When discussing business impact, it’s important to be pragmatic over optimistic. Don’t only plot out the happy path! Think about the best, most likely, and worst cases. Cost isn’t just about dollars and cents; consider people hours that will be spent, including dependencies on other teams.
Nothing is coming into your company without sign off from security and finance stakeholders.
First, security: understand what your security person needs from the vendor in order to consider them. You are the one making an ask of your security team, so go above and beyond to answer their questions and help them understand why they should greenlight the tool you’re interested in. Consider creating a one-pager specific to the security team that answers the following questions:
Second, finance: to get your finance team on board, you are best served speaking your finance team’s language. Like with your security team, consider a one-pager specific to finance answering the following questions:
Do not pay sticker price off the bat. Unpopular but I said it. Ask every vendor for a better deal. You will never get a better deal if you don’t ask for it.
If they can’t budge on price, can they offer additional support? Will they send your team some swag? Can you sign a multi-year contract? Will they offer tiered pricing? Companies have discount matrixes that mean that they can almost always offer something. Ask for it.
Discounts often have a ticking clock on them. Once you’ve got the right sign-offs, move quickly. Check-in on signatures hourly. Enthusiasm can fade, but your pain point won’t. Try to move through the process in a timely fashion. In the same way that a vendor is selling software to you, you’re selling it to within your organization.
Congratulations on closing your first purchase! Welcome to management! This is the first of many. Now that you’ve elucidated some sort of process in your organization, I suggest documenting what you did in a way that aligns with how your organization works. For example, you can create an issue template in your project management tool that aligns called “New Tool Review.” It doesn’t have to be perfect! Going from nothing to something will make it much easier for the next person.
I’ve said it before and I’ll say it again: tools are not the end-all, be-all. No amount of tooling will change a culture. But tooling that works for you and aligns with your goals can be a game-changer to any organization.