Table of Contents
- • No silver bullets: Building the analytics flywheel
- • Identity Crisis: Navigating the Modern Data Organization
- • Scaling Knowledge > Scaling Bodies: Why dbt Labs is making the bet on a data literate organization
- • Down with 'data science'
- • Refactor your hiring process: a framework
- • Beyond the Box: Stop relying on your Black co-worker to help you build a diverse team
- • To All The Data Managers We've Loved Before
- • From Diverse "Humans of Data" to Data Dream "Teams"
- • From 100 spreadsheets to 100 data analysts: the story of dbt at Slido
- • New Data Role on the Block: Revenue Analytics
- • Data Paradox of the Growth-Stage Startup
- • Share. Empower. Repeat. Come learn about how to become a Meetup Organizer!
- • Keynote: How big is this wave?
- • Analytics Engineering Everywhere: Why in the Next Five Years Every Organization Will Adopt Analytics Engineering
- • The Future of Analytics is Polyglot
- • The modern data experience
- • Don't hire a data engineer...yet
- • Keynote: The Metrics System
- • This is just the beginning
- • The Future of Data Analytics
- • Coalesce After Party with Catalog & Cocktails
- • The Operational Data Warehouse: Reverse ETL, CDPs, and the future of data activation
- • Built It Once & Build It Right: Prototyping for Data Teams
- • Inclusive Design and dbt
- • Analytics Engineering for storytellers
- • When to ask for help: Modern advice for working with consultants in data and analytics
- • Smaller Black Boxes: Towards Modular Data Products
- • Optimizing query run time with materialization schedules
- • How dbt Enables Systems Engineering in Analytics
- • Operationalizing Column-Name Contracts with dbtplyr
- • Building On Top of dbt: Managing External Dependencies
- • Data as Engineering
- • Automating Ambiguity: Managing dynamic source data using dbt macros
- • Building a metadata ecosystem with dbt
- • Modeling event data at scale
- • Introducing the activity schema: data modeling with a single table
- • dbt in a data mesh world
- • Sharing the knowledge - joining dbt and "the Business" using Tāngata
- • Eat the data you have: Tracking core events in a cookieless world
- • Getting Meta About Metadata: Building Trustworthy Data Products Backed by dbt
- • Batch to Streaming in One Easy Step
- • dbt 101: Stories from real-life data practitioners + a live look at dbt
- • The Modern Data Stack: How Fivetran Operationalizes Data Transformations
- • Implementing and scaling dbt Core without engineers
- • dbt Core v1.0 Reveal ✨
- • Data Analytics in a Snowflake world
- • Firebolt Deep Dive - Next generation performance with dbt
- • The Endpoints are the Beginning: Using the dbt Cloud API to build a culture of data awareness
- • dbt, Notebooks and the modern data experience
- • You don’t need another database: A conversation with Reynold Xin (Databricks) and Drew Banin (dbt Labs)
- • Git for the rest of us
- • How to build a mature dbt project from scratch
- • Tailoring dbt's incremental_strategy to Artsy's data needs
- • Observability within dbt
- • The Call is Coming from Inside the Warehouse: Surviving Schema Changes with Automation
- • So You Think You Can DAG: Supporting data scientists with dbt packages
- • How to Prepare Data for a Product Analytics Platform
- • dbt for Financial Services: How to boost returns on your SQL pipelines using dbt, Databricks, and Delta Lake
- • Stay Calm and Query on: Root Cause Analysis for Your Data Pipelines
- • Upskilling from an Insights Analyst to an Analytics Engineer
- • Building an Open Source Data Stack
- • Trials and Tribulations of Incremental Models
When to ask for help: Modern advice for working with consultants in data and analytics
Analytics is changing and with it the role that consultants play is evolving too. Many people have a skewed understanding of what consultants are best at in the Modern Data Stack, and it’s time to address those misconceptions.
Learn what questions you should be asking before seeking out consultants, what a successful engagement should look like, and how to align your internal talent with external strengths that best serve your team. Let us show you how consultants can help push individual teams and the whole industry forward!
Browse this talk’s Slack archives #
The day-of-talk conversation is archived here in dbt Community Slack.
Not a member of the dbt Community yet? You can join here to view the Coalesce chat archives.
Full transcript #
[00:00:00] Barr Yaron: Hello, and thank you for joining us at Coalesce. Thank you. First of all, so much for your patience. My name is Barr I work on product here at dbt Labs. I’ll be the host of this session. I’m not always great at asking for help. So I’m really excited for this session. The title is When to Ask for Help: Modern Advice for Working with Consultants in Data and Analytics.
We’ll be hearing from Jacob Frackson, a senior consultant at Montreal Analytics, which is a dbt Labs partner. Jacob is passionate about transforming business questions into data. Having worked in data roles, ranging from data scientists to business intelligence analyst in 2022, Jacob wants to help companies better to find their talent needs and strategies to help data people better define their ideal role in place in those strategies.
First, some housekeeping, all the chat conversation is [00:01:00] taking place in the #coalesce-data-consultants channel of dbt Slack. If you’re not part of the chat you have time to join right now, visit our dbt Slack, and search for Coalesce data consultants when you enter.
I’m really excited to hear from Jacob, who I learned was the first person to submit a Coalesce talk proposal this year and last year and spoke both times. Jacob not only knows his stuff about data, but he loves advocating for information, architecture and skills matrices, and thinks the data space would be better with the way more.
The first midterm Jacob ever failed was in labor economics. And despite that it turned out to be one of his favorite subjects. If you want to learn even more, he will stick around at the end in our Slack channel to answer your questions. However, you’re encouraged to react and ask questions at any point in the channel.
Let’s get it started. I’m really excited for this. [00:02:00] Over to you, Jacob.
[00:02:06] Jacob Frackson: Great. Thank you, Barr. Okay. A couple of technical delays, but we’re here. We’re in, everything’s working glad to have this small Easter egg about the labor Economics course that I swear we’ll tie back to something that is relevant to the topic. But once again, thank you to all the team for helping us out with some of these technical hiccups.
And today we’re going to be talking about When to Ask for Help: Modern Advice for Working with Consultants in Data and Analytics. First, a bit about myself. My name’s Jacob. I use he/him pronouns and I work at a company called Montreal Analytics where I am a senior analytics engineering consultant.
At this company, I get to work on a lot of really interesting problems. I get to think a lot about information architecture, its role in modern data. I get to think about data ops and how to automate or simplify deployments and workflows and something that I’ve been thinking about. And something that I’ve been working on for about the [00:03:00] past year is what’s next in the modern data stack talent market.
And how can we participate in that as a consulting company also. Let’s talk a bit more about Montreal Analytics. What is Montreal Analytics? Well, we like to think of ourselves as similar to dbt Labs back when dbt Labs was Fishtown Analytics. We’re a Montreal born, but international aid, growing consulting company, a built up of data practitioners fresh from working in industry jobs.
We’re not career consultants, but rather we’re data people who have gone from contributing with a single company to contributing across many different companies. Even in my own experience, I started off as a BI analyst to some time as a data scientist, learn a few tips and tricks along the way. And now as a consultant, I get to specialize and really focus on what’s the best way of doing a migration.
[00:03:48] Where is data going? #
[00:03:48] Jacob Frackson: What’s the best way of doing a dbt implementation and make sure that we can transfer that to all of the clients that we get to. Okay. So to the meat of what we’re going to be talking about, and this is where the [00:04:00] economics comes in, where is data going? Let’s, let’s start off this talk by playing the role of data historian for a second.
Where are we today? Where were we yesterday and where are we going tomorrow? The core thing that I want to get across with this slide is that we have seen exponential growth in demand for modern data stack talent but only steady growth on the supply side. On the demand side, if any of you have been hiring for somebody in the modern data stack talent range, you probably haven’t experienced some of the difficulties within the past 12 to almost 24 months.
We’ve really seen a ballooning and explosion of demand when it comes to these type of roles. If you’re looking at analytics engineers, if you’re looking at the inclusion of even dbt and job descriptions, it’s becoming way more popular. And it’s really hidden an inflection point where it has far exceeded the supply of people who have that type of experience.
When we look at the modern data stack, when we look at technologies like Big Query, Snowflake, Firebolt, Databricks, etc., These are things that were popular at a point in time, but have really hidden inflection. The open [00:05:00] source and SAS quality of the modern data stack also lends well to people adopting it in a piecemeal way, which has also helped accelerate this.
It means that somebody can get started with dbt on Postgres and then move to Snowflake and then adopt Looker and then adopt Fivetran and they can do it as it fits their company. This means that new companies are adopting the modern data stack. It means that legacy companies are also shifting over what that means is there’s tons and tons of demand.
On the supply side? Well, actually way back, we actually had more supply than we had demand. There was all of the pioneers. You who might be in the audience today of people that were a part of dbt from when dbt was getting started, the people that were really interested in developing it as an open-source tool, people that were really interested in taking inspiration from software, software engineering, software best practices, and applying it to the work that was being done in data.
Unfortunately though there’s only a finite number of those pioneers, which means that when you look at the most senior talent, it’s a limited pool. We are doing lots [00:06:00] to expand the amount of junior talent that’s in the labor market. There’s really great projects going on, like the Analytics Engineering Club and the Founder program, etc.
But we do see that there is a bit of a pulling away of these two curves. Demand is outpacing. And in the future, hopefully they’ll curve back towards each other. But it’s a tough point to be at in this labor market. You know, this is an oversimplification, I’m showing you two lines and there’s, there’s many more lines if you look at specific roles.
But the one thing that I want to communicate with this is right now, it means that you should be getting the most out of the talent that you have access to because of the situation that we’re in. If you have a team, we want to make sure that you’re able to get the most out of your talent and the most out of external talent if you choose to.
And what you need to do that best is a well-informed count strategy. So in this talk, I have two goals. I want to first off equip decision-makers with everything you need to know to make good decisions about working with consultants. But the second thing, and the broader more general thing that I want to do is I want to give you a framework for thinking [00:07:00] about modern data stack talent, thinking about this constraint, the market that we’re in and thinking about how you can get the most out of your talent and your team.
[00:07:09] Consulting is not a fix-all #
[00:07:09] Jacob Frackson: One thing that I need to get out of the way first off that I want to make sure it’s super clear is that consulting is not a fix-all. I don’t want this to come off as a consulting is this panacea that we can apply to all of these different problems. No, as I was mentioning most of the team of Montreal Analytics has very limited experience with working as a consultant, but lots of experience with working with consultants. I’ve had great experience working with consultants, but I’ve also had bad experiences working with consultants and, you know, that’s par for the course.
Some of those bad experiences have made me a little bit skeptical and for a variety of reasons. Consultants in certain situations never really had enough context. Problems weren’t always well scoped to begin with and the consultant’s expertise wasn’t a good fit for our needs, what our internal team lacked. Also, we included consultants either too early or too late. We were setting ourselves up for failure. And then we were left [00:08:00] with a bill that was too high. All of this is to say there are good times to use consultants and there are bad times. Being able to identify the difference is key, being able to be aware of that is going to be fun.
[00:08:13] The Decision Maker’s Toolkit #
[00:08:13] Jacob Frackson: So let’s get into the meat of it. So today I’m going to be presenting you something that we’ve been working on for about the past year. Over the course of this past year, as I’ve been with Montreal Analytics, we’ve been trying to figure out exactly what some of these concepts are, what some of these tools, how people can think about their talent in a way that helps them identify good moments, bad moments, and where they might be lacking when it comes to their talent.
The first three concepts that I’m going to be discussing internal talent versus external talent, different types of business value, different types of solutions. Then there’s a tool that we’ve slowly been developing. It expands on buy versus build to include an element of design versus delegate.
And then lastly, there’s the disclaimer of when not to ask for help, just to make sure that we’ve dotted all over our i’s and crossed all of our [00:09:00] t’s. We’re also going to share a Medium post version of this tomorrow, just so that there’s something that’s a little bit easier to share if you want to talk about this, this framework with anybody across your team.
[00:09:10] Internal Talent vs. External Talent #
[00:09:10] Jacob Frackson: So I’ll be using a couple of examples as I explained this framework, but let’s dive into it. So our first component, our first component is internal talent versus external talent. This is our first column. If you’re only going to take one thing away from this slide know that these two are compliments and not substitutes internal talent exists as the core of your talent.
It is the first circle that exists and external talent is a circle that can be added to it, but it is dependent on that original internal talent. That is your team. If we look at internal talent, there are certain things that you’re trying to optimize for, because that’s what they’re doing. They’re great for building and keeping context.
They’re self managing to a degree and they’re great for product project and stakeholder management. When I think about hiring a new analytics engineer for one of our clients, for example, I want them to be a part [00:10:00] of all of the meetings. I want them to really be getting all of the information about the data that exists within the company, the needs of the data, and exactly what the data culture is like at that company.
This person is going to be a sink for all of that information. And that’s where you’re going to get a lot of value from that member of your team. External talent on the other hand is not well suited for that type of task. They’re great for multi technology experience, they will need internal teams support really to get a lot of that context.
And they’re great for specific expertise, especially once in a lifetime problems. Once in a lifetime problems is what we call once in a company’s lifetime. This might be a migration you’re moving from Redshift or Snowflake. It might be an implementation, you’re implementing dbt for the first time. These are things where reasonably you can’t expect your internal talent to have as much experience with that.
External talent is going to come in with certain areas that they excel in. Internal talent is also going to have areas that they excel in. And we want you to be thinking about these as complimentary, as having a symbiotic relationship between these two. They’re not the same. You shouldn’t [00:11:00] be treating them like this.
Okay. That’s a little bit high level. Let’s try and make that a little bit more applied. So we’ve got a couple of examples here. We have three different projects. Although this framework can also be used at the team level, I’m going to use the project level. It’s a little bit easier to understand. And we’ll walk through these three and I’ll apply them to each of the concepts.
So our first example is a Snowplow tracking project. Snowplow, ifyou’re not familiar with it, is an open source framework. It’s a variety of SDKs that allow you to do event tracking across your mobile app across your website. Ultimately, to get those events into your data warehouse, to then do dbt implementation. I hope you’re familiar with dbt.
Lastly, a dbt migration. In a dbt migration, you have a preexisting dbt project. You are moving it from in this example of Redshift to Snowflake. You want to make sure that everything works exactly as it does on Redshift once you’re on the system, but once you’re on Snowflake. Okay. So we have our examples.
Let’s walk through Hightouch and Packers into each one those. With Snowplow tracking, [00:12:00] this might actually be a project that’s best and great for internal talent. And this is because it’s really context rich work. When you think about designing those events, figuring out what’s the meaningful events to implement on your mobile app, on your website.
This is really going to be context rich. It’s going to be dependent on exactly how you deploy your mobile app, how you deploy your website. It’s something where it may be harder to onboard external talent to. External talent could help with some of the advising and some of the high level strategy for the project, but it’s harder for them to really own as much of it.
dbt implementation, on the other hand is something that’s a little bit more complex, and it depends on your team. A mix of both internal talent and external talent could actually be a great fit for a project like this. When you look at a dbt implementation, there are certain areas where external talent could help speed up the implementation, can help make sure you’re starting off on the right.
But depending on your internal talent, maybe you need more help in certain areas. Maybe you want to get a good introduction to incremental materializations. Maybe you want to have a good, [00:13:00] comprehensive introduction to snapshots. Maybe you want to have that kind of that kind of consulting help, that kind of external talent to help. This depends on your team.
Lastly, with the dbt migration, this could be a great example for an external talent dominant project. This is because it’s well scoped and more, once in a lifetime. If we compare it with Snowplow, there’s going to be a lot of questions. As you’re working through things that are going to be really context specific with a dbt migration, you have a great example to compare with. This is how Redshift works.
This is what the results of all of your transformations are on Snowflake. We want to replicate that we want to refactor as needed, and we want to be able to do that comparison. This is a great area for us to be able to compare that is something that could make it more appropriate for external talent. So that’s our first concept.
[00:13:46] Different types of business value #
[00:13:46] Jacob Frackson: That’s the concept of internal talent versus external talent. Our second concept is the concept of different types of business value. There are four main types of business value that are going to be delivered by your internal team or by an external team and it’s important to [00:14:00] recognize all four of them, even if they fall below the waterline.
So above the waterline, we have strategy and we have implementation. Strategy and implementation are often thought of as the lion’s share of the work. There’s the implementation once you actually have the direction. And then there’s the ins and outs of how you’re going to be implementing this project.
Most people assume this is where the meat is done or where the meat of it is. Below the waterline, however, we have project management and we also have enablement. So on the project management side, this is making sure that you’re properly understanding the dependencies, making sure that everything is as structured and, and aware in, in terms of the plan.
This is the scoping, sinking with stakeholders, tracking your progress, managing of dependencies below the waterline. There’s also enablement. There’s the ground up training on technologies. There’s the technical support and the code reviews. These are also important to the success of the project. We like to present it like this because across your internal team, maybe you have the right talent to [00:15:00] deliver on two of these or on three of these.
If you’re looking at strategy, maybe you have the right direction. If you’re looking at implementation, maybe you have the right direction, but perhaps on the enablement side, you don’t have the right resource for it. It’s important to be able to recognize what your internal team is able to do on the external side, external talent can also help with all four areas.
But once again, it’s going to depend a bit. So let’s, once again, apply those to our examples with Snowplow tracking. We can see how there are certain areas where it may make the most sense for external talent to be coming in, to help. As we saw with the first part, implementation might be a little bit context rich. Same thing when it comes to the project management. You may be spending too much time just trying to get up to speed. What this means is maybe that external talent could help mostly with the start and with the end, with the high level strategy as to how to implement it, how to design a good event. And on the enablement side, making sure that people are well-trained with the framework, well-trained with how to use these events now in dbt or in whatever is downstream.
On [00:16:00] the dbt implementation side, as we kind of saw what step one, this may be a mix depending on the team. Perhaps your team is really aware of the different kind of project management aspects of it. They have been starting to do their own enablement by taking the dbt Fundamental course but when it comes to the strategy and the implementation, maybe that’s where they could use the most help depending on your team.
There’s going to be a mix of needs. For the dbt migration, once again, it’s going to be a bit more skewed to one side. The strategy has already been chosen. In this example you are going to be moving from Redshift or Snowflake, so there’s not as much work to do there. There is the strategy in terms of how to implement that, but that may be a smaller side of this project.
The lion’s share of this external talent work is going to be the implementation project management, making sure that everything runs on time and possibly more. As we see kind of aligning with talent, there are different areas where this is going to skew different areas, where you can make sure to see this is how external talent could help with that project.[00:17:00]
[00:17:00] Different types of solutions #
[00:17:00] Jacob Frackson: So those are our first two concepts. Our last concept is different types of solutions. Different types of solutions is very important to mention as well, because this has implications for what you can do with your stack, but also the maintenance of that. This is a simplified way of looking at different types of solutions that helps emphasize the degree of customization that you get from different options, but also the cost of maintenance that’s associated with them. In the bottom right you can see it’s, you know, the least customizable option, but it has the best maintenance in the sense of very low maintenance costs. In the top left, it has the highest maintenance costs, but it is also the most customized. If I were to give you an example for this we can talk about extract and load.
So extract and load, there are great options that do almost everything for you with absolutely no maintenance. You just configure it and then it will run from there on out. If we use Fivetran as an example for that bottom right hand corner, the managed SAS option, you are not going to have all the support that you might be looking for.
They do [00:18:00] have a list of connectors that they have, and you will be in some ways restricted to that list of connectors, but you will be able to benefit from the perfect maintenance, the idea that it’s totally outsourced to them. If you have a totally different example for extract and load, and you have, for example, electronic health records, API that you need to work with, perhaps you need to self host it.
That’s going to be something where you’re starting to move up in towards the last. If you look at that type of situation, maybe you need to have it on your own infrastructure. Maybe it needs to be your own code. Maybe you don’t even want to use one of the open source frameworks, like the singer framework for the extract and load.
This is something where you’re getting more customization because you’re writing all the code yourself, but you’re also starting to incurmore maintenance costs. How does this factor in with talent strategies? This is important because you’re getting benefits, you’re speeding up the talent, the internal talent, but you are also now incurring a cost. You’re incurring the cost of being able to maintain and use this system going forward.
One thing that we make sure to highlight when working with some of our clients is [00:19:00] these, the different options need to be thought about as something that you are going to be inheriting in the future.
Sure. This may give you certain benefits, but if you work with external talent to implement a custom code self-managed solution that you’re never going to be able to manage, is that going to be setting yourselves up for success? When you look at different types of solutions, you have to be aware of the different costs that are going to be associated with it longterm and not just focus on the benefits that you may be maybe receiving in the short term.
Okay, so let’s apply this one as well. This one, it’s a little bit harder because we’re talking about it on the project level. This is often more appropriate when you’ve kind of taken a step back and you’re approaching extract and load. And the larger problem, because we’re talking about Snowplow specifically or dbt specifically, we’ve already kind of selected this solution, but there is an element to it.
So within Snowplow, there is the how to host it element, managed or self managed. When you look at managed versus self-managed, think about one side is going to be more customization, but incur [00:20:00] more maintenance costs. When it comes to the managed side of things, it’s going to be less maintenance, but maybe not as much customization.
And of course the cost of having it be managed by Snowplow. On the dbt implementation side, there’s a similar question when it comes to orchestrating it. Do you want to orchestrate it yourself? Do you want to spin up Airflow so that you can write your own DAGs and, and run it that way? Or are you going to use a provider like dbt Cloud to be able to have it execute?
dbt Cloud is going to be a more opinionated way of doing it. It’s also going to give you a very specific tooling, but it’s not necessarily going to be as easily baked into some other options that you would have with Airflow. In Airflow, you could have a DAG, that’s doing many different things, working with many different technologies.
Whereas right now, dbt Cloud may not facilitate that. Lastly, with our example of a dbt migration, well, unfortunately, this sounds not quite as applicable. Once again, we’ve already selected this solution. We’ve already selected the fact that we’re on to Snowflake. Snowflake is going to be more of a managed solution.
And it’s going to give you a lot of those [00:21:00] benefits as opposed to Redshift, which requires a bit more of that self management side of things, the tuning, the vacuuming, all of those things that you may be familiar with, but there are still some questions around infrastructures code for deployment. Here you might also want to be thinking about, do we want to invest in something like Terraform?
Do we want to use Terraform for deploying our Snowflake infrastructure? Is this something that your team is familiar with? Is your internal team ready to inherit this? Maybe, or maybe not? You should be thinking about this as a factor of your strategy and how it aligns with your talent. So those are our three concepts.
Those three concepts to us are foundational to the way that we try to get people to walk through their plans. And the way that they’re thinking about who it is that they have as a part of their internal team, what it is that they’re trying to deliver on and how it is that external talent might be able to help them.
[00:21:49] Buy vs Build, Design vs Delegate #
[00:21:49] Jacob Frackson: The last tool that we’ve been working on developing is a way of visualizing that for our different clients. Hopefully you’re familiar with buy versus build. Buy versus build is the [00:22:00] communication of, are you going to internalize costs and have it on the build side of things, or are you going to externalize costs and have those man hours to have the working hours to be pushed over to the buy side of things?
This could be coming in the form of paying for SAS. So you’re just having a solution off the shelf, or this could be paying to have external talent implemented. That’s a great way of looking at it, but we find sometimes it’s a little bit overly simplistic. One element that we like to add to this question, to this access is another access for design versus delegate, which is all about expertise.
If buy versus build is about the cost, design versus delegate is about internalizing expertise and designing it yourself, doing the research that may be needed to do this note file tracking implementation, or are you going to delegate that experience and delegate the design of this to some external expertise, somebody who has much more experience with this, somebody who is not going to have to research on it and on whom you can depend for their experience with doing something like a [00:23:00] migration.
If we look at these three examples, we can see just as we saw in the tables before that they’re naturally falling in different areas. Depending on your team though, these dot placements are just an example. So let’s talk about Snowplow tracking implementation. We saw that based on its context rich quality, it’s based on the needs of the internal team to be involved so that they can maintain it in the future.
It may make the most sense for you to do a lot of the research and for you to do a lot of the building. That’s not to say that somebody else might place this dot in a different place. Somebody else might actually want to have some more external expertise. They may want to have some more delegated design.
This could be beneficial because they’re going to make sure that you were advised and you start off on the right foot. This is just one example of where you might be placing. If we move on to the dbt implementation example, we can also see a bit of the opinionated placement of the dot. You know, right now we’re depending, mostly on internal time.
Internal time is what we’re going to use to write most of the code, [00:24:00] but we’re actually leaning more on external expertise than on internal expertise when it comes to what models to be writing first, when it comes to how to implement incremental this is going to be something that will depend on the consultants and will depend on the external talent.
This is one way of doing it. You could easily see this falling below the line and falling into the bottom left hand corner. And in the bottom left hand quadrant, this is one placement for the dot that could work well for your team. Lastly, with our example of the migration from Redshift or Snowflake, we can see that with this example, it may make the most sense to fully or as much as possible externalize both the cost and the expertise.
When it comes to implementing this migration from Redshift or Snowflake, you’re looking at your internal team and you’re saying this would be best if we could if we could shift it over and have the team, this would be best if we could shift it over and have the external talent, do all of the work for us.
With this particular implementation, when we look at the buy versus build framework we would want to be able to have external talent, use their hours for this, to [00:25:00] preserve the internal talent so that they can keep working on the other systems that are in place. Once again, these are just three placements.
If you think about another project that you might be working on, you could see it falling right in the middle. You could see it falling in the top right hand quadrant, top left, bottom left bottom right. What we’re trying to introduce with this is just multiple aspects. There’s expertise, which is often underrated.
And then there’s also costs. Think about the different talent costs that might be related to a placement of the point in the top left or in the bottom right of this particular chart.
[00:25:34] When not to ask for help #
[00:25:34] Jacob Frackson: Okay. So what we’ve covered. We’ve covered our first three concepts. We’ve covered our tool. And now the last thing a bit of disclaimer for thinking about this framework is when not to ask for help. When we’re talking about this, all of that may sound really great. But if you aren’t being honest with yourself about the internal team that you have, the internal direction, you may still be setting yourself up for failure if you’re thinking about including external talent too soon, or [00:26:00] without consensus.
Three of the questions that we encourage people to ask themselves and ask across their teams are the following. Who will support the consultants and who has the context. This is making sure that you have internal talent that is mature enough to support external.
If you just hired an analytics engineer and that analytics engineer is fresh in the role, they’ve just been there for a couple of months. Maybe there are certain things that you need to do before starting to bring on external talent. You want to make sure that that person is able to support external talent.
This is thinking about that pseudo Venn diagram from our first concept who will benefit from the stack and who is asking for data. This is thinking about data and its role across the organization. We’ve been really zooming in on our concepts as to what it is that talent is going to be doing and how it is that talent is comprised.
But talent only matters in so far as it’s serving a larger purpose across the organization. You have to have a strong direction in this sense, you have to make sure you know who those stakeholders are, so that we can work iteratively in an agile way and make sure that we’re delivering the [00:27:00] proper amount of value as it’s been done.
And then lastly, who will be inheriting the stack. This is a question that we have talked about a little bit with solutions and that we’ve talked about with the types of business value as well. We want to make sure that we’re working within a system that is appropriate for that team and appropriate for that teams.
We don’t want to be implementing parts of the stack that are skewed to one side, that are skewed to a particular type of experience. We want to be implementing it in such a way that it is appropriate for those that will be inheriting it. Internal talent should be augmented by external talent. They shouldn’t start becoming a growing into a dependent relationship on one another.
And lastly, to conclude. So at the beginning, we started off by talking about things from a macro level. We were talking about the labor market and kind of the way that we’re seeing the labor market changing. What I’m really trying to get across with these slides is that talent is tight and that you should be getting the most out of it by being as intentional [00:28:00] as you can, with your strategy.
The two things that I want to leave you with on this, on this slider, that talent is changing in more ways than one. We’re seeing, especially as roles change in popularity, it’s important to think about talent in multi-dimensional ways. Is this person good at writing code a stakeholder in information management, visualization and analysis, etc.
When you know the strengths and weaknesses of your team in that detailed of a way, it’s much easier to see work consultants could lead head. The other side of this is that solution architecture and thoughtfully designed stacks make more of a difference than ever having the right team, but also having the right building blocks will ensure you can make as much progress and impact as possible. Lacking the right talent and lacking the right solution architecture are two of the biggest challenges modern data teams. When we introduced this framework, we’re trying to give you the tools to think a little bit more comprehensively about that. I hope this helps you avoid the [00:29:00] pitfalls and get the most out of working with consultants. Thank you.
Last modified on: Oct 11, 2022