The Fabric Handoff – Ep.562

Handing work off in Microsoft Fabric means pipelines, notebooks, and capacity a team may be seeing for the first time. Tommy Puglia and Mike Carlo walk the path they use, from the builder’s first version to a joint build to the client building alone, and they stay with the leadership and trust that make that last step real.

News & Announcements

• Chicago Fabric & Power BI user group — The Chicago Microsoft Fabric user group meets Thursday, September 24, in downtown Chicago. Registration on the Meetup page matters because the hosts need each person’s name to get them into the building. The session, Using AI bindings to work with Microsoft Fabric, takes the second-brain idea and splits the work into context binding, where instructions and prompts live, and execution binding, the mechanism that runs them, with setup, best practices, and a practical look at AI in Fabric and Power BI.

Main Discussion

Topic: How a Fabric solution moves from the person who built it to the team that has to own it

Tommy frames the hour from conversations he and Mike have been having on and off the show. In the Power BI days, a handoff was a semantic model and a report that became the client’s intellectual property, a finished object the receiving team still had to know how to use. Fabric is a wider object: pipelines, notebooks, a medallion architecture, and capacity an organization may never have managed, including from a cost perspective, often inside a company with little data engineering experience. The transfer has to leave that team able to run the work.

• I build, we build, you build. Mike has used the same sequence for years, in Power BI and in Fabric. He builds first, away from the project, because he knows the tools and the client knows the data and the process, then he comes back and walks through the pipelines and notebooks that produced the result. In the middle, the client shares a screen and he coaches the interface, including how AI sits next to the data work or the report, so the learning is in the click the client chooses. At the end they agree on what to create, he steps aside, they build without his prompting, and they review the result together. That review is where the pitfalls surface. Hardcoding data stores in a notebook is ordinary, and continuous integration and deployment is the point where those stores belong in a variable library. A Power BI version of the same idea is bookmarks: if he adds them, the client needs to know how to create and maintain them. Tommy’s shorter name for the three steps is I build, we build together, and you build, and Mike agrees that is the model.

• Leadership and trust decide whether the handoff lasts. Tommy reaches back to Mike’s own consulting experience. An organization did not follow the recommendations, did not hire the right people for Power BI, and the value fell away, in some cases until they stopped using Power BI. He wants two things in place when a consultant leaves, even on a reporting project: governance with real roles and responsibilities, and skills growing inside the organization. A strong semantic model and the right DAX still need a process that keeps the business reporting the right things, and someone to go to when the numbers are wrong. Without that leadership, he says the environment becomes the Wild West, and the business blames BI.

• A lakehouse build and a trust program are different scopes of work. Mike agrees on governance and treats it as culture in the organization, often beside the project in front of him. Hiring him to set up data governance and trust is a different engagement from moving SQL, on-premises or in the cloud, into tables in a lakehouse. A contract can cover the semantic model and the report, and the organization can still need the rest later if Power BI is going to succeed there. During the technical work he still argues for a feedback loop, a competency center, and documentation. An early phase might be a few tables and a walkthrough of how the pipeline runs, with the working sessions kept as training other people can find. His own view is that a consultant who implements Fabric or Power BI, says good luck, and never raises data management is underestimating the client. Tommy holds that Fabric needs a level of governance to succeed, and they set that conversation aside for another day.

• Context has to travel with the execution. A team new to Fabric should receive a taper, with Mike’s time dropping as they take on the pipelines and the rest of the design. They need to understand what was built and why, how many workspaces there are, and what the CI/CD pipeline uses, because Fabric deployment differs from Snowflake and from Databricks. Trust, and a governance practice around that process, takes time after the design is understood. A company that already uses notebooks, already has data quality practices, and already runs a competency center can take a shorter path, skip the build-together stage, and call when questions come up. Tommy puts the same fork at the first decision, before anyone is talking about a closing meeting. One option is quick wins: APIs into a lakehouse, Delta Lake, and semantic models, a few weeks of work, or a solid lakehouse in a week or two when the processes are already clear. The other is training through medallion architecture and notebooks on the way to the result. The fast path can leave a tenant full of pipelines the organization does not yet own intellectually, and the wider that gap, the longer he wants the collaboration to run. Inside a company the picture matches. A data engineering team that wants finance or sales building their own pipelines starts with the first solution, then builds the next ones with them, so training, support, and management become part of how the system grows.

• The platform decision is a leadership decision. For an organization leaving old systems and starting clean, Mike’s advice is to do the move on Fabric, so the later work stays simpler. Where a dedicated data engineering team already maintains the stack, their input comes first, and choosing Snowflake or Databricks is their call. Whether senior management can set Fabric as the standard for data and AI is a separate question, and he ties it to what that leadership has been listening to. He has been on Fabric since launch and on Databricks from its early days. Databricks leads in many areas, and he still finds Fabric close, reliable, and able to cover most of that work at the scale a team needs. Several platforms in one organization add friction between the data engineering team and the business intelligence team, so he wants that conversation early.

• Agent context is part of the handoff when the team can use it. Tommy asks whether the skills he writes for a project, and the context he keeps for that company in a harness or a repository of instructions, schema, and validation, should transfer with the solution or at least be taught. Some of that is his firm’s intellectual property, built to help produce the pipelines. He does not have a settled answer, and he expects they will have to answer it. Mike starts one step earlier: whether the company allows AI, which AI, and whether people know how to use it. AI speeds the engineering and leaves the engineering in place. The slow part moves from writing code to testing what is true, so a large batch of generated code in a couple of minutes still needs a verification practice. Many organizations are not there yet, because they have not trained the team or encouraged them to learn it. Tommy’s business case is that if agents are how the pipelines and notebooks were produced, they belong in the handover. Handing over “the proper context” and then watching the client decline to use it is, for him, like building with the Fabric API and then hearing that only the interface will be allowed.

• Meet the team where they are, and price the slower path honestly. Mike’s picture of unused prompts is a Ferrari given to someone who cannot drive, or carpentry tools given to an electrician. He and Tommy had watched a VS Code documentary live the Friday before. In it, the people building the tools say they still do not know what users need from AI, which is why a folder of prompts is a weak gift for an organization that does not understand the tool. He would still teach Fabric with an agent alongside, as a programming partner, and he treats that as an upsell as well as part of the learning. It sits with the rest of a developer checklist he already uses with a new client: a service principal, API settings, an IDE, and version control, offered at the pace the department will accept. A finance team that is not allowed to use AI, and that expects the work to happen by clicking the interface, will not experience prompts as added value. Ask before building. One expectation is clicking around on the Fabric site until something works. Another is agents in VS Code, MCP, Fabric MCP servers, the Power BI modeling MCP, and skills. When those answers are no, and the team will not spend time learning, the AI portion goes unused. Tommy would still take a project that forbids AI help and requires everything to stay in the client’s systems. He would tell them it costs about three times as much, because the time is much longer. Mike puts the same work at two or three times the duration, and a higher fee. AI belongs in the package with documentation, building together, and training, and it is a misleading open to say the job cannot be done without it.

Looking Forward

Mike reads a finished handoff in two signals. The team stops coming back with the same questions, and they come back with a harder project. He uses that pair for consulting clients and for internal teams. Good delegation means the receiving group figures the next problem out, finance owns its pipelines, including what breaks and what the data gets wrong, and a new effort arrives at the competency center as a request to scale a first success into a second and a third. Tommy’s version of ready is a package his clients can reopen. He remembers being handed a black box by consultants, and he builds a documentation guide before he closes. Mike’s non-negotiable is that every meeting is recorded, transcribed, and available to the client. If the client wants to skip AI, or to supply their own and own the prompts, that is the project’s rule, and he understands why clients want to see how the work was produced. The volume is a knowledge base: a place to recover, a month or two later, what was decided and where it came from. Tommy has kept that catalog in a competency center, with validation schemas, metric definitions, and meeting notes. He used Confluence and SharePoint for it, he has dropped Confluence because he does not think its AI is very good, and he has left access in place for three months after the project, with the length open to discussion. On Fabric work he checks back at 30, 60, and 90 days, assumes there will still be fires, and holds weekly question sessions once the implementation and the training are done. He hopes to wrap those sessions in the first two months, while also helping with roles and responsibilities. They close on the same caution. Fabric still needs a lot of support, it is new to almost everyone, and it puts a more powerful tool in more hands the way Power BI did for data and analytics: easier to start, harder to assemble, still dependent on people who know the pieces, with less code to write and a management job to teach the team. Tommy wants another pass in about three months on what handing the AI over looks like.

Episode Transcript

0:06 Measures. The louder the sound, the brighter the light. Dance every day, catch this mix. Fabric and AI understand you. Explicit measures. Add rhythm now. Pumpkins feel the crowd. Explicit measures. Explicit measures. Hello and welcome to another Explicit Measures podcast with Tommy and Mike. Tommy, good morning. How are you? Good morning, Mike. Always glad to

0:36 Always glad to meet you. The main topic today is also the recording of the episode, by the way, because Tommy has to travel. He does a great job and he is needed in other places. He should be on the trip, and that’s great. This is working out well. Yes. A good problem. So, our main topic today is today is handing things off to Fabric, right? What does this look like for you as a contractor, as a developer? What does developing something in Fabric look like for you? And what is the experience in terms of how you communicate that to other members of your

1:06 that to other members of your organization, other team members? How did Tommy and I build our work at Fabric? And how did we transition and pass it on to teams that had n’t used it before, right? What does it look like? And what is this instruction? And maybe a little bit about our process of how we do these things. So that’s really the main topic today. But before we get we get to the main topic, Tommy, I have some news for you. What do you have? As always, we continue continue to announce our Microsoft Fabric User Group in Chicago on September 24th. It’s Thursday and

1:36 September 24th. It’s Thursday and we’ll meet in downtown Chicago at PM. Be sure Be sure to register on the Meetup page as we will need your name so you can get into the building. We’re going to discuss a lot of the elements that you and I talked about in our episodes and make a comprehensive decision. decision. Meeting title: Using AI Using AI bindings to work with Microsoft Fabric. And we really take the concept of a second brain and apply apply a two-part

2:06 a two-part approach to best work with Microsoft Fabric, where your context, instructions, and prompts live. and actually the execution mechanism or or execution binding. So, context binding and execution binding is how we’re going to going to divide this. We’ll talk about setup, setup, best practices, and we’ll actually see it in action. Perfectly. So, this will be a very practical, tactical tactical use of AI with Microsoft and PowerBI. So I think this is really the new world

2:36 new world we’re about to enter. With that in mind, let’s move on to our main topic. Tommy,, what is this topic about anyway? Share your initial thoughts on where on where you think this is going. And I’m sure we’ll just take this conversation where it logically goes. I think so. So, ask the question, okay? What, what is this? Outline this for me a little. What are we doing? As always, I’ll prepare the ground for you, Mike. This comes from many conversations you and I have had both on and off the podcast

3:06 and off the podcast. If you think back to the days of PowerBI, when as the execution engine you had to do had to do the handoff, you just had to say, “Okay, we created a model and a report for you; “Now it’s your property, your intellectual property.” And it was still a more or less complex or,, intensive,

3:36 task-oriented process. But with Fabric, I think it’s a little different in what it means to actually hand off pipelines, the actual path of someone’s data from my execution and helping build the architecture to hand off to the organization. What does this mean for an organization when they have never touched or managed this capacity capacity themselves from a cost monitoring perspective? But then again, we are in a new world of data engineering. We know, Mike, that many organizations

4:07 many organizations using using Microsoft Fabric do not have experience in data engineering. We often present a lot of these conceptual ideas, like the medallion architecture, the use of notebooks, the idea of pipelines—although it works great and we recommend it because it’s the best way to manage your data. There is a transfer that I think is more than just indicating where the elements are. You want to empower

4:37 organizations. So with all that said, I think that’s enough or enough or at least more or less describes what Fabric transfer is. But let’s start, Mike, with how you think you think Fabric delivery is different from traditional PowerBI delivery, when you compare the two. . Yes, I would even say that PowerBI is more like a product, product, right? So I feel like PowerBI is more of a thing that I’m going to build for you. So, this is a semantic model and a report. There is a final final physical object, the result of the work,

5:07 result of the work, which we pass on to the team. Part of this is because we we need to have a common understanding of the PowerBI world, right? If I’m building something in PowerBI, I need to I need to make sure I’m building something that you building something that how to use know how to use. For example, if I add a bunch of bookmarks to a report for the for the end end user, I need to make sure you make sure how to know how to create and maintain them. How do they work? Yes? You need to have some idea of ​​the tool itself to understand how it functions. I think things get complicated

5:37 things get complicated when you add conveyors, notebooks, and other things. So the approach that I that I like and that we, as a consulting firm, have been using for many years is this: “I build, I walk away, I create what’s needed,” and when I finish and finalize a product or a solution, I come back, say, “Here’s the finished product,” and we break down exactly how it was created. Here are the pipelines we created. This is how notebooks work. Here are other things. This gives me

6:08 Here are other things. This gives me the opportunity to physically step away from the project, create what I need during a quick iterative session, since I know more about these tools than the client. I am an expert in working with tools, they are experts in their data and processes. So I combine these two things and come back with the final product. And our next project is a joint development. Next step: you, as the client, share your

6:38 the client, share your screen, and I guide you through the interface: how to press buttons, how to launch notebooks, how to use AI in conjunction with your your data development or report building. And then I just direct you, the client. We do this because I because I need you, need you, the client, to be faced with the choice of where to click, what to do, that’s part of the learning that you need. So there is a lot of learning going on at this middle stage stage. And . And then, once we’ve gone through those first two

7:08 gone through those first two steps, we’re left with the last one last one. You build, I direct you, right? Let’s meet to discuss what exactly you want to create. I’ll step aside, let you , let you build everything, and then we’ll come back and review review the result together when you’ve done it on your own, without my prompting. Because that’s how mistakes are usually made, but at least I can point out the pitfalls. Okay, you’ve hardcoded a bunch of data stores into this notebook. This is normal. But if you are going to set up set up continuous deployment and integration, you need to turn this into a

7:38 this into a variable library. Let’s learn this part, okay? So here are a few more few more aspects of this. That’s the approach I’ve taken, Tommy, whether it’s Power BI or

7:47 it’s Power BI or Fabric. I feel like this approach works well in both situations. Mike, that’s good. And I like the like the straightforward approach you mentioned. I build, I work,, I come back, I explain, and then we work together. However, I will use your own words against you a little and go far back in time. in time. Good luck in your attempts. Come on, keep going. Someone I know, whose first name may have started with the letter

8:17 started with the letter M and last name with a C, was talking about his extensive experience as a consultant when he was stepping away from the business. As the organization changed, they didn’t necessarily follow his recommendations and ended up not hiring the right people for Power BI. Yes. The value of Power BI instantly disappeared, depreciated, and in some cases, they stopped stopped using Power BI altogether. Aha. So I want to say right away:

8:48 to say right away: I like this straightforward approach, but I think you oversimplified everything when you said “I build, I work, and then we work together.” Well, it’s “I build”, ” we build together” and “you build”. This is the model we model we use. I use. I completely agree. And like I said, I said, I love love how apt that is, but we already knew, Mike, when you were thinking about handing off Power BI projects. It’s not just tools and semantic models. As for me, there are two things that I think

9:18 think you forgot to mention. Governance: Is the governance really set up where, if I, as a consultant, am removed from the case, not only due to technical expertise but also due to lack of proper roles and responsibilities, the whole thing is not doomed to fail? And I’m only talking about Power BI. The other side is the upgrading of skills and resources within this organization. These are two elements; Whether Whether you go through it with them or not, if

9:48 with them or not, if there is no leadership in that organization to work with Power BI, business intelligence will fail. And I think you’ve talked about this before, but it’s just from a reporting perspective in Power BI. How to make sure that over time people always trust what they see. I can teach you how to create the best semantic model and understand that you are using the right DAX, but part of that is also the process of ensuring that we are reporting on the right things. We are working on the right things.

10:18 right things. How can we trust and verify this if I have n’t also implemented the part of the process you mentioned? You have to have some guidance to fight back when back when the data is inaccurate or,, accurate. Who are you addressing? Because then it then it turns into the ” Wild West” and eventually the business will blame BI for everything, even if you provided them with the skills and everything else. I’m talking about this here; you may disagree because I

10:48 disagree because I already know this case, I’m only speaking from a Power BI perspective. If you were doing a task or a project in Power BI right now… let me pause pause because I want to add the complexity of what Fabric brings to this, because I think there’s an additional layer. But Mike, as much as I agree with you, I think there are many more elements to a successful project handover, and I know you understand that because you do it beautifully and masterfully in your own

11:18 masterfully in your own projects. Yes, but is management part of the Fabric transfer, or is it a cultural issue that is separate from the Fabric transfer itself? And I agree. So agree. So let me say that I agree with I agree with your argument about governance. Yes. I governance. Yes., mean, but I think it’s more of a cultural issue within the organization, not necessarily part of the project itself. This may not be related to the project I’m talking about. That’s right. Yes. If you’re hiring

11:48 Yes. If you’re hiring me to help you set up data governance and trust, that’s a completely different scope of work than “Hey, we just want to move SQL to Fabric, and do we have SQL on-premises or in the cloud?” We want to create tables and transfer data to lakehouse. This is a completely different type of project. Of course, throughout the project I will probably emphasize that you need to manage this. You need to have a feedback loop. Where is your center of competence? I’m helping you write documentation for what we built because

12:18 we built because it’s important, right? My videos where we work together, right? These are training materials that are worth posting in your in your competency center so that other users can users can understand. You hire an expert to learn how to build a solution. This should become part of your your documentation library or the result of our joint work. And again, one of the things I’m explaining here is: when I build something, in the first phase of the project, I’ll load a few tables. I’ll show you how the conveyor works. When I

12:48 conveyor works. When I build it for you, you get the appropriate documentation. I create documentation because it is a best practice when it comes to governance and the competence center. So, Tommy, I think you’re describing a very valid reason or problem that arises in these kinds of project handoffs, but I think that’s a separate or tangential problem compared to where I was probably leaning, which is, let’s just focus on how to

13:19 go from the phase where I’m building something to the phase where the customer owns it, instead of buying Databricks or Snowflake. Does this fit this fit the concept of governance, whether customers can ask questions about the data and get answers from the team—that’s a completely different organization of the process, but I agree. However, I believe this is tangential to the Fabric transfer, and perhaps my approach was too narrow. I think, developing your point, there is a big difference between what I mentioned: successful use of Power BI in an organization requires data governance,

13:49 data governance, but the contract may not have included included implementation of governance and user support. This could could only apply to the semantic model and model and report generation. I, I think you’re 100% right, in my understanding, for an organization to really succeed with Power BI, you need those elements that may not have been part of the initial collaboration. So, these are two different things. Yes. And I think if you’re working with someone — honestly, this is my personal opinion, Tommy — but if you’re working with a consultant who

14:19 consultant who just implements Fabric or just builds your Power BI and then says “good luck” and doesn’t advise you to think about data management as part of that process, I think they’re underestimating you. Now, I’m going to make a make a distinction here because I completely understand where you’re getting at. If we only work on the technical part to part to hand over Fabric, right? I’m still going to going to insist, and I still think it’s worth discussing here, that Fabric, Fabric BI, Fabric requires a

14:49 Fabric BI, Fabric requires a certain level of governance to be successful. But I think that’s a conversation for another day. So, . So, I guess I guess you agree with that? Yes, I agree. But I want to maybe shift the shift the conversation to the choices that the customer or client makes about what what data tools they’re willing willing to use or to use or what they put their initial effort into, that really impacts this whole story. Let me Let me add more add more context or details

15:19 context or details to what I to what. Yes? If you are an mean. Yes? If you are an organization starting from scratch and have a bunch of old systems that you are trying to migrate to something new or modern, my advice: do it exclusively on Fabric. It will just make your job easier in the future. If you’re starting from scratch, just

15:35 scratch, just use use Fabric only. This is a good method to start with. If you have other teams, like a dedicated dedicated data engineering team, dedicated to maintaining your systems, you have to listen to their input on this. And that’s where, Tommy, in my opinion, that aspect of management that you’re talking about comes into play. Because if I’m a data engineering team, and we choose Snowflake or Databricks, that’s their choice. This is their right. Is the

16:06 right. Is the company’s senior management strong enough to say, “We will only use Fabric”? This is a decision we will make unilaterally for all data and AI. Maybe it’s a choice that management makes. And again, this is where you , this is where what know what management likes to listen to? what seminars or webinars they attended, what research they conducted on which systems would bring the most value to their company. I think each company can choose for themselves where they think the tools are best suited for their organization.

16:36 organization. Personally, since I’m a Microsoft fan, I’ve been working with this tool since its launch, from day one. I’ve also been using Databricks since day one. And while Databricks is certainly at the forefront of many things, I find Fabric to be a very close, reliable, and powerful tool. It tool. It does a lot of what you need. It scales the way you need it to scale. scale. Most of the things you would do in Databricks already exist or can be done within the Fabric experience. And, ultimately, I notice that when you start to integrate multiple

17:07 integrate multiple systems, there’s always some friction between them. So, can your management unilaterally make a decision to say that we will only use Fabric for the data engineering team and the business business intelligence team? If so, I would recommend having this conversation early to figure out what it will look like, as it will impact, in my opinion, the success of Power BI, and possibly the success of Fabric in the future, through the interaction between different teams. Does what I am describing make sense

17:37 I am describing make sense? ? No, I agree. I think there is a gradual gradual growth factor here, and that’s what I took away from your words. Because I’m actually wondering if Fabric can be ported at all? Or, going back to your previous statement about the process you follow, is this a practice that needs to be developed? Because it’s hard for me to say, “We’re finishing our work on building your architecture,” as you rightly noted. Even if they if they are using Databricks or Snowflake, or they are new to the world of data engineering and

18:07 data engineering and data architecture, can they just be handed Fabric? Or, as you mentioned, is it more of a lengthy process that could take several months? I would say that what you’re describing is a suddenness of the deal or a suddenness of the handover, so in organizations where you’re brand new and haven’t worked much with Fabric, you definitely don’t want to have a sudden handover. You don’t want to just say, “Here, hold on, we’re gone.”

18:37 hold on, we’re gone.” I usually see successful organizations view this as a gradual reduction in my time or involvement so they can take on more more responsibility themselves. So this is a transition from me owning and maintaining the initial version of the project, the pipelines, and everything built in Fabric. And when I hand over this design to an organization, they, first of all, have to have to understand it. Do we understand, Tommy, what you built? Why did you do it that way?

19:07 did you do it that way? How many How many workspaces do you have? What does your your continuous integration and deployment pipeline look like? What exactly are you using? All of this needs to be studied in advance, because Fabric is a slightly different system, and its deployment methods are different from Snowflake or Databricks. They are just different. There are some similarities, but most things are unique. So, given this new knowledge, your company needs to master it all.

19:37 Then they have to start trusting it and building a governance system around this process, which can take time. What if the company already has experience in this area and knows what it is doing to some extent? They ? They were already using notebooks. They already have good have good data quality practices. They already have everything set up for their for their competence center. Then, I think, the transition could be shorter. It becomes sharper. Here, please. Here is your product. And then this team should support him. They may They may skip the skip the collaborative development stage altogether. I can build, they

20:07 can build, they will understand, and we will immediately move to the stage where they build. And then just call me from time to time when time when questions arise. This also works very well. This build phase, Mike, and the decisions you make about its implementation or the direction of the partnership, define everything in terms of terms of handover, because when you start working with Fabric, you only have two main choices. You either want to build everything yourself and we’ll demonstrate

20:37 demonstrate quick wins and the most affordable ways to ways to implement APIs in Lakehouse, use Delta Lake, and build semantic models —I can do it for you in a few weeks; or you choose the gradual learning path, where we will provide training on the Medallion architecture and notebooks, gradually moving towards the result. But whichever solution you choose will determine exactly what the handover will look like, because there are pros and cons to everything, right, Mike? I can come to a client

21:07 come to a client today and, with the right right tools and tools and experience, start building a pretty good Lakehouse by simply loading data from all their sources in a week or two, assuming I understand the processes. But if you make that decision, the organization won’t know what the hell to do with do with these pipelines if they don’t have the relevant experience, right? And even if they have some understanding of Databricks, they still need to understand the Fabric environment. So now you’re widening the gap between what they actually have in their tenant and

21:37 their tenant and how much they own it own it intellectually. And this is important to consider, because the transfer of cases begins with the very first first decision. It does not begin at begin at the end of the project. Well, the bigger that gap, gap, the longer, I the longer,, the longer I would mean, the longer I would recommend recommend collaborating to make the transition and handover happen, right? So,, we’re speaking as consultants for the company, but it could also be an internal matter for the company, right? There’s one team of team of data engineers doing

22:07 data engineers doing a lot of this work inside Fabric, and you want to open access, share, delegate content, or implement self-service for other for other parts of your business, right? The data is coming in, we want to provide it to the finance department. Of course. And what happens when financiers want to create their own pipelines and do their own data engineering? It’s the same concept; I think it’s worth using the using the same approach: a data engineering team comes in and says, “I built the first solution for you, ” and then, “Hey, sales or finance team, now let’s build

22:37 let’s build together.” What exactly do you want to create? Let us help you through this process. process. And so you start helping that team build derivative products based on your data structure. And I think that’s incredibly valuable because now you’re building a process around training, support, and management that become part of the system as you grow. And I think this approach works very well even within the organization. Yes. And for me, the difference between this and Power BI, Mike, is that

23:07 BI, Mike, is that a lot of a lot of the projects that I’ve done with Power BI, at least in the last few years, have not been cases where people were starting out with it for the first time. And, it’s hard to do, because you can create a semantic model,

23:23 semantic model, but if you’re working with a team that’s only built reports using SQL using SQL views, and that’s all their experience, it’s not easy for them to become experts when I hand over this report. And for me, that’s one of the biggest problems, especially when you add the layer that you mentioned— notebooks and pipelines. Well, I also agree with your point, Tommy, don’t I? You are talking about this level from Power BI.

23:54 We’ve had Power BI for 10 years now, right? There are many people who have studied it and learned to work with it. Fabric has only been around for three or less years, maybe four. I don’t remember exactly when it came out, but the Fabric world is much newer. newer. So the likelihood that people have deep experience with Fabric at this point is very low. Few people were there from the very beginning, from day one. We are starting to educate and accumulate more knowledge about best practices. And that’s one of the things that I

24:24 things that I think was key to Fabric. The product needs to be brought to market, and the community at large needs to adopt it and develop its own best practices. This is how we do things. Here’s what works. That’s what is effective. This is how we optimize CU usage, or don’t optimize it; Until the community and perhaps your organization within starts doing this regularly, you won’t gain this knowledge and

24:55 understanding. Moreover, you may be completely familiar with Power BI, having worked in it since 2015, but when you move to Fabric, it doesn’t help you at all to get started with it. Even if you had complete familiarity with models, created reports and dashboards. Of course. And now we’re going to move all of our

25:25 move all of our data engineering and everything else to Fabric. Maybe it will help by 5%, but I don’t think your ability to transfer work using medallion architecture notebooks helps much. So you can have a team that has all the experience that I think you… No, I disagree here. Your 10 . Your 10 years of work in Power BI, you were involved in data modeling and Power Query. You built You built tables and structures there. You’ve done more complex things inside Power. Okay, the environment is changing, right?

25:55 is changing, right? The environment is no longer Power Query. Now it’s pipelines and notebooks or SQL data warehouses. OK. Yes, it’s more technical, more code. I understand that. But the concepts, the principles… and we’re moving, Tommy, I think we’re moving largely away from the need for people to actually write code for something. The number of times I’ve built apps where I’ve physically written code—I do that less and less, but I have

26:25 less and less, but I have a lot more control over the process, right? It’s more about describing what I want, letting the AI find the best system to system to accomplish that task. And so as we move forward, we’re moving towards an era where we’re going to be more driven by AI to help us help us build these systems. So let’s talk about that, because I wrote it down, Mike, because I think that’s another important piece as we look at the transfer of cases. Mike, is AI

26:55 cases. Mike, is AI intellectual property considered part of the transfer? Because if I’m using agent solutions that I’ve built and that are the intellectual property of my consulting firm, which I use to help to help pipeline everything, or if I’ve built different skills for this particular project, which is what I’m doing, right? the skills that I write, the agent skills to help with certain pipelines, understanding the context that I’ve created for

27:25 that I’ve created for this company, whether it’s in a harness or somewhere in a repository that has instructions, schema, and validation, and when I actually build using using agent solutions, should that be part of the transfer, or at least part of the training, right? And I think I don’t know the answer to that question yet, but I think eventually we’ll have to answer it. Well, I’m going to bring you back with another question that I think will help shed light on whether or not this is even a real

27:55 even a real need, right? Does the company you work for allow its team members to use AI at all? What is their position on AI? What AI are they currently allowed allowed to use? to use? Do their team members even understand how to use AI? This is a whole new skill set that we are implementing here. Yes, , we are not removing engineering from these systems. We do not claim this. AI simply significantly speeds up the engineering process. And the bottleneck in AI is shifting from writing code to

28:25 writing code to testing and validating its correctness. So we just moved that bottleneck to another part. So, have we solved the problem of building systems using AI agents? No, we haven’t solved it, because we’ve only solved the first part: AI can write 150 or,, 10, 000 lines of new code in 2 minutes. Perfectly. Check this out. What is correct? What is true? So this verification process still needs some thought. We have not decided the next stage of this

28:56 next stage of this process. That’s why,, I’m saying this. Yes, you can give people prompts for days. You can give them documentation on prompts for days. Will they be able to read it, will they be able to use it use it and learn from it in a way that will help them? I would say that many organizations are not ready for this yet, Tommy, right? They have no way of understanding this now because they haven’t taken the time to train the team or encouraged them to learn about AI and how to use it. use it. But that’s not my concern,

29:26 But that’s not my concern, Mike. I understand what you mean. But from a business case perspective, if it’s an integral part of part of building quickly, managing pipelines or notebooks, and you’re not using it, using it, I’m sorry, but that’s not necessarily my problem, because that’s the era we era we live in. And if I use something agency-based, that should also be part of the handover. It’s not just saying, “I did all this, created the proper context for you.” If you choose not to use AI,

29:57 to use AI, it’s the same as saying, “I used the Fabric API and development infrastructure to help build your stuff.” If you want want to use only the interface and not the API, that’s your choice. I think there’s something to argue about here too. Do . Do you like it? Yes. . No, I don’t know. I No, I don’t know., mean, yes. I don’t know the answer. OK. I’m trying to respond to your comment on this. Do what place AI occupies here? Again, I’ll , I’ll take the example I gave again. If I use

30:28 developer tools and ID, if I give you a Ferrari, Tommy, and you can’t even drive a car, why do you need this Ferrari, here’s my analogy. For me, prompts and AI-related things are the Ferrari of getting things done. It’s fast. So, I shouldn’t use AI at all? I’m not saying you shouldn’t use it. I’m talking about delegating things: you can give them give them tools, like if you gave an electrician a bunch of carpentry carpentry tools and tools and said, “Go do the wiring in the house.”

30:58 the wiring in the house.” Ineffective, useless, useless, right? right? I have the wrong tools for the part of the job we’re doing, right? So, I’m not saying that AI is the wrong

31:10 wrong tool in this situation, I’m saying that you’re giving the masters the wrong tool. Which they don’t know how to use yet. And I think even we, Tommy, if we’re being realistic, we’re still trying to trying to figure out what it means to be an AI engineer. I just watched a documentary about VS Code., that’s it. Oh, yes. She was wonderful. Yes. This was last Friday. We watched it live together. A . A wonderful wonderful documentary. But the first hour of the film is dedicated to the story. And then we

31:41 story. And then we get to the point where AI appears. M-hm. M-hm. And the documentary literally says, “Well, we don’t really know what know what users users need from AI.” The user knows that they want to use AI, but the interface, the UI, is how they work with the code. People don’t really understand. We are entering a completely new era where we have no requirements for what it should look like. And so, because even in

32:11 because even in the field of AI, the people who are actually creating things with AI don’t know themselves what it should look like. So how in the name of God are we going to give an organization a bunch of prompts and say, ” Here’s a bunch of prompts and AI”? They don’t understand how to use it. The tool is too powerful. They don’t even understand what’s going on there. So, I’m not saying that you shouldn’t do it. Perhaps this will even be an advantage. Let me put it this way. If I’m Tommy and I’m in this situation, and I’m using agent capabilities to build things, or using agents to create something

32:42 to create something like agents, right? This is part of the transition. This is part of the learning. This plays into the management strategy you’re talking about. Mm. Mm. And this becomes a very strong argument for selling to the client. Like, “Look, I’m looking into the future.” Yes. You don’t know Fabric, and you don’t even know how Fabric and AI work together effectively. So part of our work in this project is not only to tell you about the world of Fabric, but also to show you how to use Fabric

33:12 to use Fabric 2. 0, how to do everything super fast with an agent by your side, as a co-author, as a as a friend, as a programming partner. I think that’s where the real real value lies. So I guess yeah Tommy, you’re still selling it. Yes, you still provide it to the customer, but you use it as an opportunity for upselling. I would agree with that to some extent. Again, I would still insist that AI toolkits belong in the realm of development. Just like

33:42 development. Just like when I connect a new client, I have a checklist for setting up Fabric: for example, creating a service principal. Enabling certain API settings so we can work can work efficiently. But the thing is, if they , if they refuse refuse to use these tools, APIs, or XMLA endpoints, and are are only going to use the interface and Power BI Desktop as is, then my help is limited. I can explain to them that we use an IDE, a

34:12 version control system, and tools to tools to edit many edit many elements because these are best practices and that is the role of a developer. But again, there is a concern that is it worth starting with this? Are you really emphasizing this? Do you offer you offer agent development right away, or do you do it gradually? You mean Well, again, it’s an assessment of how much you understand what the company company or your department is willing to accept. Yes? If I go to the finance department and they’re not allowed to use AI and they don’t understand how

34:42 they don’t understand how it works. They are not used to prompts. It’s frustrating for them when when they encounter this. This is not a sales pitch. This is not added value. value. If you come to the team and they say, “We expect you to just click on the interface.” You need to first understand the essence of your client and come to them with where they are now, what stage they are at, right? right? Let’s not make the mistake of thinking that AI provision is the only part of the box. I

35:14 part of the box. I think it’s part of the package, right? Along with documentation, co-creation, and training. I think there’s an element when they unwrap this gift, this transmission box, that there’s an element of using AI with the tools that you have. Don’t start with that, don’t say you say you can’t do can’t do your job without these AI tools. This is an incorrect incorrect statement. And I think that would be more than more than misleading. But I would like to ask, I would like to like to ask my ask my client first before doing anything. Isn’t that right

35:45 doing anything. Isn’t that right? Part of my requirements or part of the project setup would be good: tell me what your expectations are for what the outcome of this looks like. Is n’t that right? Do you expect us to go to fabric. com, click around, and make something work? If that’s your expectation, I’ll ask: well, did that there’s another experience, this is the Agentics experience with VS Code? I can communicate with agents and they can do things on my behalf. Do about MCP about MCP servers? Do about MCP fabric servers? Do about

36:15 about PowerBI MCP Modeling Server? Are you using you using skills? If the answer to any of these questions is “no,” we “no,” we don’t understand it and you’re not willing to spend the time to learn it. I think the AI ​​story you’re creating will go unnoticed. And this incredible value that you bring cannot be accepted as a gift. They simply won’t be able to truly appreciate it. And honestly, if the organization says “no,

36:45 the organization says “no, ” we want you to— we’ll pay you just for working in our interface and browser. browser. Not sure if that’s appropriate, because honestly, you could hire someone much cheaper to do it., do it., just going into the interface and doing all the development so slowly. I wonder why you say that, Tommy, because would you have turned down the project if they had said that? Yes. That’s what this is all potentially going to lead to. Hey

37:15 potentially going to lead to. Hey Tommy, I need you to go and go and create a fabric experience. Would you let a client ask you to build something and say, “We’re not comfortable using using any AI, anything you build has to be in our systems. No AI help.” I ‘ll be honest, would you refuse such a project? I would inform them that it would probably cost three times as much due to the significantly greater time involved. Okay, fine. I’m glad you responded that way. Yes. Yes. I could also say, “I’ll do whatever you want,

37:45 you want, client, but it’ll take twice or three times as long, so , so it’ll be more expensive in the long run.” Got it. Yes. And it will take a lot of time. One hundred percent. This will take much more time. Time, like, time is getting longer. Yes. The terms are longer and you pay significantly more. And why do you need this? So, okay. I think we touched on a lot of things. So . So let’s, as we get closer to the end, what’s included in your handover package , if I’m trying to think of a better name for it, your handover handover handover, handover,, your “bill of rights” or handover plan

38:15 or handover plan. What is part of your list of things you always do, in terms of materials? I’m always curious about how consultants do it, because as you rightly point out, there’s the ” we’re we’re going to build together” side of meetings, “I’ll show you,” “we ‘ll train you.” But there are a lot of elements that I go back to when I was in the state and always wanted consultants to provide, right? Because they usually gave me a “black box”, which

38:45 “black box”, which I don’t do for my clients because it was very tiring. So for me, there is a basic package, a guide with certain elements of documentation that I always want to provide before closing our

38:58 closing our project. Mike, what are the essential elements you always include, regardless of the size of the project, that you always add for clients? , well, my non- non- negotiable requirements are: every meeting is recorded, every meeting is transcribed, and you get access to all of those meetings. For me, this is non- negotiable. ., again, , again, the customer is the main thing, right? If they don’t want

39:28 ? If they don’t want to use AI in a particular project, great. We don’t use it. Or if they want to provide their own, that’s even better, right? A lot of clients are now saying, “We want to own the prompts. We want to understand what you’re building. We want to see a little bit more of what’s behind the scenes, how consultants are building things. And again, this is intellectual property that we’ve been developing and refining refining over a period of time around AI. I understand why clients want to see this. see this. The amount of information that can be generated by this is

39:59 generated by this is probably too much for many organizations to parse through and get get value from. It’s more of a knowledge base. It’s more of a database. It’s more like a wiki, wiki, right? So it’s more like, here’s a bunch of stuff that we’ve done. You done. You at least need to know that this is where where the information came from, and then you can you can go back to it, reference it, etc. etc. Back. Yeah. Keep going. So in So in a month or two, when you have the same question, like, “I thought we talked about this with Mike” or “we did something.” Let’s

40:29 did something.” Let’s let’s go back and retrace that. Let’s see what that looks like. And so for me, this part is where we’re we’re coming from. Mike, to your point, I I used to use Atlassian’s Confluence and tools tools like SharePoint. No more Confluence. No, no, no more Confluence. Their AI is not very good. But it was essentially a competency center for them or a knowledge center where all the resources were stored, the , the data validation schemas, the metric definitions, the minutes of our meetings, and in a sense it was an organized organized catalog of all the

40:59 catalog of all the resources that we had created. So they could look there for information, and they had access to it for 3 months after after the project was completed, they could review it, and the duration of access we can discuss. But I think it’s just an important part of the project handover. But when we look at Fabric specifically, I again, I again, as more and more projects on Fabric are completed, I try to reach out to my clients after 30, 60, 90 days. And I I always want to know if they think we’ve successfully handed off the project, and I know there’s

41:29 project, and I know there’s no perfect answer here, right? There’s never been a time when there’s been no problems at all. There’s always going to be some fires. But when you look at those one, two, three months after the project is done, Mike, for me I always look at it from a handoff perspective. And the reviews are very important when I think about handoffs. You can, as you said, provide all the documentation, the wiki pages, and the videos, but nothing replaces answering questions. So I

42:00 questions. So I always try to have to have weekly weekly Q& Q& A sessions with them even after after the project is done. That’s the only thing I do. I’m not doing doing the implementation anymore, as we were in the terms of our collaboration, but I’m just working with them and helping answer answer questions after we’ve done the training and everything. I want to make sure that they’re ready to succeed. And that’s what I’m trying to do. Hopefully, in the first two months, we can complete these sessions when they’re ready to learn on their own. I own. I try to help

42:30 try to help them with organizational roles and responsibilities. That’s another part of my handover. But Mike, I’ll turn it over to you to you to talk about your 30-60-90 days after the handover. What elements of success are most important to you? Yeah, I think I would tend to say that my success metrics are no news from the client. No news No news is good news.. So there are two ways I look at it.

43:00 I look at it. One is, if I’ve done a good handover handover, they don’t come back to me. And if I’ve done a good job of transitioning and handing over, we get another project, maybe a little more difficult than the last one.. So repeat So repeat business is a great indicator that you’ve done a good job. They’ve liked your work enough. You haven’t done too much, but you haven’t done too little, and they’re coming back for more. more. So to me, So to me, repeat business is an indicator of a successful business. And I think that The same principle applies here

43:31 same principle applies here. We’re talking about about business consultants. Take that approach and apply it to internal teams working with other internal internal teams. Great point. Right? If you’re working with another team, helping them implement something, they should be able to work independently. Good delegation is when they don’t come back with questions. They figure things out on their own. They do everything themselves. At some point, they have to take take ownership of what they’ve built or what you’ve handed them over. They have to own it going forward. Finance Finance has to be responsible for

44:01 has to be responsible for their pipelines. And if something breaks, it’s their their responsibility. If they create bad data, it’s their fault. They’ve built a system and a process that works with that. When they have problems, they come back to us. They come back to our our competency center and ask new ask new questions.,, if they have a new new challenge or a new project, they come to the competency center and They say, “Look, the first project was successful. We want to scale it to projects two and three. Let’s scale that up.” So, repeat business is now the measure of success. So that’s how

44:31 the measure of success. So that’s how I would I would measure the success of things. things. I like that. I like that. Mike, great conversation. I think as Fabric evolves, some of that will change. I’d like to meet with you in three months. I’ll do a reminder about what the handover to AI looks like, because I think we’re going to be talking about this for a long time. But Mike, thanks for the conversation., I just want to say that I totally agree with you. A good business is a business that people come back to. But the most important thing is to

45:02 But the most important thing is to prepare people for success, because Fabric is going to require a lot of support. It’s new to everyone, let’s not forget that. Yeah, I think it does. And I also think that Fabric does what Power BI did for data and analytics. You get a more powerful tool, tool, accessible to more more people in the organization, no exceptions. It’s easier to set up. It’s hard to put all the pieces together. So the knowledge is still required, but it

45:32 required, but it democratizes engineering and analytics on a much larger scale. So you don’t have to write a lot of code. That’s the point. You’re going to going to use new use new tools, and they’re going to be more accessible to more to more people. It’s a management decision. You have to think about it and work with your team your team to educate them. That’s a good thing. Final thoughts for today. We’re going to keep this episode short. Tommy, where else can you find the podcast?

46:02 find the podcast? You can find us on Apple, Spotify, wherever you listen to podcasts. Make sure Make sure to subscribe and leave a rating. It helps us a lot. Have a question, an idea, or a topic you want us to cover in a future episode? Go to Go to PowerBI. tips/podcast. Leave your name and a question of interest. And finally, finally, join us live every Tuesday and every Thursday at AM Central Time on all on all PowerBI. tips social channels. Thanks everyone, see you see you next time. metrics. Raise the bar higher. Tommy and

46:32 the bar higher. Tommy and Mike light up the sky. Dance until dawn, laugh to the beat. Fabrics and AI—your dope today. Expressive measures. Turn on the beat now. Pockets won’t steal the crowd.

Thank You

Want to catch us live? Join every Tuesday and Thursday at 7:30 AM Central on YouTube and LinkedIn.

Got a question? Head to powerbi.tips/empodcast and submit your topic ideas.

Listen on Spotify, Apple Podcasts, or wherever you get your podcasts.