A (2:05)

I believe so.

B (2:06)

No. Let the record.

A (2:07)

Let me check the notes from our process.

B (2:09)

We have a process for this and we recorded this.

C (2:13)

But.

B (2:14)

But I think, you know, you know, as we look into this sort of thing, like, talk to a little bit, kick us off a little bit about where you've seen process maybe not work so well or not. Where a lack of process has affected you and your work. Maybe let's start with that and then we'll kind of like wind up from there.

A (2:34)

Oh, wow.

B (2:36)

Or if you prefer to do positive, you could give an example of where you saw a great process work. And you could be like, oh, I'm so awesome that I created this amazing process. But I was going to let you save that for later in the show. Problems Then Solution, A transformative art narrative arc for your character in the podcast.

E (2:57)

All right, well, to open this up, I guess my first thoughts on process, I will say it's been interesting because Every client I work on, our process is slightly different. You'd like to think we set up a repeatable process and, you know, we're going to come to a conclusion that this is really effective and we're just going to keep rolling with it. But every client brings kind of their own process to the table. So I will say that I was. I am really excited about this discussion because I've seen it where certain clients have a ton of process and it just slows us down immensely or they want to automate a lot of the process, like, do everything asynchronously. And, you know, you have to have a lot of technology and tools and logins and interfaces to, like, communicate between us and their team. And it's amazing how, like, they're trying to do it for effectiveness and clarity, and it slows us way down. And I think a lot of times it burdens us where we lose the ability to have, like, a personal relationship with them. And then on the other extreme, when there's no process, it does feel like you're kind of like flying by the seat of your pants. And sometimes it's a little chaotic. So I've definitely seen the gamut, the spread.

C (4:15)

Sorry, Julie, when you say no process, like, can you describe what that looks like? Because I also like, my new process would probably look quite different to your experience, like working with different clients. But what does a client with no process look like for the team?

E (4:32)

Ones that don't really love even like a weekly cadence touch point. They're like, we'll reach out when we want to reach out. And you get like the chaotic random email. And then the team is scrambling and it's a little unclear who your exact, you know, direct stakeholder is. Some of them are like, oh, well, I told my coworker just to directly email you. And we're like, we don't know who this is. Are we allowed to pick this up and do it? Can we schedule time with you? I now have to loop back with the stakeholder. So that's kind of my experience of what I'd call no process.

A (5:06)

I mean, it seems like there's from like an analytical intake. There are cases where, like, to me, one extreme is when it's assuming you have. This is a person who I am supposed to address their needs as an analyst. So we are going to meet and have a conversation, and I will uncover the requirements and the need and the underlying problem, and we'll kind of conversationally, kind of process free, gather the requirements, and then I will go back and execute like that's like no process. And it's efficient or low process and it can be efficient. The kicker is that when you roll with that and you have different people not necessarily having enough of a discussion and then something gets missed. A timeline isn't communicated or a scope or a time frame, I've seen it start to swing in the other direction. It's like, well, now when you meet with the. Sure, sure, sure, we still want you to meet with the stakeholder, but here's the form. And you got to make sure that everything on this, this brief or this intake form or whatever it is is sort of filled out. And there are times where it gets to like, but some of this stuff isn't relevant, but it's a required field no matter what that intake is. And it tries to make the process. And I'm thinking specifically on kind of analysis projects, intake, not necessarily implementation or others, it can get to where. Well, now you've removed judgment because you said, well, we had one issue one time, let's now inject more structure into the process. And that's how processes become bloated. Because you're trying to say, well, we want to keep shedding every possible crack and now we've built something that is a cumbersome, formulaic way to do something. So those are on my two extremes.

E (7:02)

If the other side is we got to talk about every single thing and it's very super organic and we have nothing, quote, unquote, like repeatable. If that's the spectrum, I'm, I'm going towards the secondary one. Like the more like organic. I don't know if that's right, but I definitely prefer that over the like, God for oh my God. If they're like, we want to work with you and Jira, we'll just send you tickets. I'm like, get me off this flipping project, I'm done. I hear those words and I'm like, no, no thanks.

B (7:30)

I have a saying. I say just enough process and no more. So it's just as much as you need and not more than that.

C (7:40)

But how do you know you've hit that?

A (7:42)

You don't. But that's like saying building a model and saying you're going to have Type 1 and Type 2 errors, right? You're going to have cases where you have too much.

B (7:48)

If I still like it, it's okay. If I don't like it, it's too much. Super objective, scientific. Yeah, it works.

A (7:59)

Well, that does remind me, I mean, the quick example and this wasn't a client. This was somebody who we were talking to for quite a long time about potentially being a client, the head of analytics. And they had gone down the JIRA ticketing process because they felt like their team was having spend too much time having those organic conversations. So it's a logical step to say, oh, we'll make this asynchronous and put a form in. I've been for years. I think those always end up in the same spot. And this is where this company was living and that they were just dying death by a thousand cuts because they were just getting requests lobbed at them and people were getting them in as fast as they could because they knew it was going into a queue and they were trying to turn something into this machine that shouldn't be a machine. And he's like, we're just overloaded by these requests and every request we get that comes in, we're going to have 10 iterations of back and forth before we're actually done with them anyways.

C (9:07)

Yeah, it's like, but, yeah, but isn't that, isn't that okay? I have been like doing some serious soul searching on both planning and processing because I am definitely Julie, when you describe the very non processing world that is like my mecca where I live and operate. And it is not.

B (9:32)

I think there's a personality component to it for sure.

C (9:35)

But the thing that I have been grappling with is like I think that there is a like a process component. And process is such a like loaded word. But like I'm particularly thinking we've said this multiple times now of like tickets going in and they go in a queue. Like that to me is not a process. That to me is a like way of working, which is not a way of working that I want. And so JIRA can be a way that you can manage tasks. But for me the I like the problem is when that then becomes this is how we engage with our stakeholders. And like I violently hate this whole like service desk mentality. I believe in like data folks being business partners and I do not think submitting tickets actually is the right way of working even if you want to use tickets for task management. And so like we actually, I've always said like team leads can decide if they want to use JIRA or any other task management. I don't give a shit. It's not my like thing. We've now agreed as a team we're all going to use it. But like it is more about us as a team being able to make prioritization decisions than like stakeholders thinking anything I ask for is going to get done goes to the back of the queue. I can just ask for whatever the fuck I want, even if it's going to add no value. But I'm like still processing all this.

A (10:58)

Well, that's a good point. That's the tool for being used as an intake. As part of the. As the intake process or as the resource. As a tool within the resource management and availability and prioritization process.

D (11:12)

I was going to say. Well, I was going to admit rather that, hi, my name is Val Kroll and I'm a recovering implementing tickets in front of my analytics team person. But I will say, and Tim and I actually went a couple rounds on this over dinner one time when we were on site with the client.

A (11:29)

I do recall, I think there's trauma with a couple of. Yeah.

D (11:33)

With the capital T. Some people who are witnessing that, some other people who had tickets to that show. Yes. But what I realized was, well, so contextually I was standing up a program for the first time ever. And so there was also like a lot of novelty to the data that was now available. And so there was a lot of like, this would be interesting or could you tell me if questions.

A (11:54)

Right.

D (11:54)

And so when I was putting that system in place, what I actually realized now years later is I was actually itching more for. It was only however many minutes into the episode before we said the analysis planning document, the one that Julie that I referenced. This is probably the sixth episode where I've referenced that thing. And so the analysis planning document, for those who have not had the pleasure, we will link it again in the show notes. It talks a lot about what is needed from this analysis.

E (12:24)

Right.

D (12:24)

Like putting some boundaries around the hypothesis and time frames and just kind of really getting a broader understanding and kind of asking the business partner to be thoughtful about exactly what they're looking for. And like, how is this going to help them, support them? There's a meeting coming up, whatever. So I wanted some of that documented to help foster the conversation that always happened before we picked up a ticket. So to your point, Mo about like interfacing with your stakeholders, it never, it never, never replaced a thoughtful conversation, like as a partner. But I have to admit that I definitely was like, oh, this is how I'll operationalize this team. Because I had like, people growing my team. It was just me at first, and then it was four of us. And I was like, how do I manage this? Like, I'm not touching all these stakeholders. So, so for everyone out there who's done it, like, just know that there's another side. We're not, we're not shaming you.

B (13:22)

Hey, quick question. When was the last time you really unplugged? Like inbox, zero phone on, do not disturb, toes in the sand kind of unplugged? With five Tran, that dream doesn't have to wait till retirement. Their automated data integration means your pipelines run smoothly even when you're on the beach with a book in one hand and a drink in the other. 5 Tran handles the heavy lifting. Sync your data from all your sources into your warehouse reliably and continuously. No babysitting required, no custom scripts, no last minute dashboard breakage. Just dependable pipelines to give you peace of mind. So go ahead, take that long weekend. Heck, take the full week. Fivetran's got it covered. Visit fivetran.comaph you can see an interactive demo or sign up for a free trial that is F I V E T-A-N.comaph5tran data in, decisions out. Mo said something that I think is really important distinction, which is you can have a ticketing system, but don't use that as the means of communication. Yes, like communication happens out in another sphere and then you manage the task and you can communicate within it. Like, you know, like, is this your right idea? But like, there should be layers to this. So your process should incorporate not just I submitted a ticket, but more like I then connected the overarching purpose for this to it and then the ticket supports it. If you have a system like that, you put in, you know, some intake.

A (15:03)

System for tickets or some sort of, some sort of atomic or granular management of what is the work that we're doing has, has a lot of value. When you look back at the end of a quarter, the end of a year. I mean, that I've seen as well where it's like the team keeps growing because it's just emails coming in and when somebody says, what do we actually do? And it's like, well, let me go through the network drive folders and let me sift through my email. And all of a sudden now you actually can't even. You're not generating good data on the work that you're doing. Not that you're just trying to count volume of work, but sort of forcing you to think about the nature of what types of work you're doing, who you're doing it for, what value it delivered. All of that goes towards having a data orientation, I think to the work that's being done. I mean it is why I. And I know I fall on a weird extreme on many dimensions, but it's like tracking time. Even when I have not been working somewhere that I've been required to track time. Even when I wasn't working at all, I was tracking time, but I was shifting that around.

D (16:20)

Psycho.

A (16:21)

Saying anything. No one's like, there's some facial expression normal. But whether it's. Yeah, so I mean, maybe not.

E (16:33)

I mean, they're teasing.

A (16:34)

Well, I'll stop.

D (16:35)

No, no, but why is the thought like, why did you do it? Yeah, yeah, we're just giving you a hard time.

A (16:41)

Well, I'm tracking time because I will go back and say this, feel like this is taking an inordinate amount of my time. Is it? How often am I doing it? I have to have that information somewhere, which, I mean there have been cases where there have been time tracking that's enforced like purely for, you know, billing clients. And that doesn't actually tell me some of the non billable stuff that I do that I actually do want to know. I spend a fair amount of time on a podcast, I spend a fair amount of time on a local meetup. I spend, I don't. Not all parts of my life. There is kind of a professional, personal boundary. I'm not, not tracking like, you know, quality time with my wife.

D (17:23)

Non quality time with your wife. You flip it.

A (17:25)

Not quality time. Yes. Two different, two different tasks, two different codes. Yeah, but I think, I think when it goes in, I mean maybe like, like mo. How do you're. It sounds like you're. It's kind of delegated to your team. But when it comes to the, the work, there's always going to be more work that could be done than can be done. And when it comes to prioritizing and managing and that's always going to be shifting the priorities today are going to be different than tomorrow. Like, how do you see that as a process by which the team doesn't just get run ragged and what's it look like?

C (18:10)

Yeah, so we, I've been taking feedback on this and trying to improve. So there's been lots of really robust conversations probably since about, I don't know, maybe three months ago. And so what we've decided for the second half of this year was to do like very rigorous planning. So a lot of, a lot of data folks at Canva are more embedded in product teams. And so it's kind of easy. You have a product manager, we have technical program managers. Who help with this sort of stuff. In marketing, we kind of run to the beat of our own drums, so it's a bit unique. And we were just like, you know what, we're going to really throw everything at the wall here and see what are all the things that we know that we need to do, basically in half two, what are the things we want to do, all that sort of stuff. And so our planning cycle was really intensive and then we broke it down. We like, we like big buckets and themes of work that we wanted to do for different areas because like we have one team that build tooling and some that are doing more like strategic analytics and that sort of thing. And then we bucketed it all out. We had to do some really ruthless prioritization because we do have some teams that are just under resourced and it's taken too long to get headcount and things like that. And we went to our stakeholders and we're like, this is what we're planning for H2. Every time you come to it, like, this has all of the things you've asked us for, by the way, already baked in. And anytime you come to us in H2, when you ask for something that's not on this list, we're going to ask you to cut something else from it. And like, I mean we had one team where we had to cut like 50% of their work just because of headcount stuff. And so we went through it with the stakeholder and it was, yeah, highly entertaining because sometimes stakeholders don't realize that they're the problem. They're like, oh, but like, just tell me who the team is asking for all this ad hoc stuff. And I'm like, that would be you, but can't really say that quite so directly. But I, I think the, the thing that we're really trying to shift, like I said, I, I've always felt like data is like a partnership model, but it's like we're not going to prioritize on your behalf. Like we're going to do this together and we're going to come up with a list. And so then therefore, when you want something else, that's okay, and we will happily do that, but then we need to drop something else. And I think the thing that I've probably most enjoyed about it, which the team are pretty good at, but it's kind of solidified it is even some of our teams that are super ad hoc and reactive, which is the nature of their work, have gone through this process now and really Been able to kind of give more thought and color to the things that they're doing that might be helping them with a promotion or these are the projects that I want to be working on as part of my growth and development plans. And yeah, it's fucking annoying, but apparently doing process stuff is good.

A (20:53)

Well, so in that specific. Because what I feel like I've run into at times, typically there's just for simplicity, say there's one analyst and they're supporting a team that has four people and a manager on it, which is super, super simplistic and that sort of prioritization is done. But the fact is the two different people on that team, but more often than not it's like two other groups or sub departments that they have their priorities. And so when somebody comes in and says, but this is really burning and it's like, well what are you going to. You can't just ask them what you're going to drop. Because they could say well yeah, drop that thing for that other group because I don't give a shit about it. I mean, not overtly, but they don't. Like, do you have to, if that sort of cutting something happens, this is where I've never found the great way to do it. Do you have to keep going up the chain and keep pulling in some more senior person to say your team isn't capable of making this judgment call? You're going to have to step in and tell person X that their thing's getting cut because person Y's thing now supersedes it.

C (22:05)

Column A and column B. Like generally like a team lead does have a relationship with the like quote unquote manager of like in this hypothetical situation there's four people. So they could be like person X's thing is more important than person Y's. But the reality is the manager in most cases is like, actually my thing that's item A is more important than either of their two things. So I don't give a shit about those. And that like that's what we've started to work towards because I think we did also really have that other format of like trying to please person X and person Y. And it just doesn't work because like you end up building stuff that is very like or doing analysis that's very bespoke and it serves one person. And like, I think the biggest like shift in our direction is being like if it is for one person ad hoc, non repeatable, like not connected to a company, we're saying no, it has to service multiple Teams, multiple groups. When we build it, we want to build something that's reusable or it could be adjusted for a different use case, I don't know. But I feel like I'm preaching to the choir, at least for me.

E (23:11)

I'm working with smaller stakeholder groups where with you you're kind of seeing the whole beast of it. Your scale of the team you're talking about is so different than the scale of team I work on, even if you count my stakeholders plus my internal teams, you know what I mean? So I was really curious to hear how you guys do manage that to Tim's point.

B (23:34)

Well, and I think in smaller or less scaled organizations, mo, what happens is people don't haven't faced that actual boundary and so they're still trying to do all of the one offs as if they were just as important as the structural or multi team or business strategy focused types of work. And, and there's nobody giving any delineation between, okay, this is sort of like a nice to have versus a must have and they seem equally important and people are getting run off their feet and burnt out completely in organizations that aren't trying to make those distinctions because analysts are just trying to do everything for everybody, which there's an unending amount of interest on specific topics that may or may not actually have any worth in terms of the time it takes to go and pull the data together, do the analysis, present it back.

C (24:32)

I did actually come up with a framework which I shared with the team and I'm happy to share in the show notes afterwards of when we came up with this whole body of work of things that we need to do in H2, we actually scored every single thing on there. And one of them is strategic impact. One of them is like, I can't remember the name, it's like multiplying effects. So like is this servicing one person or like a team of people? And the last one which actually became the most important I called like DS uniqueness. So like we would score it a one if like a marketer could pull the report themselves if they really had to. I would mark it a five. If like it's building an mmm and it's doing, you know, QA on the data coming from this platform. And it like only a data data scientist can do that specific task. And so we had this kind of. And we've shared it with the team now and like when you get something and you do the eyeball check and you feel like this task is like sitting at the ones you shouldn't be doing it. It should be sitting at like three plus across all those three different pillars. And like, that's kind of how we're trying to think about it. Like I said, I'll let you know in like a year if I still have a job.

B (25:43)

Yeah.

A (25:44)

Because.

B (25:44)

Yeah. Well, how do you score it? If the question is, well, the CEO.

C (25:48)

Wants it, but that's strategic impact. And that's actually one of the criteria of like, has like a founder or an investor asked for this or is it connected to a company level goal and then you would score that like a five. Because yes, that, that does have huge strategic impact and a thing that we need to do.

A (26:03)

To me, that is having gone through various, I mean, going back years having, having put in the scoring, I've always thought the scoring is like, you need to figure out, you kind of need to run organically with people that you know and trust and are kind of thinking about the business. And then what you're trying to do is just enough, not too much, Michael, kind of codify that and say, what really are the decision points? And it's like that strategic one is always going to crop up. And then I do think there's a part of it that says you have to run it and have the discipline to say, six months or a year down the road, is this working? How are people, how are we ourselves gaming the system? Because we're bumping up the score here? Because we just know this thing needs to happen. Even when you do the scoring, presumably you're not saying, and then you get the score and we sort and chug away. It's like, that's a way to. I love the way you just framed it. Like if you're eyeballing it and you've got ones and twos on stuff you're working on, you need to kind of stop and ask why? And it may be, oh, I'm falling back into a bad habit trying to keep the squeaky wheel happy. Or it may be, no, these really need to be done and this framework isn't capturing it. And we need to kind of make a note of that and refine our process. Right.

E (27:24)

Does scoping come into it at all, Mo? Or is that like, note you, you use the framework you talked about. Yeah, because I'm just thinking, like, what if you do identify, like the top five things that really have to happen in this team, like, these are things that would be the best for them to tackle, but then you get to actually scoping it and this amount of work and Your capacity to do the work and it's not going to fit in the time period that like is realistic. So then is that like a secondary part of you guys after you've done your intake and priority, then it's scoping in like another round of prioritization or is that part of your.

C (28:01)

To be fair, it was a little complex because we did include that. We did have, I think we had a time estimate but they were very rough. And also because we're trying to plan out work for such a big team over a six month period, we were also talking about in tasks in days and weeks, not hour blocks. And so there was a component of that. But then it would be more about if something scores really highly and this person or this team doesn't have capacity for it. But we know that it's on our list to do. How do we move resources or that particular task to a different team to make sure we can cover it?

A (28:39)

Can we shift to what happens when it gets scoped? And the scope is it's always going to be low, it's always going to undershoot. But when something you get into it and there's a commitment to we're going to do this project and then all of a sudden you realize oh my God, like the data cleanup for this, like we just did not see this hot mess. This is going to be 4x the level of effort. What's the process? I'll say it for getting back to do. You just keep plowing ahead, say we're going to suck it up and do it and figure it out or Tim.

C (29:17)

Are you asking me the question? Because like when did this conversation get turned around? Because like I am not the process person and like every keep saying that.

A (29:26)

But you have all this, you have all these thoughts where you're like well here's the, here's the mental and actual and reality process step by step how I approach this. But I don't like process. Let me tell you about the four part framework we have.

C (29:41)

I also said to my team leads like here are some guiding principles. But also I'm shit at this. So like I need you guys to lean in and help. And they honestly did a phenomenal job. I am not the process person, but.

B (29:52)

I think like me. I think like me. Mo you think about process in terms of like the value it can create when applied correctly and, and given to the, the, the challenges that your team is facing.

A (30:05)

Right.

B (30:06)

So like that's kind of the way I look at it.

A (30:08)

Well, maybe let me side rant on this for this is not a. I don't think if it's process for the sake of process in many organizations, especially larger enterprises, wind up in that world where they're operating. I had a lady working for me who, she didn't care if she delivered business value ever, as long as she followed the umpteen gazillion steps in a wildly over bloated process. She knew that was going to be her way to get ahead in the organization. That's problematic. I look at actually my wife's Measure Camp New York presentation about process where she's like, she called out that there is a process. Now there are levels of how much you've codified it and documented, but everyone is following processes all the time. It's a matter of when an inefficiency is being identified or a problem. And there are lots of getting into heavy process stuff. There are certainly Six Sigma and all those worlds to really diagnose them. But I don't want it to turn around. Like I'm not a process person. Like, no, everybody's a process person whether they realize it or not. I don't think you can function like you have a process. There is an innate organic. You run into these things all the time and there is a way of reacting to them. It's not like, well, on Tuesday, today I feel like we're carrier pigeons. Can be the way that we get intake requests and on Wednesday, you know what we should do is we should figure out what our business needs, right? So I don't know, maybe that's my side rant is like, recognize process is there. It's useful to recognize that.

B (31:52)

And I think what we're talking about is sort of like expanding the process out beyond the individual. So in other words, you take your process and you push it out across a team or across a function and you say, okay, this is the way we're going to execute this all the time. And a lot of times people like me who say I'm not a big fan of process, it means that I don't externalize my process. Well, that's actually what I'm trying to say is I have a process like you just said, Tim, but my process is sort of like very intuitive. And so a lot of times it's hard for me to sort of like document that process for you. So like, if Tim was going to follow Michael's process, I would have a hard time writing it down so you could follow it step by step.

C (32:34)

But I think that's the learning that I'M having. And maybe, maybe Tim's right.

A (32:43)

We can cut this out.

C (32:45)

No, but there is this thing where I would self describe as a person that's not really into process. But the thing is, all of the thinking happens in my head. It's just not externalized. And so, like you said, I know how all these pieces of the puzzle fit together and I know why I've asked Johnny to do X and why Max is working Y and Y, Timmy's tackling Z and Sarah's doing whatever. M. Great examples, Mo. But like, I know why all those things are being done and how they let her up. I think the thing that I've really been like, learning over, like, this, the course of this year is like, that's not fucking good enough. Like, you can't have all that stuff floating around in your head. Even if that process works for you, it's not working for my team because they're like, wait, why does task X, like, how. How does it fit into everything? Where does this connect? Like, why is this important? Like, oh, this is going to a founder. I probably need to know that. And so it's about me making sure that I'm like, connecting the dots for them, that they have the right information. And that's like a growth journey. Tim, you said we weren't going to talk about fluffy feelings today.

B (33:57)

Yeah, and I love that, Mo, because that's exactly right, is like, anytime you need to transfer something from one person to another, whether that's vis as a leader, whether it's analysis from one analyst to another, the. The production of a podcast, we have a process document. Guess who didn't write that document One. You think there's multiple process documents? To be fair, Val, I've never actually looked at them. I've never actually looked at them.

D (34:24)

Tim takes a drink.

B (34:27)

Yeah.

A (34:30)

That'S exactly it.

B (34:31)

If. If you wanted to make sure that, that that process continued, you go through those steps and that's kind of the idea is like, yeah, the value of it is, okay, wow, this person's doing it really, really well. Let's dive in and see what they're doing and then expand that out to the rest of the team. And you do that all the time. When you look at things like, what's going well? Oh, that's going well. Okay, let's figure out why and then expand on it.

A (34:56)

But not to the point that you externalize it. To the point that you think, now that we have the process, anybody can do it. I think that's the.

B (35:02)

I mean, yeah, very Good point. Yeah, yeah, yeah, yep. And I think that's where you get into sort of some wisdom about what's. What's required in terms of skill and what's required in terms of steps. And that's a balancing act and like.

E (35:22)

How much you can generalize a process. I think that's where you hit the tipping point where people want to generalize a process too broadly and then it starts to become cumbersome and it's not applicable. So it's like the flexibility of the more you guys were talking too. It's like there's layers of process. You have individual processes, you have ones that scale to a small team, a large team. There's competing processes. But it does. You have that tipping point of where is it too burdensome because we've over generalized or where are processes intersecting in not a helpful way. Oh, my brain is starting to spin down a rabbit hole.

D (36:06)

No, the other thing I was thinking too, and I think this is somewhere along the lines of what you were kind of thinking about the different levels of this, Julie, is that like, I think a lot of times a lot of things get labeled as process too. I think we touched upon this already earlier with like the ways of working. But sometimes process is used especially with clients that we work with to solve something that's can't be solved with process. If there's like two teams that have two different, you know, responsibilities as a part of this input or whatever, and they don't disagree or their motivations aren't aligned correctly, like putting in a process, say like, you should do this by this day, or you have to fill this out as like a way to control when really the alignment isn't there outside of the process. And so like there's no amount of like. But I put that in an email or that's in the spreadsheet. Did you check that box? Is not gonna solve too. So it's like it's the layers, but then also the things that process tries to get thrown on top of to kind of, you know, be a band aid in certain situations or just to. It's not always actually making the work more efficient or valuable or you know.

E (37:10)

Because mo even you saying like how you just make those decisions, to me, that's not a process that anyone else can follow. Like that is your problem solving skills, your management skills, your leadership skills. But to your point, the way you communicate it out to probably could have a very clear process so that they get everything they need.

C (37:28)

Out of curiosity, because I feel like we're Saying the P word, every third word. And I think it means so many different things. Predictability for people. When you think of like the best process that you've seen, what does that look like to you? Like, what's an example of a process that's just worked really well? And I know Val had a really good example, but what about other folks? Like what stands out to you where you've seen someone do something and you're like, that works.

B (37:57)

My problem MO is that I've always modulate the process for the situation or the level. So like I, I work in consulting, so I have different clients and different clients need different levels of process. So I bring that level to whatever that situation is and you adapt. So if you're working with a company that's a highly processed organization that you're doing much more process around everything in the work, whereas if there's, you know, a leaner team that you're working with or a smaller company, you can just have a conversation and then get to work and everybody's on the same page and it's fine. There's a lower level of process. So it, I tend to modulate mine up and down.

C (38:40)

Yeah. So to you it sounds like adaptability is the key though to good process.

B (38:44)

Yeah, absolutely. Because if I brought this heavy handed, like multi step process to a smaller, more nimble team, they would just be like, why are you wasting all of our time with this extra stuff? We don't need.

C (38:57)

But why is it wasting time for a small team but not a big team?

B (39:00)

Because you don't need that level of detail or there's not that level of complexity, there's not that many stakeholders with differing opinions. Like there's all kinds of reasons why you wouldn't need to bring like all that additional artifacts into it.

D (39:13)

Can I say. So this is actually I have one thought that I'm not sure if you'll agree with this, Michael, but the difference that I've seen working in much smaller organizations and then like 100,000 person organizations is the, with the adaptability or the scalability I think Michael's talking about is when you're in a smaller group, there's so much more that can just be like a soft contract between people because the expectations can be unwritten and when it's more people, there's more variability or like you have to report things to the FDA or the sec, like then it becomes like the necessity to be more rigorous.

B (39:48)

Yeah, there's a PMO and there's an infosec team and there's a procurement org and like there's all these other interfacing organizations and structures that live in these bigger environments that you kind of have to navigate through. And so that requires you to have a little bit more structured or refined process that you go through. Things that are kind of a step by step. So like, you know, let's say you're going to go build a dashboard for somebody. You know, you could sit down with a smaller company that has two or three stakeholders, the chief marketing officer and one of the people on their team and you spend an hour and a half chatting with them about their strategy, what they're doing, talk about all their data and those things like that. You go away and you come back with version one of the dashboard a week later and it's looking good and you're on your way. You take that exact same process and the exact same data points and you walk into a much bigger organization. You're going to be weeks doing the discovery and the step through and all those different things until you can then get to the people that are going to house the data and they're going to do all the setup of that data and then you're going to go that and you're going to get into that team. And so that same dashboard will take six times as long, maybe longer to build in that environment just because of the additional process steps you need to go through to get to that end point. The the actual output is nearly identical.

A (41:15)

Everything you said, sure, true. However, flip side, I mean one, it wouldn't be the same because it's likely a much more involved in more data sources. But recognizing a process of saying I have a request and I would say probably you want to define that when a request comes in. I need to establish kind of the level of effort and some form of the requirements like in a macro process so processes can go higher to lower level. The adaptability I think is spot on. When mo your question of like what's a process that I've seen work really well, I think work breakdown structures not I mean they've been around for decades come out of the project management world and people, they will bristle at them because the request is for you someone to sit down and think through what the steps are going to need to be and it doesn't have to be perfect. And 100% of the time if somebody tries to just estimate the level of effort, say I think that's 20 hours of work. And then if you take the same person and say just make a list of Everything that you think has to happen and let's just put some numbers on it and all of a sudden it's 60 hours. So that, I mean, I, I've worked at multiple, I've worked at consultancies that don't have that, but that was much more individuals. But I would still make that list. If I'm going to estimate something, whether or not I ever told the client I was doing it, I would make my full on list. So I think that is a.

C (42:52)

Sorry, but why wouldn't you, why wouldn't you share that with the client?

A (42:55)

Out of curiosity, kind of back to Michael's point. Sometimes they don't. I mean, I may or I may not. Like sometimes. Well, sometimes I don't want to because I don't want them diving in and saying because I'm going to miss on every one of those. The expectation is if I have enough detail, I'm missing high and I'm missing low on enough different ones that it nets out to the reality. You start putting that level of detail in front of somebody who they've hired me to be the expert. If I say I think this is going to take me 60 hours and they say, whoa, we can have a discussion and I can hit kind of the big points of, you know, why it would. If they look at every line item and say, what do you mean this is going to take you two hours to review this document? And all of a sudden we're having a pointless discussion. So I see that as a more useful. And I'm trying to think when I worked.

E (43:47)

Or they want to rip out line items of like, oh, well, we'll take that off your plate. And they want to then like hem and haw over splitting up the work. I've run into that too.

D (43:56)

And then you're like, well, then I'll add in more hours after that to make up for what you aren't going to do.

A (44:02)

So I think from a process for estimating the scope, and then I would even say on the dashboard example, I am going to have a heavy bias towards doing the process. I will have will be as part of that discussion doing some form of wireframing because of the risk that's opened up, regardless of where it is that they'll start Frankensteining what you've done and having some sort of an interim step. But it's kind of like a general one from an intake of a project of a certain scale or saying this is an ad hoc request, this is going to, whatever the threshold is, this is going to Take less than four hours. I'm not going to say that I'm going to open this tool and pull that tool and do that query. There's back to adaptability and judgment in it. But that's just my simple answer to where's a process that works well, I think scoping work, having some steps and tools and having people understand how to use them. And if somebody's a savant and says they nail it every time just off of their gut, it's a weird thing for them. How do you. How do they prove that? How do you prove that out?

D (45:12)

But just going back, I don't think we ever resolved your thread, Tim, on like what happens when the scope blows up after you start digging into it. So like you've best laid plans, you've got the WBS and right there's rounding error in there. But you realize like, oh, that's actually not the data mart where that was. And some people on this call know exactly which situation I'm referring to. But like, what do you want to like, talk about how you. Because I don't have an answer. I just want to hear someone answer it. So is it YouTube or something else? But like, how do you.

A (45:44)

Mine is simple, that I'm like communicate, communicate early and often and say I'm sorry we missed on this. What should we do? And we need to re. Balance as opposed to try to hide it. But.

D (45:54)

But do you change the process then going forward too? I'm curious. That's the part I was not unless.

A (45:58)

It'S happening a lot because that's where I get nervous that it's a.

B (46:02)

Typically for me as a consultant, I usually bake into the process, what we're going to do if we run into something like that. So in other words, if we run into a situation where it's going to be like that, we're going to come to you and have the conversation and then we'll figure out what we do about it. So it's not like, you know, obviously we hope it doesn't happen very often, but it does happen and then you just go talk about it. And honestly, I've had in my career a lot of those conversations. I think maybe 20% end up with frustrated clients. Usually people get over it pretty quick and they get back to productivity pretty quickly. And honestly, a lot of times people are thankful that you brought it to their attention and were upfront about it and reset expectations correctly. I think what I've observed over the years is there's a lot of people out there who try to fake it all the way to the end. And people have gotten back a lot of bull crap from people who they thought were going to give them something of value. So in a certain sense, like you stand out if you're just honest about it and have a frank conversation.

A (47:11)

The process.

B (47:12)

Yeah, yeah, well, it's part of the process, I think.

D (47:16)

So you think adaptability is the first thing that you think about, Michael, for an effect and the ones that I've seen work. Well, to go back to your question to Mo is all about expectations. And so are the expectations of me clear? Are the expectations, you know, to my stakeholder clear? The other people have to touch as part of the process, do they know? And so I think that kind of goes in line with what you were sharing there in communication. But Julie, we have to talk about assumptions though, going back to the document because that's.

A (47:41)

I was the going to say, yeah.

D (47:42)

We have to get back to that. Tell us, tell us, Julie, all about that and how that's helped.

E (47:49)

Well, I was going to say like the assumptions one is big because if we were the example that Tim was just walking through and something like blows up, it's because we assumed that data would live in a certain place and we would have easy access to it. Everyone assumed and signed off based on that. And so that document Val that you did mention talked about on multiple episodes. It's so simple. But it really does save us a lot of pain because one of the sections we put in there was assumptions we have started to bake in general. Assumptions that we will list, that the data listed above is available where expected. You can put those safeguards. And so then it's like a soft contract almost with the client to say for even just an analysis within a larger program that we're working on with a client, we can say, hey, this analysis, this is the exact scope of. These are the steps we plan to go through. These are the deadlines and like rough timing that we're going for under that these assumptions are true. The client, we talk about it, they have their expectations set, we've agreed on it and it is where we come back. And if they, if we find something that goes against those assumptions, like it's a very neutral way to bring it to them. Of like, we all agreed on this now the terms have changed, so let's reset. And they're usually much more receptive to it or if they come with last minute requests, it's kind of the same thing of like, well, we agreed upon this. If you really want to change the scope, then we have the right to change the deadlines. Right. Like you can't change what's in here with no effect to the other areas, which is kind of nice. So the assumptions have been like a saving grace. Even though they felt so obvious in the beginning. I found it was a really good exercise. The more I thought through, like what am I actually assuming in my head or from experience and pain points, what do I know I should list out as an assumption that I might run into?

B (49:46)

Yeah, experience is a good teacher on that too. You pick stuff up and then you make sure to add it in as assumptions later.

E (49:53)

Definitely. Especially if you have points where like you know that the client or your stakeholder is going to be a bottleneck. I like to list those out, you know, like this is based on the dependency that you guys are able to provide XYZ by such and such time.

A (50:08)

Oh, I've totally done that. When they're like, oh, we can get that data for you that's available. Like you can't access it. It's in. Yeah, yeah, that's easy. We can get that data. It's like, okay, the assumption is going to be that you will get that data. I'm wondering if Mo's got a reaction like on, on, on data science projects or on other projects. Do you run into cases where like, do you, do you guys document assumptions or like the projects where the scope is risky? How do you manage, Is it setting expectations? Is it documenting assumptions? Is it frequent check ins? Is it all of the above?

C (50:47)

There's definitely, definitely documentation of assumptions. And I would also say in most cases those assumptions would be stress tested. Not always with the folks that you think. Like we will often use finance to stress test assumptions, which might surprise some folk, but often because it's to do with our strategy, our marketing strategy, which is also part of our like global strategy. And so we will work with like finance about, you know, have we thought about this particular, particular market correctly or our investment here? And like this is kind of how we're thinking about it. Does that, you know, does that make sense? Essentially? Like my preference is always to include assumptions, if not in the body of the doc, but at least in the end of the doc. I'm kind of pretty ruthless on that. But yeah, that's definitely a part of it.

A (51:39)

But that's a simple little potential step of the process. It's two things. It's one, having somebody check the assumptions, do they seem reasonable? But then there's also, are there assumptions that are missing here. And those may be two different parties or you may ask the same. I don't think too often of actually checking the assumptions with kind of a third party, but that makes going to the team that actually has that say, hey, we assume we're going to be able to get this data in this form from this and that's going to be reasonably straightforward. Before we dive in, we want to check that assumption before we commit to doing this. Asking finance a question, I don't think I've done that, but now I want to.

C (52:25)

Oh, I see what you mean. I think it's a little bit different internally though, right? Because have I got it right that when you say you check an assumption of like, does this data exist in this place? Yada yada yada, you're going to your clients. Whereas like it's very different for our team because we could just look it up. So like, I don't know if there needs to be the same rigor on that specifically.

A (52:49)

There's plenty of in house cases where there are two different. I mean I'm thinking pharma, you've got an marketing analytics team and you have a commercial insights team and the those they're the same company, you know, they roll up to the same. But boy, there is an assumption that, I mean I, even though I've been working with those sorts of teams externally, it's the internal people that say, well, oh yeah, you'll have to go to this other internal team to get that. And it's like, well, you're internal, can't you reach out? And they're like, we can reach out, but it doesn't matter. They're not going to I think.

C (53:21)

But I think a lot of that happens informally firstly. But secondly, I think what I find like with the folks in our team, it's less assumptions about whether something exists and it's more about how it's calculated. So like whenever we have like a table or whatever, there will always be a readme that explains it. But some people write really shit read me that make it really difficult to understand how that metric is actually calculated. And sometimes the like, the amount of like precision or way ways it could be misinterpreted but like that very much happens. I would say informally where folks like, you can see who the code owner is. You would go to the code owner and be like, am I thinking about this metric correctly? I would say that it's completely informal but I also am not doing the work. So I don't know. I don't Think that would be documented.

A (54:09)

I've again watched teams where they're like, oh, we have this one team says, well, there's this flag in this data which is the same thing. That's like a segmentation flag. And it's like, well, what does that. Actually, we assume that it means these things. And they're like, yeah, yeah, we think that's what it means. It's like, but do you know, and you may find out much later in the process that, oh, you had an assumption. Our maybe business stakeholder had this same wrong assumption. And it's only somewhere down the path that because something looks funny and they go to another internal team and they're like, well, that's not what that means at all. So I think it's going to vary. I'm clearly now obsessing about one specific client that was just constantly triggered. Internal team A didn't know what internal team baby was doing. And that also had some very sensitive data. But then I think there's a spectrum along those lines. But any sort of assumption, Julie, like you were calling our assumption, is we have an assumption that at these checkpoints we will get feedback from you within a couple of days. I mean, there are assumptions that are sort of setting expectations for what the business partner will. Will do. That is saying, we're assuming this will happen. And it's kind of a way for them to say, well, that's not. Well, yeah, you can do that. Except for I'm going to be on PTO for three weeks. It's like, well, I'm glad we validated that assumption because that's going to make it hard to pull this off.

B (55:40)

Yeah, we've all got one of those. All right, we need to wrap up, but I'm going to throw all of you a big curveball right at the end, which is this. Everything we've just talked about matters even more now because of AI.

C (55:58)

No, I mean, AI is really good at process. That is one thing it's very good at.

B (56:03)

No, you have to understand your process and manage it effectively to be able to incorporate AI effectively.

A (56:10)

No, it's always fucking mattered. And now if, sure, if people want to say, well, now with AI, you've got to do it more. It is always mattered.

B (56:18)

You do. I'm just saying it has always mattered. But now people want to leverage things like AI and it's not going to work unless they have their process in place.

E (56:27)

So Michael thought that was going to be a nice closing. And instead of Tim, close.

B (56:36)

Tim, just agree with me, you know, you want to.

D (56:40)

All right, well, I. Although I wouldn't. Michael, you said earlier you disclosed that you're a person who doesn't document your process. So. So I could see where you're coming from on that comment. I'll leave that there.

B (56:54)

Yeah. It forces you kind of to, like. As you try to work with things like AI, it forces you to kind of be like, oh, I need to extrapolate my process out more cleanly if I actually expect the AI to perform in the way I want it to. So it's a thing that kind of opens your eyes to, like, okay, yeah. Whereas before I could just.

A (57:16)

Those poor. Those poor humans. Yeah, those poor humans who were reporting to you were, like, driving. Driven up the wall.

D (57:21)

That's why I said, oh, no, it's important.

B (57:23)

I could just yell. I could just yell at them, Tim. Like, yeah, and they'll change your behavior.

A (57:32)

It'll change his behavior and tell you how awesome you are.

B (57:34)

I will be like, oh, I can see how angry you are about that.

A (57:38)

Sure thing.

B (57:39)

I'll do that. But I'll still make the exact same mistake over again. Anyways. All right, we need to wrap up. And if you've been listening to this show, I'm sure you have your own thoughts about process and its place in our world of analytics. We would love to hear from you. And the process for doing that is reach out to us on the Measure Slack chat group or on LinkedIn or email at contactnalyticshour.IO. and I don't know if all of you know this, but we've been putting our shows up on YouTube as well as we've started putting out out little snippets and shorts of, like, little parts of the show that you can find on our YouTube channel at Analytics Power Hour on YouTube. So go subscribe and like the videos. That's a thing we want want you to do for us. That'll help our process.

C (58:30)

That will help out KPIs.

B (58:31)

That helps YouTube. Sure, that will help. That helps YouTube's process of promoting us to more listeners out there, which then helps you by exposing you to the network and wonderful community of analytics people that all are fans of this show, which we appreciate. All right. And of course, I think I speak for all of my co hosts, with the exception of Tim.

C (58:56)

No, I'm just kidding troll.

B (59:02)

When I say that no matter what your process, keep analyzing. Thanks for listening.

A (59:09)

Let's keep the conversation going with your comments, suggestions, and questions on Twitter at.

B (59:14)

Analyticshour, on the web at analyticshour IO.

A (59:18)

Our LinkedIn group and the MeasuredChat Slack group.

B (59:22)

Music for the podcast by Josh Crowhurst.

A (59:25)

Those smart guys wanted to fit in, so they made up a term called out analytics. Analytics don't work.

B (59:32)

Do the analytics say go for it no matter who's going for it? So if you and I were on the field, the analytics say, go for it. It's the stupidest, laziest, lamest thing I've ever heard for reasoning in competition and it's making a bald spot on top.

C (59:47)

Of my head and that's what's making the bold spots.

B (59:50)

So yes, yes, Mo. That is what's making it.

C (59:54)

I can't even tell tell a joke because it's like 30 seconds delayed and you're all frozen, so I don't even know if it was funny.

B (60:03)

Well, we are laughing.

D (60:04)

Yeah, it was funny. I'll be good for the shorts.

B (60:09)

Internet.

C (60:12)

Listen, I thought you were gonna be like, analytics. And I'm like, oh, I cry about that all the time.

B (60:18)

Yeah, Yeah, I used to cry about.

A (60:20)

Analytics all the time.

D (60:22)

Still. Do I have a shirt that says I cry at work. I wore it on stage.

B (60:27)

Yeah, I don't.

A (60:29)

This is. Yeah, this is not a EQ episode. What the hell?

E (60:34)

I'm allowed to have Internet issues just.

B (60:36)

To get out of this.

A (60:37)

Like, oh, you guys are breaking up. What is. This is it. Ah, now it's my turn.

B (60:42)

Let's do a quick 20 minute episode about process and call it a today.

D (60:50)

That's all the time we have.

B (60:53)

Got to jump right into it.

A (60:56)

Keep crying about it. Yeah, keep crying about it.

C (61:03)

Feels weird that I'm the only one who's drinking.

A (61:14)

Rock Flag and its process all the way down.

D (61:22)

Sorry I laughed on top of that.