Patterns for being a successful internal data consultancy with Dylan Jones - Episode #51

Welcome to the Agile Data Podcast, where we talk about the merging of agile and data ways of working in a simply magical way. Welcome to the Agile Data Podcast. I'm Shane Gibson.

And I'm Dylan Jones.

Hey Dylan, thanks for coming on the show. Today we're going to talk about this idea that there are data consultants out in the world and they're the type of people that you help to build their consultancy. But I'm particularly interested in this idea that when you are working in an organization, say full-time employee, this art of consultancy is actually still important. Selling to your organization what you and your team do, how you do it, the value you deliver, and some of those consulting practices and patterns that we see are really useful for internal teams. So that's kind of the thing I want to chat about today. Before we do that, why don't you just give us a bit of background about yourself?

Sure. Yeah, I guess I started around about '93, started out as a software engineer, quickly moved into data. Pretty much straight away, first role. Yeah, shifted from software engineering into data engineering for an organization doing really cutting-edge work at the time. It was predictive analytics, like back in the '90s, which was unheard of everywhere else, and still some of the most sophisticated and forward-thinking work I've been involved in. Learned all the foundations there, and then quickly went freelance after a couple of years. And then that took me to, yeah, so based in the UK originally, then went over to Australia, headed up a technical manager of a large managed funds organization. So I ended up at the department there in terms of the technical side, came back to the UK, ended up working for a large consultancy. I just got the bug for launching my own firm. I guess went through the same trials and tribulations everyone else does. It's hard at first. Stumbled on blogging. This was late 2000s and things took off from there. Really caught the wave at the right time in terms of the blogging and building my own kind of personal brand, as we would call it now, personal data brand. Did that for a few years. And then what started happening was a lot of big vendors, companies like SaaS and Experian, other vendors started reaching out and saying, hey, can you create content for us? Can you help us figure out the content marketing thing? And so did that for a few years and then still with my hat and doing the data consultancy as well. But then eventually consultancies started asking me if I had a program, could I help them systematize, I guess, inbound lead generation? Because a lot of consultancies were struggling to, and I guess a lot of consultancies still are struggling to predictively attract clients. A lot of doing outbound and getting mixed results these days, but a lot of companies really struggling with the inbound as well. I built a program around about 2015 to predictively bringing inbound lead acquisition. That was the goal. And that's pretty much what I do today. Still do a bit of data consultancy, but the focus is on the MyDataBrand business, which is basically helps data consultancies and some software vendors systematize their inbound client generation.

I always have a joke that there's two projects you should never do, payroll and data migration. And And the reason is when you are infinitely successful, everybody goes, oh, that worked. And then every other time something goes wrong. So you actually spent a lot of your time when you were a consultant in the data migration, data quality space, didn't you?

Yeah. So I got really lucky. My very first role, I've learned probably 80% of the fundamentals, I think, around data management. The first role was really around moving data and having not just like good quality data, but just phenomenal data quality. Because if we had the data quality wrong in the first organization, because it was predictive analytics, We would be putting things like car dealerships in the North Sea. There was just nowhere to hide. The data quality had to be absolutely flawless to a standard I've probably never seen elsewhere since. So I learned the fundamentals there. When I got to 2006 and I wanted to launch my own consultancy, I just couldn't really decide which horse to back. So in hindsight, it was the wrong move, but I essentially backed two horses, datamigrationpro.com and dataqualitypro.com. And the idea I had was if I build a community for each one of those areas, I'm pretty much hedging my bets. They both will be big enough for me to drive business. And that ended up being true. In hindsight, I should probably just pick one, but both are successful. They helped me elevate my brand globally. It sounds a little bit pretentious when you say it, but I would basically connect and reach out to people all over the world who had the same problem. They wanted to figure out data migration. They wanted to figure out data quality at a time I think both of those disciplines, late 2000s, were really starting to pick up as defined things. Before the mid-noughties, they weren't really a thing. I think technology helped as well. Data migration technology, ETL technology, and data quality technology suddenly started to become a bit more sophisticated, I think, towards the end of the noughties. So yeah, I built frameworks and training and products as well, but mostly just services. And got lucky working with some fantastic companies in the UK and some overseas as well. Those were the two core focuses I had, migration and quality.

If we look at that pattern of blogging, we know that if you're a data consultant or you've got a consultancy company, writing articles, writing blogs, showing your expertise, helping people solve their problems, sharing is a valuable technique. It's hard. There's a concept of a long tail. You need to spend a lot of time over a long period of time to be successful at it. It's not a one and done. But with some of the organizations I've worked with, I've seen the idea of internal blogs. I've seen an idea of data leads or CIOs or the data team writing blogs internally around the work they're doing, the things they've delivered, some of the business problems they've solved, and also using it as a way of increasing data fluency in an organization. If somebody was in an organization and they were like, yeah, actually this idea of an internal blog is something I want to experiment. What are the tips and tricks for starting your journey in blogging? People typically try to overbake it. They try to boil the ocean. So they'll try and craft the most beautiful article that you've ever read. It'll be massively long, 16 peer review processes, take 6 months for that one article to come out. And for me, that's a form of an anti-pattern. But how do you see it? If you were recommending to people internally to start this process, what would you say they start with?

You're absolutely right. I'm seeing far more people these days apply the concepts of content marketing internally because they realize, you know, if they want to reach a bigger audience and have bigger impact and basically demonstrate the value that their unit has, they have to market internally just like a consultancy would. I think fundamentally you have to understand the audience, right? Within, within the framework, I've got the My Data Brand framework. The first thing we focus on is positioning. So you have to do the positioning work first of all. And one of the first things we do is this exercise called building the asset vault. And the asset vault is like profiling the projects you've done to identify what was the pain, what was the agitation, and what was the kind of solution and outcome that you delivered. The wrong type of content, I think, to start off with is content that just goes into the mechanics of data. So for example, yes, if you're in a modern kind of data team, perhaps you're working under the Chief Data Office, yes, you could talk about the benefits of analytics or the benefits of governance and things like this. But I go back to one of the most powerful pieces of content you can create is a really simple case study of this was the problem we had, this was the agitation it caused for the organization, this was the solution we came up with, written in a way that is relevant for the audience you're pitching to. So if you're writing for, let's say, a chief finance officer or a CMO or CRO, CSO, something like that, it's going to be very different compared to if you're writing for someone in the data bubble. If it's a data analytics person writing for a data analytics person, then yeah, you can get into Databricks and Snowflake, Hadoop, or you can go as detailed as you want, but you have to be really mindful of the audience. So if you look at the core structure, should really be, hey, look, we saw this problem, it was agitating the business in this way. You really get into the emotion of the agitation. Then you talk about the solution in a way that's relevant for that audience. Then you talk about the outcome, and then you talk about, this is what we would like you to do next, action. So that PSOA framework is like a universal copywriting framework that's been applied for 50, 60, 70 years, going back to the Mad Men met in Type Era and beyond. And it's because it works. I definitely think the starting point should be, if you have had success, just focus on that success, because you almost want to create this like fear of missing out. So this is one of the things I've done in previous organizations, where we've had an outcome that's been really positive, we focus on, okay, who else needs to know about this? Because if we've done something really cool with analytics, or we've done something cool with data quality, we've reduced lead times, then people want to know about that. We want to tag it to things that other people might be measured on. Lots of different departments in an organization will be measured lead time performance and cost reduction and things like that. So I think, yeah, a great piece of content is always just a simple case study written in the language that is going to resonate with that target audience.

I agree. And I like that idea of bubbles. So if I think about it, these three natural bubbles in an organization that you can talk to. So one is your stakeholders. And like you said, you've got case studies, you've got access to information in your organization that no external consultancy has. So you just write a case study. We got asked by the head of marketing to identify the customers that were leaving us. We built a thing called a churn model and maybe a short description in business language of what a churn model is for people who don't understand. Identified people that are about to leave. This is the action they took. They went and did a save campaign. The outcome they got from that was they stopped 10% of our customers from churning. The value of that was articulated at around about $5 million. Your stakeholders are going to love you because you've actually delivered something for them. Quick quote from them because that actually helps reinforce the message. And that's it. If you want to see how to do it, go look at any vendor's webpage where they've got a case study and find a good format of that and replicate that internally. And what that will do, it builds your brand as a team. People would no longer say, what do the data team do? It helps people find you. So make sure you've got your team's name on it. They can come and contact you and say, hey, we've got this problem. Can you solve it? Stakeholders, definitely one of the key people we should be talking to internally with our internal blogs.

I think you've hit upon a really good idea as well. Within the framework I teach, we have this exercise. Again, it's all part of this project profiling, building the asset vault. You want to try and tell those compelling stories. You're absolutely right. Once you learn those kind of case study formulas, you can reuse those over and over again. And I've taught it to clients where they'll use it in a sales situation, but they'll use it at a conference and then they'll use it in an internal pitch. Again, you've got that problem, agitation, solution, outcome, action. One of the exercises we go through is like when we're building case studies specifically, they're going to be on like a sales page. So if we extend that a little bit more, we want to start the story with people and end with people. So The framework there is that you've got people, they have some kind of problem. When we talk about people, we're talking about stakeholders primarily. They all either have a problem they have and don't want, or they have an aspirational goal they want and don't have. So it's like things they have and don't want, or things they want and don't have. You may be in a different department, but we generally want the same things. We want to reduce lead time, we want to bring costs down, we want to increase revenue, profit, whatever. So we got the people, we got the problems. And then the key bit I think a lot of people ignore is like the pull. So you've got people and problem, and then you have pull. Like, why were you pulled onto that project? And I think it's a nice subtle point within the case study that you get to show off a little bit. You get to blow your own trumpet and explain, we were pulled in to solve this problem because we have these unique set of skills. It's like the Liam Neeson things that we have, these unique set of skills that make me uniquely capable of solving this specific problem. And that's going to create the pull. Then you go through the payoff. And I like to split the payoff in terms of, What was the payoff for the company? And then what was the payoff for the stakeholders? And that gives us that nice kind of bookend from, we started with the pain and frustration of the stakeholders, and you can go to whatever level you want in that. You can start with a CMO had this problem, but her team had this problem. And you can drill down and then you wrap up with, hey, and it was great for the company because we reduced lead times or increased revenue or whatever, we met regulatory controls. But what's really cool was for the stakeholders and their team, they boosted morale, they were able to hit their targets. So It's like that Hollywood thing where we start with the pain and frustration and we end with the payoff and the happy ending. You're absolutely right. It's using that kind of classic case study framework as a wrapper for your content.

I'm a great fan of Kat Greenbook's data storytelling framework, and she talks about and, but, therefore. And so again, bring that into your case studies, bring in the but, bring in the hard thing. We wanted to do this, but the data wasn't in the right quality, so we had to clean it. And I go back to the key outcomes. For me, there's only 3. Increase revenue, decrease expenses, decrease risk. Everything can be tied back to that. So again, when you're doing those case studies, think about which one of those is the most important and coalesce around it. So you've got case studies about increasing revenue, case studies about decreasing expenses, case studies about decreasing risk. The other thing is often when I was consulting, the permanent team members would go, why do they keep bringing consultants in? We're doing the work, but we never get seen. Consultants come in and they ask us a whole lot of questions, write down what we say, and then somehow it becomes true. And my feedback to them is because you're not selling. You're not selling. And what that means is your stakeholders don't know what you're doing. So use these techniques. You're doing the work. So just finish that last mile and present the work in a way that a stakeholder can see the value. So stakeholders are definitely one that we should be marketing to internally. The second one that I picked up on is data communities. We want to build this community outside our team. We want to talk in slightly different language with slightly different things, but we're trying to educate people in that case. We're trying to say, here's some things that you probably don't know about. Now we don't go into infinite technicality, but we're trying to make it written in a way that they can understand what we do. Take some of that complexity and if you can make it simple. And again, those internal blogs, those educational blogs are really valuable because there are lots of people in an organization that are interested. They want to maybe go from being a business analyst and move into the data world. And this helps them understand what it is and how they can get there and come and have a conversation with you. So, have you seen that? You've built data communities outside of organizations. We can use that same technique to build data communities within an organization.

I've seen some organizations do the kind of classic show and tell. So, that's one model. I think it's so much easier today than it used to be in terms of organizations are geared up with intranets. I've worked in organizations where We've taken the community and we've wrapped it around external communities. That's worked really well. There's the whole kind of marketing mix can be deployed, webinars, articles. And what's interesting, I find as well, is that when I was running a data team, it's like you never have enough resource, right? You just never have enough. And one thing I've always found was some of the best resources I found were some of the ones which were most undervalued within an organization. So I remember one of the organizations I worked at where I just had no budget. There was no budget to make any improvements. And I just looked at, okay, what did I have? And we had a team of data entry staff. So we just formed this little community where we would share data quality tips and tricks. And I would just teach them like the fundamentals of data quality. And we started off as a community. And then gradually these people became really skilled, just lunchtime community briefings, things like that. And then Before long, they were really skilled members of the team. And of course, we could bring in people to backfill them. We just built this homegrown capability. I think you'll find this often with an organization, that's one of the best ways to find star talent, because I think if someone genuinely wants to learn a data discipline, I would take them in many cases over someone who just has a passing interest and they've fallen into it. You can tell the passion's not really there. It's just a job, but give me someone who is just desperate to learn. You can teach people the fundamentals fairly quickly, applying the whole marketing mix, like you say, webinars and away days and sessions like that, and just finding that kind of star talent throughout the organization, the people who are desperate to work with you and get into data. I think that's really powerful.

One of the ways I've seen teams have a really great success with is book clubs. So again, having people read a book, come together, and the benefit you have in an organization is you have a closed community, you have a relatively safe community. Compared to if you're doing it publicly. So again, just look at what all the vendors are doing. Look at the fact that they're doing webinars. Look at the fact that they're doing Ask Me Any sessions. Look at the fact they're doing video demos of technology and what they've delivered. Look at the fact they're doing podcasts and experiment. Try it. You don't have to go and do high-quality production podcasts. Just get a couple of people and a microphone and have a go and push it out. And you'll be amazed at how your organization is going to pick that up because you're in a relatively trusted environment because you're part of their tribe, you're part of their organization.

I think the one you mentioned there on the tools, I think that's a good one. Definitely one of the things I've done in previous organizations is say, okay, what are the 2 or 3 tools that we use that we want other teams to adopt and just create simple little internal courses. And I think just not overthinking it. And some of the tools now for building training materials, they're like £30, £40 a month. There's no friction in terms of budget. So you can create really good little training courses in a few weeks just by doing like little over-the-shoulder videos and things like that. So I've definitely used that a few times. That's a really good point as well.

Iterate it with it, experiment. So when I started doing our product videos for our product, I found I went into a massive rabbit hole of perfection. I knew what I wanted and I'd write a script and then I'd read it and go, oh my God, that was awful. I could tell that I was reading something. So I stopped doing that. I find I do 12 or 20 takes because I got one word wrong. In the end, I got to a pattern where I gave myself 3 goes. I had 5 minutes to record something, so it could never be more than 5 minutes long, and I'd have 3 goes and one of those goes will get published. So again, you're internal, just do it, do it quickly, iterate it. If nobody comes, then that's an experiment to tell you that actually it's probably not interesting. If people start coming and you get feedback that needs a little bit more polish, then polish it, then change the way you do it, but do it quickly. And the third one for me is this peer community. So what we know when you're in an organization is you're just getting snotted with demand. It's like an adoption curve for software. Software, crossing the chasm. We start off where nobody cares. There's always latent demand for data, but nobody trusts we can deliver it. We start delivering it for a few stakeholders. People can start to see that we actually know what we're doing. And then we get this massive adoption curve where we just get hit with this backlog of latent demand and we get busy. And when that happens, we start focusing on doing the work, not learning the work. One of the great techniques I've seen teams do is things like Friday afternoons are learning days. Now that's a cultural thing. Often the engineers will be like, but I can just write code. And we're like, don't. 4.5 days of code writing is enough. But one of the things I found was you needed a feedback loop to get as much value out of those learning sessions as you can. So a lot of teams put in this idea that you'd go and learn something and then you'd have to actually teach somebody what you learned. So you'd go and learn something new and write a blog about it, or you go and learn something new and do a video about it. And that art of having to give back had a couple of things. When you were learning, it was forcing you to think and learn because you couldn't just learn it and go, yeah, I learnt that. You had to go, actually, I've got to teach somebody this, so I'm going to be a little bit more invested. People could then see what you did and they get more context. Might see a vendor's presentation on semantic layers. When the person played it back internally through their content, you got a view of what a semantic layer may mean within their organization. It put context and that kind of stuff and flavor. Also, you're somebody you can go talk to. You can go watch the same things they watched or read and go, hey, I found this. So you started getting good feedback. So that idea of building a community for your peers, for technical people like you, very valuable. But like you said, they're a different audience, they're a different conversation. They potentially are different techniques and mediums that you're delivering for those.

Just on that point, one of the things I always stress with clients on the consulting side is that you have to build a playbook as fast as you possibly can, because one of the challenges you have, and I think the exact same challenge is relevant internally as well. This is one of the things I learned in my very first job. I got lumbered with basically complying with ISO 9001 in my first role, and I was brought kicking and screaming to the compliance table. It formed the backbone to everything that I did. And one of the things that was drummed into me there is unless we have a standard operating procedure, this process that you do doesn't exist. Some people hate sitting down and writing down, and I'm one of those people, I hate sitting, but I realize how important it is. And I think So often in data teams, whether that's your own consultancy or whether it's an internal one, there just isn't enough focus on like, what is the playbook for building this thing? What is the playbook for how we build a pipeline? What is the playbook for how we build a data governance council? What is the playbook for how we build a data warehouse? And what happens is all that knowledge gets stuck in Kevin or Lucy's head, and then when Kevin or Lucy disappear, then it's all gone. That process of teaching people how to create effective playbooks that has to rest with the data leadership. They have to see that's being done. And certainly when I've done that in my own consultancy, when I've documented whether it's like marketing or building data quality engines or whatever it is, the stress that falls away when you've done that and then having someone to come in and be able to follow it, you instantly see I can scale now. I've had this before where it's taken me weeks, sometimes months to write what is my data quality playbook? What is my data migration playbook? But when I've done that, we've been able to bring in 4 or 5 people. Who maybe they do data profiling or some aspect of it, they've got some basic data analysis skills, but we can say, here's the playbook and boom, within a few days that they're productive. I think too often I see data teams where that type of rigor just doesn't exist and then they really struggle. It shouldn't really come down to the skills of the person coming in. There should be a backbone to this is how we do it. Cool thing about that is that quite often it means you don't need such highly skilled people. Necessarily, once you build up those playbooks. But I think that's another skill. The skill of building a playbook is really key. And that's something I instigated that in my very first role. And I'm constantly surprised how it just doesn't exist in most organizations. So I don't know your views on that.

I don't see it very often. And I'm thinking about why. So writing playbooks is hard. And the reason it's hard in my head is it's easy to write a marketing playbook, a couple of soundbites. It's incredibly difficult to write a playbook that somebody can execute with context. And the way I think about it is I think about information value stream. So when I'm coaching a team, I get them to watch this great TEDx talk around how to make toast. And it's around systems thinking, it's around nodes and links. So there's a task you do, that's a node, that then gets handed off to another task, that's another node, and there's a link, there's a line between it. I get teams to map out their value stream. Tell me the data you work with, tell me the stakeholders you serve, tell me every step you do in the middle. Now, some teams will do almost like business flow. Some teams will give me a technical flow. Some give me high-level nodes. Some give me incredibly detailed nodes with if statements and else-thens and their workflow. The reason I do that is I want them to have a shared language on how they're working. I want them to then adopt lean thinking to say, where's it broken? Is there a node that's broken we should invest our time in iterating that way we work next? Is a line broken? Is the handoff between two teams and we know it's where we are with things? Let's look at the system. And let's identify what's broken. Then what I loop in is the idea of patterns. I go, if you think that your data collection is broken, okay, there's patterns to automate it. So pick a pattern, find one of those problems, see if the pattern fits and lock it in. What I hadn't done is think about combining all those patterns for a node or a line as a playbook. And that would be really good. So I'm gonna experiment with that because now what I've got is I've got a structure that I can go and see how everybody else structures their playbooks. And I can say, okay, you're given this problem. Here's the patterns and the order you should try them. And then once we get to a playbook that's been proven where somebody can come in and operate that playbook, they can pick it up and execute it manually, then we should look at automating it. We should build the Information Factory. We should say, okay, how much of that work can we get the machine to do, not the human? So that playbook would be great. But building a playbook and building community, they're two things that kind of seem like dark arts. It's hard for some reason. It looks easy. Community, we just bring people along. They're going to come, right? But they never do. Building a playbook is just a set of steps. How hard can it be to write down their operating process? But both of those are incredibly hard. From your point of view, when you teach somebody to build a community or you teach somebody to build a playbook, what are the things you get them to focus on to begin with to reduce that complexity for them?

When we're doing the playbook, so let's say I'm working with a consultancy, say they've done a whole bunch of projects and generally those projects will follow a similar theme. So let's say they're building a data platform. Or they're building a warehouse, or they're building some kind of data product. When you get them to go into the detail of, okay, how did they do it? You'll see, just as you were saying, you'll see some standard patterns coming along. So I just get them to break that down. First of all, what are the core building blocks? What are the big steps that you go through? And then just iterate on that, just go deeper and deeper. Obviously technology will change, the process, the way I would build a data pipeline today It's pretty much exactly the same in terms of the high-level building blocks. It's the same as what I did in '93. It's set up a data contract, build an information chain map or value chain, as you were saying, identify all the stakeholders, identify the data quality measures. It doesn't really change. And yes, we will have new technology, it will come and go, but it's the same fundamental building blocks. But yet over the years, I've seen so many organizations, they will just skip data quality or they'll skip the contract piece or they won't map the full chain or they'll map it at a weird level or they won't have a data model. or that they might have some kind of physical schema stuff, but they won't have the logical and the conceptual. We just want to remove that variance. So in terms of the playbook, it's just like basically sitting down, writing out as best as you can. And then the key thing is like the next time that requirement comes along, next time someone says, hey, build a pipeline, you get someone else to do it. And you see where they put their hand up and say, this just doesn't make sense. So the idea is you want to train people to follow the process, get them comfortable with the process, and then they basically perfect it over time. That's the key. You want to move the expertise away from the expert and then push it down to the rest of the team. And I think a lot of people struggle with that because some people want to be seen as the guru and some people, malicious reasons, want to keep that knowledge locked in their head and they're terrified of letting it go. Even as a freelancer, I realized that that was fool's errand. Even as a contractor freelancer, I would always train the rest of the team. I trained myself out of a job because I realized that's one of the best ways to get asked to come in again and again to solve problems, to be seen as proactive, to be seen as an enabler and someone who develops a team as opposed to someone who just hoards information. But again, this comes down to leadership. A leader has to do this. You can't expect the team just to magically do it on their own. This is the role of a data leader. So I think that's the process for defining the playbook. So write it, get someone else to follow it, and then have them pick it up and then just get the team to refine it and refine it. And come up with a format that works. I like to have a document that's just like full of pictures, just explains everything. Other people just like to do textual, very simple text. Again, it's work with a format that works for the majority of the team. In terms of community, I think most communities fail because people can't see the value. It loses the what's in it for me factor. The way I did it with Data Quality Pro and Data Migration Pro, when I was trying to form a community there, was just to share everything I knew. Like just share practical things. For example, like my checklist, I had a huge 50-point checklist. I just gave it out for free. And that got a huge body of people looking at my framework and my process. And I would just do webinars, and then I would do events and things like that to bring that audience together. And then we would do virtual summits, and then we get other people to share. Internally, one of the cool things you can do is look at building a simple little curriculum. What is a capability framework for if people want to get involved with this stuff? Okay, just create a simple little capability framework. So if we were talking, say, data quality, you would say, okay, these are what data quality dimensions are. These are what data quality rules are. These are the most common rules. How would you do it? And then just use your own internal data. Data to show how to do that. I think that's the thing. Most people will come to these things if they're learning something practical they can then take away and deploy for themselves. I've seen some vendors get this right with the way they bring out products and things like this as well now. So it's, there's that community element of it. I think also having somewhere where you can get answers. You came up with a really good point earlier about the AMA sessions and Friday afternoon sessions and things like that. I Those are some of those impactful things I've seen in terms of building communities. Just say, give people a bit of a roadmap and a mission, help them see where they are, and just ensure that their questions are being answered. And also be open to where people want the community to go as well. Yeah, it can't be top-down. It has to let things bubble up from within that community as well. We run a large forum on LinkedIn now, we've got like 20,000 people in there, and You have to lean into what the community wants. So we're constantly asking people, hey, what topics do you want to see this term? What new features do you want to see within the forum? That type of thing. It's just let the forum decide where it goes.

If I look at that playbook, what we want to do is, is when we are building out the playbook, we are starting with a large amount of uncertainty. We, we don't know what our playbook looks like. We don't know what the process to write one is. We probably don't know what our value stream in our organization is. So the first thing I recommend is just document something you've already done. Take one of the processes, put it into a playbook and experiment with the playbook format. Second thing is don't sweat the detail. We're not looking for a step-by-step immutable checklist of every step you need to do. High level's fine. A high level story of here to here is enough to start with. It's valuable. And then iterate it, get somebody to read it and see if they can tell you what your process is. Get somebody to try it and see if they can follow that process. So we're not looking for, you know, a 50,000 page step-by-step manual of things you have to do. We are looking for artifacts that have help. So the way I talk about it, if you're producing an artifact, a template, or a piece of documentation, you need to be really focused on what the action that you expect from that is. So if I do this, I expect the person to use it in this way and achieve this thing, and that thing has value. If you haven't, then don't create it. You're just wasting your time. So experiment. Again, look at playbooks that vendors have and see how they do it and the bits you like. Coming back to community. One of the things I've, I think about again is, is your community doesn't have to be bound solely to your organization. You can probably find some other organizations that are maybe not competitive, but are in the same geographic region or use the same technologies. You can put in place non-disclosure agreements and then build a community between two of them, you and somebody else. You can think about building a community as a first step for an academy. If I'm going to build these little bits of content. And help my community upskill themselves, how does that get me towards this idea of building an academy internally? You can bring your vendors in to help you build that academy. Now you've got to be very clear with them. I've seen somebody do this really well. We're building an academy. We'd love you to help. Yes, we're interested in, in how to use your technology, which we use, but actually we're interested more in what you are seeing in the marketplace with your other customers. We don't want you building sales material, but coming in and helping us build material around the community. What you often find is those vendors have a whole toolkit. They have a massive repository that somebody's built in their organization that you can pick up and leverage. And again, get there quicker. So again, just be clear on the relationship, but often there's lots of ways outside of your small team that you can help build these communities.

I've worked with some really good vendors who are good at that, having away days and things like that, where it's not just about the product, it's about bringing often data leaders and that type of community together to see what the art of the possible is, not just around the product, but like, what is everyone else doing? There's some some vendors who try too hard to push the product and they miss the point. We have a data quality and data governance leadership forum on LinkedIn and it's discussion only. There's no pitches or promotions in there. We cut out spam. We routinely get senior data leaders say, hey, I'm really struggling with this problem. And they're quite transparent and people respect that. We'll sometimes get 40, 50 people jumping on trying to give advice about where to move forward. I wouldn't get too bogged down in terms of features and functionality and all this kind of stuff, like just a simple forum gateway where people can come on and just share what they're struggling with. But I think you definitely need someone to manage that community. It won't just happen. I think a lot of people just throw technology at it and they spend loads of money on things like Circle or Slack and things like that. But the key is that you need a community manager. You need someone to step up and own it. And it's quite intensive. We have to put quite a lot of effort in to keep that going and manage it. But It's one of the things I'm most proud of, just having that many people all around the world, basically feeling like they can come at any point to say, hey, I'm struggling with this. Can I get some help? And have data leaders all over the world jump in and say, yep, we've had the same problem. This is how we solved it. This is what I would do. Don't sweat the kind of tech, just make it simple.

And amplify the resource. Often people think they can create a community, it's just going to manage itself. Sometimes we'll see a community. Startup, there's a classic one in Slack at the moment that had 5,000 or 10,000 people join over a week or 2 weeks, but now it's dead. It's a zombie community with just vendors posting and be shameless vendor. You need somebody that's pretty much full-time if you're serious about building an organization-wide community, because they need to keep reinvigorating the conversations, bringing in new ideas, helping people, answering questions, helping people answer questions. You need somebody there just to feed and water and drive it. Like you said, if you just create a Teams group It might get some people coming initially if you're lucky, but in a month or two, it'll be a zombie group. Don't underestimate the investment.

Like you say, if you look at LinkedIn, for example, most LinkedIn groups are just exactly what you described there. They're just a vendor pitch zone. Some of the ones that have got like 120,000 members in there, you have to scroll for pages and pages to find a single discussion, let alone anything that gets one or two, one or two comments is good performance for some of those forums. But we routinely get say 40, 50 comments sometimes. There's always discussion on some of the posts. That we get. And I say one of the things we found is little things, you get a feel for who are the people who will readily jump in and offer advice. And what we found is as soon as a handful of people jump in and offer advice, then people let their guard down and they'll jump in as well. We really focused on spotting when someone has a hidden agenda to subtly pitch their consulting or their product. Hey, what does everyone think about the future of data governance catalogs? And they're a data governance catalog vendor or something like that, and which way that conversation is going to go. You're right, it does take a lot of effort. But the upside is huge, I think, particularly for internal communities. If you can get the rest of the organization talking frankly about where they're struggling and what they've got going on, what their problems are, then that can really start to build some bridges internally. You made a really good point earlier is that why do consultancies come in and why do some data leaders and data teams get frustrated when external consultancies come in? And you made the point, well, because they're not marketing themselves effectively. And I've had so many calls over the years where data leaders have picked up the phone and basically said, hey, yeah, so we've lost our entire team. We've had a management change and we've all been kicked out. Is there any chance you can help me find a job? Or do you recommend any organizations we should talk to? And every time I've had those conversations, you dig a little bit deeper and they've literally done no internal marketing. They just thought they were doing good work and that would be good enough. And I think maybe 20, 30 years ago, doing good work would be enough, but I don't think it is today. I think the pace of change is so fast. You look at chief data officers, for example, it's almost like a revolving door. If they're there for 2 years, that's a long time for some CDOs. The pace is so fast and expectation is so high. You have to overdeliver on your marketing and your salesmanship. Whatever you think you're doing, you have to double it, I think, to get it across just how much value you're driving. And I think that's why it's so important for data teams. It's coming back to the whole playbook thing and scale. You have to treat it like an internal consultancy. You have to figure out what is my positioning? What is the proposition that we're offering? Because most people are completely confused about why you're there and they can't figure out what is it that you actually do in data. It comes back to that classic, what's your positioning within the firm? What problems are you solving? What's the core proposition? What's your playbook of delivery? Then you get into the whole marketing piece of, okay, you need to publish, you need to promote, you need to prospect, you need to pull people into those sales conversations. And then you need to provision and learn from it quickly and be able to do that at scale and do it often with limited resource as well. That model of treating a data team like an internal consultancy fits really well, I think.

I want to talk about moats in a minute, but just before I get there, you made a good point about communities. One of the unseen tricks that you see in a community is small cohorts of people that boost each other. If you look at people that are very successful at their LinkedIn posts or communities that are very successful, there's normally a core of people that as soon as somebody posts, they will jump on and comment about, 3 or 4 people will jump on and then everybody else joins the party because they find it interesting and they find it safe. So again, internally, when you're building out your community, line up some people that think like you and say to them, hey, tomorrow I'm going to post this. Can you jump on? Be very proactive. Virality doesn't tend to happen by accident. So set up your team, your people to work with you or other people in the organization, and then maybe come up with some themes. This month, we're going to follow focus on posts around data quality. I'll post one, you post one, we'll help each other out. That helps it. And then moving on to moats. Yeah, I was talking to somebody the other day and they were incredibly frustrated because they were permanent in an organization. They've been working there for a while. They'd picked a certain data modeling pattern for one of their layers. And then change of slippers, new leader came into the data team, turned around and said, oh, we don't want to use that modeling technique. We're now going to use this. And they had no moat. They said, look, we've built it. I don't care. If they had a playbook, they had a set of things, if they had things they can point to, people and documentation that said, actually, this is our way of working. We're willing to iterate and change, but do you realize what you're about to do? Because we're about to stop adding value to the organization for 6 months while we completely rewrite our processes and our playbooks before we get back to delivering value. Are you sure that's what you want your first step in this organization to be? Now, don't do it in a threatening way, but what you're doing is you're pointing to a playbook that exists that says, here's how we work. Look, we're willing to change it, but here's the consequence of that kind of change. Now, that probably wouldn't have fixed it. People come in and they, they're in a leadership role. And for me, that's more a manager role because a leader should come in and observe first and then help iterate. This playbook idea can create this form of moat, you know, a form of safety net to potentially help your team carry on working the way they want to work, not the way somebody can come in and wash it out.

Absolutely. The idea of the moat, I think, also comes back to other teams understanding what your value is and building those bridges, whether that's infrastructure ops, data ops, or DevOps, or say marketing, finance, whatever. It's about being really clear about the value proposition that you have. And it comes back to that communication. What was the problem we solved? What was the solution? What was the result? And what's the difference now? And I think that's the bit is that a lot of data teams are really poor on explaining like the difference. What is the difference of working with us as opposed to the old world? That old world, new world. Quite often data teams will just go in, fix something, and they're just a little bit shy communicating that value effectively because the data people, and this is the problem I had when I launched my consultancy, I could build anything in data. I was a good data engineer and all that kind of stuff. Data quality migration, no problem at all. But when it came to standing on a stage and basically blowing my own trumpet or writing an article about my service or whatever, it took me a long time to get over that. And I think that's endemic within the data industry, is that we're not effective enough at explaining. And you can do it in such a way where you don't sound arrogant and brash and things like that. And last thing people want to hear is, oh, these guys came in on horses and slayed the demons and won the day and all that kind of thing. But I think just being really clear about the value that you're offering and build those bridges with different stakeholder groups, because you want to get that air cover. So if someone comes in, they would have to basically say to every single stakeholder, all the value that's being generated, we're going to strip that away. And then it becomes a much tougher conversation.

Typically, the leader that's come in, their boss is still there and their boss actually endorsed the way that the team built it last time. So they've got to be a fairly brash person to come in and go, we're just going to throw everything away. And if that's the strategy, if the organization has said there is no value in what was built, it's okay. But it has to be clear that there was no value, just not that there was value, but it wasn't articulated. And the other technique that vendors use a lot is fear, uncertainty, and doubt. I haven't quite got into it, but today there's a few things on LinkedIn about Databricks and Snowflake having another go at each other. What are they doing? They're trying to bring fear, uncertainty, and doubt. They're trying to say, you could use the other vendor, but ooh, are you sure? And data migration is a classic one. People think data migration is easy. It's a horrible thing to do. And so bringing some fear about that process to say, actually, data migration is really complex. Here's all the things that can go wrong. We'll make sure they don't. As an internal team, that's a great value proposition. So one of the things about about this whole thing is why would you do it? You're a data person in a team, you're busy, you've got to go build some stuff, you've got to learn some new stuff, want to spend 40 hours to 80 hours of your life doing your role. Why would you go and actually do these extra things? And for me, building your personal brand is as important as building your team brand. And so all these things we talk about are valuable for you. You can build these things internally and you're building your personal brand, and then you're more likely to to get the promotion, you're more likely to get the pay rise because people know the value you're offering. If you want to go one step further, you can take that content and you can anonymize it into a form of patterns. So remove all your company information out of it, generalize it so that it looks like any company, or potentially rewrite it for another industry and another company that you haven't worked for. ChatGPT is a great way. Here's a whole lot of content for my industry, give me some examples for another industry, and then recreate curate it and publish it, publish it on your own blog, publish it on your own portfolio. So when you go for another job, you can go, hey, here's some of my writing, here's some of the things I did. They're not actually about my organization because I can't do that. Nobody's going to hire you if you actually give your company's IP out, but you can generalize it. And the benefit you have as a permanent is most organizations will let you do that in the hours you have with them because there's value. If you're a consultant, doing that kind of stuff is non-chargeable. It's effectively unbilled hours.

So what have you seen?

Have you seen that using these patterns and techniques that consultants use, if you use them internally to build your own personal brand, there's some massive value for you and your company, your organization doing that?

Totally. I think on the personal level, it makes perfect sense. And I've had lots of data leaders who reach out to me privately and basically say, hey, look, I want to showcase the work we've been doing here. One, it's good for the team. It's good for team morale. It puts us on the map. I think there's always that personal element as well, where people, they don't know how the market's going to shift in 2 or 3 years. So they definitely want to build their own personal brand as well. I think you can do it in a way where you bring the team through. Let's say we've run with dataqualitypro.com, for example, the, one of the websites we had for the data quality sector, we used to do virtual summits and we would get teams coming on those to talk about about the project they've been through. So you'd have the leader, and then they would bring their team as well, which I thought was really cool. So it's, hey, this is what we're doing. It gets the team used to being in that environment, a public environment, talking about the challenge they've gone through and what they've solved. Obviously, there's always issues with some organizations, like the PR police basically spoiling the fun and saying, you can't say this, you can't say that. So you do have to be mindful of that and obviously get everything cleared, Yeah, don't go rogue and just put stuff out on your own. But I think a good leader will always try and develop their team's communication skills as well. Cause if they're confident presenting on a podcast or a webinar or any kind of digital format initially, I think then it will help them when they come to stand on stage and do it. Those are always nice kind of safe environments to start with. And then if you've worked with a vendor, for example, you might do one of the vendor roadshow or something, or an annual conference where you talk about the projects you've been delivering, things like that. So. Definitely helps with morale. I think it also helps, like you say, it helps the team learn how to communicate the value that they drive and brings that confidence back up as well. If you're running a data team or you're a data leader, then gone are the days where you can just rely on your CV doing the job for you. I certainly found for me, there was pre-2006, no one knew who I was unless someone had my CV, they would have no idea. And even as a consultant, I found that hard. When I first launched my firm, everyone said to me, you'll never work for big organizations because you won't be on the preferred supplier list. You're not Capgemini, McKinsey, Accenture, those guys. You'll never work. What I found was as soon as I had my personal data brand, as soon as I had my data brand, then I would do things like I would host a webinar and then companies like GE Money would say, love what you did in the webinar. Can you come and do that for us? All of those fears and doubts I had and all of the kind of naysayers saying, 'Big firms will never work with you' just went out the window. Obviously, you don't want to get into a client scenario, you know, exactly what the client was struggling with or exactly what your employer is struggling with in fine detail, because sometimes that can be damaging. But if you explain, as you say, what are the patterns, what's the process that you went through, and what's the outcome people can expect, I think people will resonate with those situations. You don't need to spell them out in detail, but just going through the high-level issues and then explaining what your playbook or your process is for resolving them. And just doing that in different formats, obviously webinars, events, clients, things like that, but just through external content. Again, some organizations are very sensitive about that. But generally, if you talk in high-level terms about patterns of behavior that you've seen, I think today, if you look at LinkedIn, there's two different types of content. There's the kind of contrarian type content that you see, which is everyone thinks this, I believe this. The other type of content is like playbooks and processes. Here's step 1, 2, 3, 4, 5 of solving a problem. I think if you can combine both, I think that's when you have a lot of power as a content creator where you can basically say, hey, for a long time, I thought this, which is understandable because that's how we were grown up, right? That's how we were taught to behave and believe. But here's the thing is I kept doing this and I had this pattern of failure. I kept seeing this pattern of failure. So we tried this and we had a better outcome. So now this is our approach. I think the problem is a lot of people just rely on the kind of ChatGPT view of the world. I even see people who have really popular courses on how to create LinkedIn content, for example. Saying, this is how you should use ChatGPT to create your content. And all you're going to do is get the same content that everyone else is putting out. So what it'll end up is, here's 5 tips for XYZ. And I see a lot of that content in the data space, like here's 5 tips for building a warehouse or building a pipeline or building a data governance council or onboarding a data catalog, whatever it is. And I think we're just going to see an explosion of content like that. It's already bad. I think it's going to get much worse. But I think that framework of, Hey, here's what we always used to do. We did that as well, which is understandable. But when we saw this pattern emerge, so we tried this, here's our framework and here's our proof. I always say that to consulting clients, unless you can show proof, it didn't happen. I regularly get people reach out to me going, that last post, it feels like you got inside my head. It was spooky because that's the exact same thing I've been doing for the last 6 months. I've been making that same mistake. When you can get to that point. And you'll know you're at that point because people will literally reach out and say, wow, that was spooky. That's quite freaky. That's the exact same conversation we had. That's when you know you're on the right track with your content. And you can apply that internally and externally. It doesn't make any difference. Internally, you might be talking about, hey, do you find when you're trying to produce a report and you keep getting this type of issue? We used to get that issue in our department and what we've done is we do this. Hey, and we can do it for you as well. It's that universal framework that works really well to convince people you're talking about. Because there's a lot of people on LinkedIn now who you look at their profile and it's clear they haven't built things like data mesh and data fabric because very few people have.

The same joke I have about ChatGPT now is we write one sentence, so ChatGPT can write 600 words. So somebody can take the 600 words, put them in ChatGPT, and give us back one sentence. You're right, there's a lot of people that x-Fang, x-Google, x-Airbnb. And often I think, that's great, but how many organizations do you know have 1,000 engineers? How many organizations do you know that have 30 petabytes of data? Actually, most people have a team of 3 to 20 in the data world. Most people have under a terabyte of data they actually use. And from a data influencer point of view, yeah, we're seeing data influencers who are content creators and marketers, and they've never actually worked worked in the data world. They've never worked with 3 to 5 different organizations across their career. So if you're inside an organization and you're doing that work, you're doing that mahi, you've got such insight into actual problems, how you solve them, or even better, how you didn't solve them. I tried this, didn't work because of this reason. I tried this, that context is where people will get value. And so you've got access to a rich vein of information that other people don't. And the last thing for me is write with your own voice. Don't look at the way other people write. Craft your own personal brand, therefore craft your own way of writing. It has to have your tone. You should be able to read it and go, I actually know who wrote that, ideally, because it has to be you. When I write, I don't typically spellcheck because I don't care. And, and I get lots of feedback about that, and I'm like, I have a writing technique that I've works for me, which is when I have an idea and I can, I stop, I write for 15 minutes, and that's it. Because anything else didn't work for me. If I put bullet points, I'd never come back and complete them. If I wrote it and then curated it 3 times, yes, it would be much better, but I would never get around to doing it. And so for me, it's about, oh, I've seen this problem, I find that interesting, or I've seen how people fix it. I'm just going to write that down for 15 minutes. I'm going to push it out. If it's valuable to somebody, great. If it's not, okay, that's 15 minutes I haven't wasted because it makes me think. And it's 5 minutes for them reading that they go, eh, nothing for me. Just find your own way, your own craft. It's your personal brand, not anybody else's, right?

And that's what you're trying to build. Totally. I think a lot of people these days, they get too hung up on the kind of the affirmation side of it. I think this depends a little bit if you're a consultancy or you're internal, but A lot of people obsess over how many likes they got and how many views they got and things like that. And the danger there is you become a slave to the algorithm. So like LinkedIn, for example, right now it overindexes on content that generates a lot of commentary. The other day I posted like a big chunk of my framework that people pay several thousand pounds for, and I shared that out with a lesson and some advice and things like that. And it did okay. And then I shared a meme because I wanted to test something. I shared a Buzz Lightyear meme with a topic that I thought people might find interesting and it just rocketed up. So which is the more valuable piece of content? I would say the framework that people pay a lot of money for, and I gave some context around it, if you apply that, you're basically going to be, you're going to drive sales to your consultancy, much more valuable than the meme, yet the meme outperformed it. I think you could become, like I say, a slave to the algorithm. And go where the algorithm wants you to go. But I completely agree with your approach of my best content has always been, that's a good idea. It's important to me. I like content that was, it was a realization when I realized, ah, there's a pattern there. And when I change things, I had this outcome. That's always the strongest piece of content as opposed to here's 5 tips for doing this. Here's 5 tips and tricks. And for that, it's when you can show that we had this problem, we saw this pattern, we switched, and now we have this outcome. And here's some evidence for that, that's really powerful. It's really helpful to look back and see where you had resonance around your content. And then I think it's really important to go deeper as well. I will routinely look at my most popular posts, not necessarily popular by this one had 20,000 views or whatever. Popular is in terms of people reached out and went, I like that. I hadn't thought of it that way before. That made me think. It's more on the emotional side of it or the kind of feedback I get as opposed to I got 20,000 views and 200 likes or whatever. It's more, what do people say to me? What do people reach out? And also some posts I'll put out and then I'll just see 3 or 4 sales calls instantly. And then when I get on the call, people say the post you wrote yesterday just hit me square between the eye. And I thought, yep, I had to get on a call with you. And you'll be the same as well if you're internal and you put something out and a lot of people disagree with it or they come on and it creates energy and conversation. Then go deeper into it, leave it as a post, but sometimes you have to go deeper. And that's where I think going into an article and like you say, yeah, don't get too hung up on frameworks and things like that. Cause that, yeah, that can all be taught. And I do training on that. There's loads of different training on how to create an article, but extend that post out in terms of, okay, can I show some examples? Can I show some pitfalls that we went through? Can I break those pitfalls down? And always frame the article, who are you writing it for? Just really get into the detail because then that'll help you potentially reach a bigger audience, but it will just help your clarity of thought as well. Most of what I write is not necessarily for my audience. It's for me to really think through the problem of what I've just solved. And then I'll use that again for extra modules or going deeper into a module or a webinar or something like that.

That writing process actually helps you articulate in your own head. It helps you think about about it. I will often think I know something, I'll start to write it, and I'll go, actually, I haven't nailed this one in my head. Or I write it and I get to the last bit, which should be, so what? And I don't have one. And it's okay. So actually, I don't know what the benefit of that was. Or I write 3 or 4 different things over a period of time, and then I'll look back and coalesce them. I'll go, actually, there's a thing there. There's a single pattern that solves all those problems, or there's 3 or 4 patterns that go, I could put into a plain book that helps me solve a part of the value stream. That practice of writing is valuable to you as much as it is to everybody else. Let's look at time. I want to close it out. And you talked about the fact that you came from a software and a data background, and we've seen patterns from the software brethren come across the data, DataOps and CI/CD and a whole lot of technical skills that have been very valuable to us. I think today we've talked about a bunch of patterns from consulting and content creation that are very valuable. That we can apply internally, if not as our own consulting businesses, that's where we want to go. Anything else? Anything we've missed that you go, actually, if I was going to pick up a software pattern or a data pattern or a consulting pattern or a content creation pattern, and if I was leading an internal team, or I was a person who was full-time in an organization, I wanted to go out on my own to become an independent consultant or start my own consulting company. Anything else we've missed that you go, actually, this What was the other thing that I found really valuable?

Oh, that's such a good question. So many things. I think for me, I would say of all the consultancies I've worked with that were most successful, I think the one thing is the positioning and not trying to do too many things. I think there's so much value in nailing one problem and becoming the best in the industry at that one problem. It never ceases to amaze me how small or how focused you can get with us. If you look at classic positioning, At a simple level, it's basically saying, okay, which problem are we going to solve? So you could come at that for so many different dimensions of positioning, but you could say, okay, what is the platform we're going to work on? Or what is the technology? Or what is the fundamental problem? So you could say, I'm going to focus on CRM. Okay. And then you can say, okay, what about the sector? What verticalization can we focus? So you say, okay, I'm going to do CRM in charity. But even within that, And that, there's just so many different layers of the onion you could go. I think that's the one thing you really have to lean into. What is your true zone of genius? We all have different layers. So we have a zone of incompetence, zone of competence, zone of excellence, and zone of genius. And so many times I think when people launch their consultancy, they get pulled in the direction where they think the market opportunity is, but that shifts them out of that zone of genius into maybe a zone of competence. And I see a lot of people do this and go, well, this product is hot or that product is hot and they can move into that area or this sector is hot. And I think as long as a market isn't shrinking, as long as you're not trying to sell something in say print media, so print media is, you could argue is shrinking. As long as you're not in a shrinking market, just being in a stable market with a service that people will always need, you can go so much more fine-grained with your positioning than most consultancies realize. I've got one client. Who's— they've tripled in size. They've just beaten a massive consultancy, one of the biggest household names on the planet, simply because she has a podcast and she produces content every week. And her positioning is so focused that there's probably 300 organizations in her geographical area. So it's not a huge marketplace at all. But when people want to solve the problem she solves, she's the first person that they will find. If they search on Google, they would find her. And I think so many firms think that they have to be, and I made this mistake. I was looking back at my website the other day because I knew this podcast was coming up and I thought I might get into positioning. And I think I had 15 different services for my first consultancy and it was just me, which was just crazy. I just created a big list of all the things I could do. And I was probably like the zone of competence for a big chunk of them. But the two that I was like zone of genius, like you put me on a stage, 2 minutes notice and I could talk about these things for hours. And hours was basically data migration and data quality. So I should have just stuck with those. People too often think that they have to have all these different array of services to look like a big firm. And it's absolutely fine to have one simple vertical, one simple horizontal, a really laser-sharp focus to your positioning, and then everything becomes so much easier. It's almost like the anti-pattern. It's if you do that, if you strip away everything and just focus on that core offering, I've got one client, we caught up a couple of nights ago, and they do one tiny little thing now. And they said to me, their head exploded when they realized how much was in just that one little thing. They have something within a subset of data governance, and they're growing like crazy. They've sold stuff all over the world, and they just do this one little thing really well. And they were saying, the ability to create a playbook for that one thing, everything becomes so much simpler. Their partner strategy is simple. The content they create is simple. The outreach is simple. The events they need to be at is simple. Everything becomes so much simpler. So I would say that's a really key thing is just get, get really good at doing one thing before you start thinking of expanding out. Because once you nail that one thing, you can create that playbook so detailed that you can actually scale because that's the biggest challenge when you're a small firm, you just can't scale because you just think no one else thinks like I do. No one else can do data the way I do it. But if you focus, if you narrow in, then the playbook becomes easier to create. I know guys who have formed consultancies around a very narrow thing and they've been able to bring graduates into the fold and just scale that very quickly. And I've seen some consultancies who have done that and they've had big exits to companies like Accenture and that they've worked on that kind of, we're going to bring in graduates, train them in this one thing and then scale that out and sell it. Yeah, I think that would be my big one. And then just learn enough sales and marketing so that you can do things predictably. And it's not hard. I've taken clients who, they have a strong data background, but they don't have sales marketing. And just by teaching them the fundamentals, most of which are what we talked about today, just being able to explain very simply what the transformation is that you offer in a language that is aimed at your target market and just do more than everyone else. Just look at everyone else in your market and just create more content than them. And that's as simple as it needs to be.

I agree about one-person consulting companies that try and look like they boil the ocean. You see it where the person's the chief executive, but there's only one person on the about them page. And then their services are always data strategy, data platform, transformation ETL, some kind of data movementy thing, support, maybe a bit of training education if they want to get really funky. But those four core services with some iconography for it. And you see that time and time again. Again, and like you said, no differentiator. So just to close out, if people wanted to get a hold of you, if they want to talk to you about you helping them with their consultancy or their internal team, helping their team get more brand awareness internally about the value they're adding to their organization, how do people find you?

I'm always happy to chat to anyone, uh, you know, informally about what they've got going on. So if you go over to mydatabrand.com, there's a big button there which says book a chat. So yeah, Always open to chat to people about what they've got going on. But say my website there has got a blog with loads of articles and guidance and practical advice. Always open to having a chat, mydatabrand.com, or people can just email me at dylan@mydatabrand.com as well. It's just dylan@mydatabrand.com. Both of those ways will get me.

Excellent. And people should follow you on LinkedIn because I found your articles particularly helpful and sharing is caring and you do a lot of sharing.

So Yeah, as well. If you, if you go to my LinkedIn profile as well, you can book a call with me there as well. I try to post most weeks and get some content out. So that's, yeah, it's another way as well.

I'm a great fan of your content because it's actually educational rather than just a data influencer selling somebody else's product. And probably that's my last kind of bit of feedback for everybody out there is if you are going to start posting, be honest. If the post you're doing is being sponsored or paid for by a vendor, make sure you say that because it's so obvious when your content is pushing somebody else's product and you're pretending you're not. So just Be real, be honest, because we can tell. And if you want to build a personal brand that's based on selling other people's products, that's fine. Just be honest. That's what you're doing. If you want to build a personal brand, which is, hey, I've got this experience. This is what I learned. Then make sure you're honest. That's what you're doing. Been great chat. Everybody get, get in touch with Dylan if they need some help. Otherwise, look forward to seeing everybody go out there and start to use some of these techniques internally or externally. So on that, I hope everybody has a simply magical day.

Good day.

Good day. Data Magicians was another Agile Data podcast. If you'd like to learn more on applying an agile way of working to your data and analytics, head over to agiledata.io.