1. Mark Tattersall - Healthy Tensions And Elastic Thinking

The Importance of Setting Direction

• LogicGate started out as one big team that self organized around projects, but eventually moved to squads.
• There are now four product squads with ownership over various pieces of the platform.
• However, there wasn't a strong definition around the direction and visions for these squads. There was an intentional initiative to set a purpose and "North Star" on where these squads are going.
• Also, when Mark joined there were only two PMs serving four squads - which led to them hiring two more. "It's important that PMs have the ability to have a singular focus."

Healthy Tension's With A "Three In A Box" Model

• The "three in a box" model is an autonomous cross-functional team that consist of a Product Manager, Engineer and a Designer.
• The trade off, discussions and dialogue in a three in a box model leads to a healthy tension that is needed to do good holistic product work.
• By building good relationships with the engineers and designers you can be ahead of the curve and ensure you do not fall into feature work.
• The different perspectives is also what makes the role fun!
  

Hiring

• How and who you hire depends on the maturity of the product and organization.
• In more mature products and organizations, there’s specificity around the type of background - e.g., number of years of experience, experience with data products, certain domain knowledge, etc.
• In growth stage companies, Mark looks for a balance of culture, experience and an energy and desire to learn and grow. This is because the company will look very different in a year than it does today.

​Autonomy

• It’s all about hiring good people and letting them do their work, but it’s hard.
• OKRs are a great way to help facilitate autonomy by promoting creativity in solutioning. By asking for updates on progress to metrics (as opposed to a roadmap and features), you devolve decision-making and discussion on features to the teams on the fringes.
• But, there is a balance - you still need to listen to customer service, sales teams, etc. Particularly as a growth startup.
• But it does come down to having the teams own a problem statement or objective, and giving them the freedom to iterate towards that goal in a given timeline.

​​Elastic Thinking

• Analytical thinking is your busy work and more structured. “I need to do this presentation and I need to work through steps 1-10 to get there”.
• Elastic thinking is the dedicated time for imagination, meandering and downtime, which is necessary to connect dots in a unique and differentiated way. Sometimes, this can be the result of procastination.
• To make the leap from PM to Senior PM to Director, you need to get out of the tactics and understand how to lead your field and organization to a vision.
• Elastic thinking can become part of the job for teams when decision making required for setting strategy and features is decentralized.
• Action - think about how much of your day is spent on analytical / structured thinking vs unstructured / elastic thinking time. And adjust accordingly!

​​Building Culture

• Not something you can stamp on an organization, there’s no magic wand for this.
• You need to create the space in which this grows. You have to create good boundaries around it.
• All good cultures should be open-minded, fun and blunt at times. This allows your teams to have conversations and discussion openly and quickly.
• As a leader, the best way to foster culture is to exemplify it.
• Growing fast is the best way to disrupt a culture as well, but setting good boundaries and living your values day in and day out is the way to help curb this.

‍

My guest today is Mark Tattersall, VP of Product Management at LogicGate. Mark is one of the best product managers and leaders I’ve had the pleasure to learn and work with. Our conversation covers a wide range of topics from: the importance of setting direction, healthy tensions needed in working relationships, hiring for growth stage startups, the importance of autonomy, elastic thinking, and culture. I hope you enjoy the conversation!

Mark’s LinkedIn

View Mark’s writing at www.ProductPolymath.com

-----

Show Highlights

(1:54) - LogicGate background

(4:48) - How LogicGate organizes their product and engineering teams

(7:25) - The “three in a box” model and it’s healthy tension

(11:18) - Staffing and hiring for a product organization

(15:06) - Autonomy and empowering product management teams

(21:51) - Elastic: Unlocking Your Brain's Ability to Embrace Change

(26:42) - The slippery slope of culture building

-----

For more episodes and access to our bi-weekly newsletter with key takeaways, subscribe for free at reorgpod.com or follow me on Twitter @itsdanwu

1. Mark Tattersall - Healthy Tensions And Elastic Thinking

Dan Wu: [00:00:01] Hey everyone. I'm Dan Wu and welcome to The Reorg. Every other week, I'll bring on a guest and discuss everything from organizational structure to leadership, to building community and culture. I believe that a business is only as good as the people behind it. You can find more episodes and subscribe to our bi-weekly newsletter @reorgpod.com. My guest today is Mark Tattersall VP of product at Logicgate. Mark has extensive experience as a product manager and leader. And in this episode, we talk about the healthy tensions needed when building products, how procrastination can be a superpower and culture as a living and breathing organism. I'm Dan Wu and welcome to The Reorg .

Welcome to The Reorg, everyone. I thought I hit record but. I didn't. So we're doing this again, but Mark is very nice. So I'd like to introduce my first guest and good friend Mark Tattersall.  Started his career running his own recruiting business. And then he moved to Chicago in the mid two thousands and transitioned away from recruiting into technology. He eventually joined Braintree payments in 2012 as one of the first PMs. And that's where we met. Stayed there for six years, he saw Braintree through the PayPal acquisition. And in 2018, he joined another rising Chicago tech company called ActiveCampaign And now he's most recently the VP of product management at LogicGate , he also runs a product centric blog called the product polymath. And he's an avid Leicester city football club fan. So Mark, welcome to the podcast. 

Mark Tattersall: [00:01:47] It's great to be here. 

Dan Wu: [00:01:49] Cool. So. Would love to start off the conversation by talking about your new role as VP of product at LogicGate could you just talk about. the background of the company, what stage they're at, and maybe dive into. How you're assessing the state of the products and the product organization. 

Mark Tattersall: [00:02:08] LogicGates is a, is a startup in Chicago. roughly about five years old. and they're in the governance risk and compliance space, the GRC space, which I'm not the most sexy industry, but definitely, a critical industry. one that's growing and Chris. I would say, like, I think everyone has run into GDPR as a term or Sox or PCI compliance. So there's the compliance aspect and there's the managing your risk aspect. it's something that every kind of, business, as you reach a certain size has to address a and B become more than competent At as you grow. so. The platform is, it's basically a catch-all workflow tool that can help companies, handle any number of use cases across that. That domain. so, what attracted me to the, to the company and the product in general. Was that they, they seem they've been around for five years. Like I said, they came up through TechStars Incubator, The three founders have great domain. knowledge. and they iterated on the platform and it clearly found product market fit. At least my perspective coming in and that's been born to be true. since I've joined. you can just see from the last 18 to 24 months, the graph is kind of like hockey sticking. they, their customers are becoming avid avid fans of the platform and we're acquiring more customers than ever. So. What attracted me to the role was that the three founders, like I say, it it's rated really well to reach the point of product-market fit that they've. discovered today and they were looking, they, they saw growth as in their future, and they also saw a big opportunity for, category creation in many ways. it's a space that is full of old incumbents. and a few fresh startups. so they were looking for somebody who had been through the growth of a startup. a few times we've been on the product side and is kind of, can I bring their experience to bear. On how we set ourselves up for that growth in the future. but also people, somebody who's, worked on building. Big new products, product categories, product lines, because they have big ideas about where they could go with the platform and just kind of were looking for help and experience to kind of make that a reality. So. That was what attracted me. It had those two aspects to it. The, the kind of working with working with and growing a product team, product management team. As well as like the new product innovation, which is, which is just so important for a startup. cause it's so easy, I think to end up, Just iterating on the product that you've you've found fit with. and, it's easy to kind of put a pause on innovation and it's hard to get that back. So if we want to make sure we keep the momentum there. 

Dan Wu: [00:04:49] You know, you joined in June. So what was your,  first series of steps to really understand the nature of the products and how the company currently organizes around the products

Mark Tattersall: [00:05:00] Yep. So the, The product and engineering teams had just recently, before I joined kind of moved from that stage of like essentially it's one big theme. Who would kind of self-organize around projects that need to be executed and then actually moved into defined, squads, by the time I joined. So there were actually four squads, although there were only 2 PMs when I joined. and they were, they'd also hired a lot of engineers recently, so.

Coming in and kind of learning about the product and understanding around the structure was that the, the. The squads were a good move. I think into kind of setting ourselves up for the future, but there wasn't necessarily a really strong. Definition about the, the vision of those squads. They were very much. built around like ownership of pieces of the platform. which is a really common, way to organize and not, I don't think is, is bad in any way. and it's something we've maintained going forward. as I came in and kind of start trying to assess, the most important areas, I can impact how we, how we go about building the product. Was was firstly to boost the team. I think we needed 1:00 PM per squad. because I think it's super important that the PMs. have the ability to singularly focus on their area of responsibility. and then just to think about like, how do those squads, set themselves a bit of a North star for why they exist and where they're going? I think a lot of the activity Continues to be based around iterating on existing features. not to say we're not building new stuff. We have, we actually release something really impactful. This month, that was entirely brand new. but it wasn't exactly clear how we were making decisions. About what we were going to build every sprint, because it wasn't exactly clear. what the, what the Like I say the North star, the vision was for that squad. So, coming in it really was about like, trying to just kind of. Start to get that conversation going about, , let's get our heads up out of the, iterative features, which we obviously, you always need to keep moving and start to think more about where we're going. Longer term. So I've only been there. You know, it's coming up to five months. So it's, it's definitely a work in progress, but, that was the initial thing coming in. So, and actually I worked with engineering straight away to kind of. help implement a dev lead on every squad. so to try and get to that three in a box model. We've got a growing design team. and with a dev lead and a PM on every squad that three in a box model on every squad I think is, is so critical. and so we're heading down that path. right now,

Dan Wu: [00:07:37] You beat me to my question. the three in the box model, could you maybe explain that a little further and .Why that is your preferred model ?

Mark Tattersall: [00:07:44] Yeah, absolutely. And this is purely comes from, what I found to be most impactful coming up as a PM is a. A product manager. Owns should own the strategy and the tactics for. What it is that we're, they are building for in their squad, in that team for that product ownership area. Right. So, In order for it not to fall into project management. It's super critical that you have an excellent relationship with engineering. And not only just the, all of the developers on the team who are executing, but ideally an engineering leader who is somebody that you can bounce ideas off and have that good discussion about like, It's. If there's no point sitting at your desk as a product manager, trying to come up with, Oh, we should do this. We should go there. I think that this would be the best thing to work on next sprint without grounding that in the reality of like, well, How is engineering going to execute on? How long is it going to take? What, what tech. do we have What may be bugs are coming in. That could be bigger than you think that they all so the relationship with engineering is obviously critical and I'm, that's not, that's not a groundbreaking statement to make, but I think that if you have, an engineering leader. Who on your team, on your squad? The PM develops a really strong partnership with between the two of you. You start to have an excellent discussion every week about where you're going. why you're going there. what your views are on the product direction, what the engineering leaders views are on the technical kind of landscape of where we are. And that that dynamic is super critical. Then design now. Is the, is the other part of the, of the puzzle that really adds an entirely new point of view on things. So if you have a good product designer on your squad, they're thinking about UX. They're thinking about the user flows. They're thinking holistically about the kind of path that you'll use as a taking in a way that as a PM, you're thinking of some of that, but you're, you're wrapped up in a lot of other things. And engineering's thinking about, but they obviously, buried in the technical. And so between the three, peop leaders of a squad like that design product and engineering, The trade off and the discussions and the dialogue and the tension to be perfectly honest between the three, I think can really generate the magic of like how a good squad operates because. If those three can have that discussion and become aligned around the direction you're going every sprint. And where you're going longer term. I think that the, the rest of the team falls in line. Behind that really, really easily. And I think that the decisions that are made. are just richer then a PM who was making on their own or engineering. making it on their own so. I just think that three in a box model. That, that relationship you have with those two other people I think is just, that's where the magic happens. It's also where the. So those are what makes the role fun right? Like you're, you're just getting two completely different perspectives. So, that was something we'd already hired a director of design at logic gate. By the time I joined he's he's growing a design team. aye. I'm ho I'm growing the PM team and engineering was totally bought into the idea of like, okay, let's have like a tech lead, Who will kind of, be a developer who elevates their role on each of the squads. And we'll get that three in a box model going straight away, And we actually implemented that within two months of me joining. there's some growing pains, but it's, it's showing promise. And in terms of creating a strong alignment on each of the squads between product engineering and, and really bringing design's voice into the, into the mix. . 

Dan Wu: [00:11:19] I love the concept. You mentioned this healthy tension that this, this three and a box brings . Being side-by-side with design engineering is, is so critical to, to build a good product.

Could you talk about, When you're thinking about , staffing and hiring, , how do you determine.  Who needs to come into the organization and where they should go. So, you know, are you looking at. Capabilities prior experience, seniority. Working style. these are all things that you kind of have to take into account when you're hiring and placing on certain teams. could you talk about the hiring and the placement of team members specifically? 

Mark Tattersall: [00:11:56] I think a lot of this depends on the maturity of the, of the product and the organization in general. Because when I think about. When I think about by the end of my time at Braintree, when we were appalled PayPal, six years in hand. I couldn't even tell you how many product teams, 25 30 product teams in Chicago, which is crazy to think about. We really were starting to hire with a lot more specificity about the type of background, that we were looking for in a PM. But the number of years of experience was obviously is always something that was discussed that like, did they have experience with data products? Were they. Did they even have experience in payments or, on the banking side or whatever it is. So I think based on the, you start to like mold. The hiring to the gaps that exist that in your product org, because it's just a mature kind of setup and organizational structure. And then when you're in an early stage, growth startup, like logic gate. mostly what I'm looking for is a balance of culture and experience. and people who have that have that. Energy, and desire to learn and grow because. There is one thing that we can guarantee a, is that a year from now? It will not be the same product org as it is today. So you have to try and hire people who are ready to grow and develop with that protocol. and, and I think is a really great growth. startup. At least in my experience in the domains I've worked in, that's been the primary kind of a goal is like, how will this person compliment the team? How will they not necessarily be the same as the other people we've hired? They'll bring a different perspective. they may be coming from a different industry or they have a more years of experience, or they, have greater speeds working with design or they. how about she went with the data science org, whatever it might be like, I'm looking for differences. Whilst also having a good sense about like, I think this person will fit in the Daryl that work well with the rest of the org and kind of help help it grow. And mostly that they're just like, They have that energy and desire to learn and adapt because, you know, yeah. We forget 12 months from now, three months from now, the old is going to be different. And then that's just going to repeat again and again, when we're in this fast growing. Phase. So. Right now that's where my head is has been at. Or we actually just finished hiring suite with two new P. PM's joined. and that, that was mostly what we were going for. because it was point there's no point to this point hiring, Or you'll go, you gotta be on this squad because that will probably be change pretty quickly. So you're more looking for adaptability and, and a growth mindset and a variety of experience. to bring to the table. 

Dan Wu: [00:14:38] That's really cool. I wanted to talk about. Autonomy. I think the best organizations out there really decentralize decision making and  empower your teams at the fringes. Right. And so. And as a PM, I think the work that you do, you need to be empowered to do this decision-making on your own. so could you talk about autonomy? In the role of a product manager. And just the importance of autonomy and how you empower your teams. 

Mark Tattersall: [00:15:12] Yup. I think this topic is the most critical, as a product leader. And then how you think about setting up your product catalog? Multitasking, I think is always banging the drum about this, but he wrote an article a year ago, two years ago. About the difference between theater teams and autonomous teams, which really for the first time, I think kind of put a pin in exactly. Like, that's it. Right. It really is about.  hiring good people and letting them do their work, rather than dictating down to them. And, it sounds easy, but it's actually really hard because it's a bit like it's a bit, like when I think about, when I go into technology originally, it was like the agile transformation was happening. It's like, We've got to move from waterfall to agile, but you can't just make it a little. Dev team agile. The, the culture of the organization needs to become agile. Because otherwise everyone's looking at this team and it looks like that just like making stuff up as they go along. everyone needs to buy into that concept. And I think that this autonomy. idea is exactly the same kind of wheelhouse, right? It's like, We have to talk about this. I think we can do it from a product and engineering standpoint. And I think we have to also sell it to the rest of the ed, to the organization. To make sure that they understand, well, why am I not seeing, why can I not just say, go build this? Or why am I not seeing a roadmap for the next whole 12 months? and, and that comes down to like, some of it is procedural and summer is just kind of cultural evolution. fortunately logic gate, like a lot of the, framework for making this happen. And in fact, the way that they were operating already was very autonomous, which was great. they already have the model of like, okay, ours. which procedurally is one, I think, I think you can argue that OKR Can be bad as well, but as a procedural element in this like stew to making autonomy happen. OKRs can be the way that you say, like don't tell me about the roadmap and the features you're going to go build. Reports on me back on how we're hitting this target. And if you start to have that, that level of discussion. On OKR and the key metrics that you're going after. You're starting to devolve the decision-making to the team on the fringes. Like you say, you can choose like, okay, well, I think the best thing that we should be doing in order to hit this OKR is to go build this now. Even if maybe five, five months ago, I thought we'd be going after this. And that's what we communicated. so, I think there's a product team. It's top of mind for me. and it's, it's always a challenge, You have these, these like nonstop voices kind of coming in for product, or if you've got customers asking for iterative kind of improvements on their pro on the stuff that they're already using, you've got. the executive team who are all speaking to people, our customers, and prospects and analysts at completely different level, who are hearing things from the market. And kind of a very kind of like pointedly saying like, well, here's a direction. I think we should really be headed and then you have the product team itself and that three in a box model. and, The kind of path that they're, that they're going down. and, creating it between the three of them. can often be a tension with those other two kind of key, input areas. So, It is super critical. I think some of is a trained and kind of learned, a belief that. if you give the product team and our Slack, they will deliver. but it has to kind be proved over time. and I think that there is a balance between, okay. We do need to listen to what our customer service teams and our sales team. And the customers themselves are saying particularly as an early growth startup.   Just cause we found product market fit doesn't mean we couldn't lose it again unless we Keep our platform fresh. We're not there yet. Right? Like we, we really are only five years old, but really like two or three years in to the platform that we're on today. Being the one that all of our customers are using. So there's still a lot of work to do. So you don't want to lose sight of like what got his here and how we, we know we can predictably kind of keep that wheel turning. but at the same time, giving enough Slack to teams. For them to explore and, and figure out the best path for their areas. And I think. Like the name of the podcast, a lot of that is about structuring the, the product teams to own an area or a problem statement or an objective. And give them the freedom to iterate. Towards that goal. and to actually like, get really good at communicating what my goal is to the rest of the company. consistently and often, and to report back on progress. 

Dan Wu: [00:19:42] There's this balance between. taking input. From those external voices. know, you need to do that as a product person, but then. at the end of the day, the flip side of autonomy is accountability. Right. As a product person, if you're autonomous in your decision-making, you're also accountable for the decisions you make. And that  should be structured accordingly.    

Mark Tattersall: [00:20:02] And this is where the structure is so important, right? Because. That you could, you don't want to give autonomy to a product manager and say you just don't, you know, I dunno, whatever it is, feature a right. Bye. Well, just by phrasing it that way. What are they going to do with that? They're just going to look at features. They're going to listen to feedback about feature a and they got to try and make Feature A better right? Like there's no problem statement there. There's no objective of like make feature a. Drive, 10 million in. ARR over the next year or whatever it is. So it's about how do you, how do you set up the teams to have a mission and a goal around what they're going after. And then the metrics under that for how they report back on that. And, and. And a timeline, to be honest, like, you know, this isn't going to run forever, like maybe within the, for this quarter or this year, whatever it might be. So that they can go after that and charge after it and report and report back on that, consistently. I think that's it. It D it doesn't just happen on its own. Right? Like it does need to be, there needs to be like the constraints need to be set. You can't just let them just run while the economy is not just. Go figure it out. It's like, you're responsible for this problem statement or this objective. Tell me how you're going to get there and start by kind of like laying out a vision for me of like what the end goal looks like. Even if, even if we all know. Chances are when it's not going to look like that 12 months from now, but it is. It is at least something that you can rally the troops behind, and helps you make key prioritization and dizzy and product decisions along the way. 

Dan Wu: [00:21:39] So I wanted to switch over to this. unique concept that you brought up in your Product Polymath blog. this concept of analytical versus elastic thinking. So could you describe what this is, the difference between the two, and   how do you ensure that. Product teams are set up for this elastic thinking time.

Mark Tattersall: [00:22:02] Yeah. Yeah.  Really this came. I did. There was a book, called elastic thinking, that I read. And, as I was doing that, it kind of like spoke to me in terms of like, what I saw is. One of the big problems of being a product manager at a, at a kind of fast growing tech company is that it's so easy to be busy, right? Like, it's not a problem to be busy. He's not a problem every day. Just turn off. And the day will just go ride that wave until the end. And, you'll have answered a thousand slacks and emails and throw thrown a few decks together. And you'll you arrive exhausted at the end of the day and you do it again the next day. but really at what point did you stop and kind of like. Give yourself the space and time to actually. Think about where you're going and why you're going there. And how do you achieve breakthroughs and changes in what you're doing rather than just incremental improvements? and, That's really what this, this distinction between our analytical thinking and elastic thinking is, which is like analytical thinking is you're busy work thinking. It's your more structured. Logical. I know I need to do this presentation a week from now. I'm going to work through the steps one through 10 to get there. And that would have been some research. These people I'll collaborate on this deck and then we'll go in there and we'll present it. Great. Like that's, that's like, that's the basis of like human development since the alignments, so fantastic. But, if we want to think about like, Oh, When you take a step back and you've been granted this product squad. With this objective, and you're trying to map out a vision for how you get there. Should that be a one through 10 process that you just sit down and bang out, or like, it feels to me, like there should be a lot more time for imagination and  meandering and, downtime. and it's really hard to do. And, And also before I read the book, it was like, well, making that point sounds like you do. I'm just advocating for people to just like take the day off every now and again. but this concept of elastic thinking kind of just made it a little bit more concrete in the sense that, There are these conditions. There is this way of thinking. And there was a time of the day. that you can help enable you to think differently about a problem and make breakthroughs Cause he'll know to get in the shower in the morning. That's often when you're like, Oh yeah, maybe I should be thinking about it this way. Well, you're driving the car and you're on autopilot. and it just taking the kids to school or the grocery store. And that's when you're thinking about things in a different way. And that's because you have the baseline. of your thought. Enables you to do more imaginative elastic thinking later. So. I actually think this is like a critical concept to kind of get our heads around as product managers, because, I think there's a commonly understood a belief that, you know, Oh, all part of my ideas can become good at that job. by just executing really well. But to make that leap from. PM to senior PM, senior PM to direct sale. All to, to start leading a product org. At some point, you've got to get your head up half of the tactics. And once you do that, what are you doing? Right. Like, Is that. You know, you're busy in a different way, but how are you like setting the direction for the, for the org or for your entire field? You know, maybe you've got three or four teams reporting under you that shift is that is elastic thinking shit. I think it's about that. Head up versus head down work. and the article that I wrote, was just trying to like, say like, Make time for that? Think about it explicitly. think about how many of your days are just being busy. And how much of your time are you ever getting your head or Pat the weeds to really think about, where you're going and why and how you could do things differently. and it goes back to the idea of it between like innovation and iteration, right. I think you need to do both. but innovation doesn't happen on its own. And, and I think elastic thinking that kind of like. Lightly less structured, more, imaginative. More kind of almost like procrastination can lead you there as well. Like that, that, those times when you're not really thinking, but there, you know, your brain is working away on it. I think it's just so important. I mean, it's a hard thing to kind of like foster into a team, but I think it's, it's a concept that I just found interesting. And, just tried to like, Document how I thought that that would apply to product managers in particular. 

Dan Wu: [00:26:27] I think that the elastic thinking is it's kind of the result of bringing that autonomy to the squads as well. You're decentralizing the decision-making and that means that people need to think more creatively about solutions versus just the feature work. If you're just doing feature work, then all you really. Have time to do, is this analytical thinking? That's your job, if you don't have the autonomy to make those decisions. So, it comes from that as well.

Mark Tattersall: [00:26:52] No. That's exactly right. 

Dan Wu: [00:26:54] I think maybe the last topic we'll discuss is culture and culture building. You know, we, we were at Braintree together for a few years and I always say that Braintree. inthose early days just had a very unique. Culture. so could you talk about. how you think about building culture?

Mark Tattersall: [00:27:14] This one is so slippery. This one, because obviously culture, isn't something you can just stamp on an organization. It's something that has to grow organically and it's it's again. It's like the autonomy argument. It's like, you just need to create the space in which they grows, by creating good boundaries. around it and it's mostly around like, creating an environment where people are trustful of each other, that they feel, able to speak up, without being, Jumped down or, just failing. The culture is open-minded. and I think that the only way to do it is by doing, rather than saying, right, like being. I particularly as a leader, like, Trying to be all of those values that you want to see in the rest of the team. and people will model their behavior on what they see from leaders. and it also gives you the ability to call out people. If you see that that's not happening.

Yeah, it's just a, It's a very slippery thing, but it is super critical because like you say, like at Braintree it was, it was a great culture. It was one of like dynamism and, Very. It was, it was blunt at points. but it was it enabled conversations to happen quickly and openly. Without fear of it being something that will be held against you later. and I had going back to the three in a box. I think it started there, right? Like I think of the, you know, like the, the product org leader in the engineering leaders exhibited that, that kind of, traits we then are the designers and the engineering leaders and the D and the product managers on each of the teams between those three, you saw the same traits again, which then just means it's just like, It rolls downhill. so everyone kind of acts that way. now it wasn't perfect. And growing fast is the best way to kind of like disrupt that as well. The more people you hire. it's really difficult, but, I think mostly it's around like, yeah, there's simple things like, yeah. Establishing trust, establishing openness, candidness in your, in how you speak to people. and fun to be perfectly honest, like actually like. You know, having a laugh. not making everything super serious. I think it kind of just loosens people open kind of helps you generate a good culture, but it's like, I don't have a magic wand for that one. It's like, You have to. It's it's a constant challenge and one that's really difficult as you're hiring new people all the time.    

Dan Wu: [00:29:32] Well on that note. Maybe we end it there. I know we started this super early 6:30 am central, so, and you've got parently duties coming up. I think you're on the cusp of having your, your children burst into your room. 

So, thanks so much, Mark, for being the first guest and Super excited for everything you have going on in your new role. 

Mark Tattersall: [00:29:53] Thank you. Thanks for inviting me. I'm really excited to hear what other guests you have on this podcast? It's going to be awesome. 

Dan Wu: [00:29:59] As always. Thanks everyone for joining the show today with me. If you'd like to hear more, please subscribe to our mailing list at reorgpod.com.