Strategic Workload Management | Carhartt | PI Apparel

I'm Tiffany Raidon. I'm manager of technical design at Carhartt. And I'm here today to talk about workload management, which may seem like a bit of a strange topic given that we're at a technology conference. I'll intro myself really quickly before we dive into the presentation. So I've had a less broad, but a very deep journey in my apparel career. So I started, I went to college at SCAD in Savannah, Georgia, spent a couple of years in the custom home decor products industry before finding my way back to apparel, which was my degree and my passion. Was fortunately hired in at Carhartt as an entry-level technical designer. Saw a job posting, didn't know what technical design was, but I knew how to do Illustrator flats, I knew how to measure garments, I knew about garment construction, and gosh, almost 16 years later, I'm still at Carhartt and really fortunate to be leading a great team of technical designers. So tech design is my passion, but I do have a couple passions outside of work. I do, I just, I'm learning how to make craft cocktails, so that's been a fun hobby. I've just moved house, so my gardening strategy has changed. I was in a full sun yard, now I'm in a full shade yard. We're figuring it out. I'd love to get a little bit of running and biking in, and I will pet any dog that I can. Say hello to your dogs for me. So workload, right? Why are we talking about workload at a technology conference? I think across the conversations we've heard yesterday and today, one of the common themes has been resources. So any new technology, whether you're, you're implementing a PLM system, maybe adding modules to an existing PLM system, implementing, implementing a 3D technology, figuring out how to make your 3D technology integrate with your PLM system, you know, or whether you're starting to dabble in AI a little bit, any of that takes resources. And that's something where I think a lot of brands, especially particularly this year, are in a place where maybe you're challenged with resources. Maybe you have open positions on your team that HR is not letting you fill. Maybe you have budget cuts happening that aren't letting you maybe spend on a new technology that you think would be really valuable for your team. Maybe there's ways that you are being challenged, whether it's, you know, across your company or across a department or by another department, that you're trying to find ways ways to make things happen. Because as passionate as I am about fit and sizing, which some of you may have heard me speak on before at prior PI conferences, I'm also really passionate about my team and their happiness and their well-being. Carhartt's already very fortunate that we tend to retain our employees. It's a great company to work for. It's privately held, run by the fourth generation, and two out of the three of the fifth generation work there. One of them's our director of sustainability, which is, it was great to hear some of the sustainability talks this week too. But my team is super important to me. I want them to be engaged with their work. I want them to have the tools to do the job. I want them to be as efficient as they can so we can spend our time doing things that are more important. You know, how can we, you know, tech design, eh, they measure garments, right? But tech design has so much more value we can add. So even though I'm approaching this, and the talk today will be from the perspective of a tech designer, my hope is that some of this resonates with all of you too. If you're being challenged with trying to do more with less right now, my hope is that you'll take some inspiration from my talk today in how to quantify the creative process. If you ask a tech designer, how long does it take to bring a garment to life in a season? Anybody have a tech designer and know what they'd say? It depends, right? Because there's so many dependencies. As you go through that garment development process, no garment is created equal. You've got a t-shirt. Maybe it's with a trusted vendor on a known fabric platform. Maybe we're sticking a graphic on it, so you got a graphic approval. That's a process. What about a pant? OK, denim bottom, maybe it's a vendor you sometimes struggle with. It's going to take a little bit more effort, maybe a few more rounds of protos. You've got wash development to factor in. How does that work in your go-to-market? Market calendar, you've got a different approval process happening, right? And then, gosh, get into regulated product. Anybody work on regulated product? Show of hands? A little bit? OK. Carhartt does a lot of PPE and high-vis. We've got flame-resistant apparel in our assortment. So that regulatory process adds additional levels of complexity when you're trying to meet minimum square inches of a high-vis material on a garment. So there's extra calculations, extra workload that has to go into that to make sure that you're meeting regulations before you even take that product to market. So every single product product's journey is going to be different. Talk about coveralls. Whew. The workload on a t-shirt versus the workload on a coverall, right? They're different amounts of investment from your team in what it takes to bring that garment to life. So when we're talking about quantifying workload, there's so many complexities. So of course, every tech designer or every developer or even your designers are going to say, how long does it take? It depends. I think we heard yesterday in the panel yesterday afternoon, they were talking about like, there are resources, right? There are companies here who can help you figure out that workload and figure out what that value add is when you're adding a new software. How much time is it gonna save you? How much money are we gonna save 'cause we're saving time if you implement this? Or how much time is this gonna add to your process? How much more workload is this gonna be for your team? But if you are already in a position where your company is strapped for resources or on budget cuts or in a tough spot, how do you on your own start to quantify that workload? 'Cause data talks. Everybody's gonna raise their hand and say, it takes time. It takes a lot of time. How much time, right? Somebody's gonna ask that. So anytime you are working with your leadership or working with your IT team, Quantifying that creative process into actionable data will help you prove your point. It'll help you get your objectives across. It'll help you in an ask for a new software system. 'Cause if you can tell them objectively the time savings or the, you know, time is money. So the money savings you'll get if you implement a piece of software or a software solution into something that you're doing or into your creative process, you'll have much better results than just saying, we can't do this because it takes too much time, or we need this. In yesterday afternoon's panel, they were like, why? Why do you need it? And so I think being able to quantify that why puts you in a position of power in those negotiating conversations. So let's talk about that complexity factor when you bring garments to life. And the examples I'm going to share with you here are just some internal tools, things we've put together for ourselves. Pros and cons of Excel aside, I'm utilizing Excel in these examples with some fluff data, but trying to make it relevant to show you how you can roll up that complex data into those actionable conversations. So thinking about the first factor in complexity is what are you doing? Like before we even start to get to the complexity level within a garment, what are the main steps in your go-to-market process that and it could be in seasonal development. The examples I'm showing here are mostly seasonal development examples, which then you can roll up into how your seasons stack on top of one another and how that workload accumulates as you're in 2, 3, 4 more seasons at a time. But think about what is the process? What steps are you going through that you're trying to quantify the workload for? So I've thrown up some examples here of seasonal development. As a tech designer, I'm going to build a tech pack. I'm going to request a first pass. Proto, I'm going to go through one or more rounds of evaluating a sample and sending comments to a vendor, check and send a production tech pack and maybe a top sample evaluation. So that pre-production process is included in there, right? Because that's all workload that has to happen to bring, bring a product to market. As we're getting into 3D sample, some of you know Carhartt's on our 3D journey. We implemented CLO about 3 years ago. We're not on that journey, that map to return on investment. We're not there yet. So 3D sample development, right? Right now we're doing sometimes virtual development, sometimes a lot of still very all physical development, but sometimes we're doing both to build that trust in those digital assets. So that's additional workload we want to consider. But if you're on a 3D journey, maybe you're collaborating with your tech designers, collaborating with your designer pre-handoff. Maybe you're building a CLO asset from scratch. Maybe you're partnering with your vendors to create your digital assets at this point in time if you don't have the in-house software or knowledge or tools to do that yourself yet. But essentially, that same process of what is it going to take to bring a product to market in this path? This could look different if you're a developer. Maybe you're doing lab dips, you're doing color approvals, you're doing graphic strikeoffs. Each of those are a line item in your process that you want to account for. So once you've figured out what are your steps in your, you know, whatever the workload is that you're trying to quantify, seasonal development or otherwise, start thinking about that complexity. And as a tech designer, I love the details. I love it. I want to know every little bit, every everything. And this is where I've had to challenge myself in trying to do these types of, types of calculations to just pull it up a little, get myself out of the weeds and think about things in a little bit more of a high-level way. So these are just some made-up terms here, but you could use your own, or maybe you already have internal terms to describe like we call it innovation— is our most complex style development. These are just internal terms in TD that we use. But maybe it's a completely new concept, new fabrication, really complex fit challenge we're going after, something you know is going to take a lot of effort. Define would be your average new style, maybe going to take 2 rounds of protos. Great. Check it off the list. Carhartt, we do a lot of repeat silhouettes. We're not fashion, we're not groundbreaking. So a lot of it's like, we're going to take the same pant, we're going to put a different pocket on it. So it's a pretty known quantity, known fit, known fabrication, just changing some design details. And that's less work, right? So you see we're moving down that path of really complex to less involvement or less time investment into a style. You know, repeat with variations. Sometimes there's, there's, system, unfortunately, system data entry, right? We've talked about the value of making that easier where we can these past couple of days. But even that's pretty complex. You could simplify this down. You could make it 3 steps, really complex, an average style, or a simple one. So then you start to mesh the 2 together. So think about the, essentially, your development steps and combine it with that complexity factor. Making that as complex or as simple as you want that to be. But you want to include different levels there. But how do you know how long it takes? Ask your team. And when they answer you, please believe them. We had one bad example where another team unfortunately tried to implement a similar thing to what tech design was doing. And they all rolled up how much time it took to do each of these steps. And their boss said, It can't actually take that long. Go back and do it. Just write it down. Make it this many hours. So how do you think that made the employees feel? Not great, right? So when your team tells you, and you might get some varying answers between two tech designers, maybe one has more experience in a product category, or one has, maybe one's just faster, more familiar with some optimized steps in the PLM system or something. But the goal is to get a number, get a data, get some— sorry, a data. Data's already plural. But essentially roll it up and ask them. And if your tech design team is like mine, they're going to go, well, sometimes it's this, but sometimes it's— you still get ranges. Great. Average it out. You have to simplify it to get somewhere. And even if by the end of this, your calculations are 80% correct, you have something to work with. So that's where, again, try to stay out of the weeds because it can get so complex so fast. So once you have this valuable data from your team, how long does it take you to build a tech pack on a really complex style? And you can even— you can get specific. If you have coveralls again, different. At Carhartt, we call it BOAT, bottoms, outerwear, accessories, tops. That's how our PLM hierarchy and our teams are structured. So OK, well, a coverall, sure. Coverall is an outerwear piece. So a complex outerwear style, fine. We can put it in that category. Helping guide your team through this and giving them the confidence that close enough is good enough. Just give me a number. Is it 2 hours or is it 10 hours that it takes you to do this step? So, that'll get you the start of data. So, what do we do with it though? How do you start to roll that up? The way we looked at it was breaking it down by development type. So, new development within a category. And then how complex is that category normally? So for example, in Carhartt's business, knit tees, we have a ton of graphics, right? It's a block silhouette. We don't fit it. All tech design has to do is build a tech pack, which is still an unfortunate amount of data entry for us, but we're working on it. But essentially, what percent within that category falls into each of those complexity classifications? So right, in bottoms, most of it is kind of an average new style. We called it 50%. Whereas there's maybe 25% of the bottoms line on average every season. And you can work with your team to help refine this. We plug these in our— we have these templates set up. And we use them. We calculate workload seasonally. I'll talk about that in a minute as to why we do that and how we use that information. But essentially, simplifying it down to the point of plugging in how many new styles do we have in a season, how does that shake out across those complexity classifications? And then using the hours data that your team has provided to roll that up into a total hours for a category, for a season, or whether this is for a project, you can then multiply that out to roll up that data to find out how many workload hours are we talking about? It's really cool. We then do that across every category. Again, I've built it into a template in Excel. So all I have to do at the beginning of every season is plug in my new style count, my carryover style count, and it rolls it up into workload hours for my entire team. Now, of course, you can start to use this data in different ways. You can look at it across the season. You can roll it out by category. You can do this for projects. We typically do this for seasonal development, like I mentioned, but this same concept can be used if you're implementing, you know, taking on a new project or maybe modifying a process that you know is going to have some workload add for your team. But essentially, this is, this is gold. These are hard numbers that then you can start to slice and dice by category to help understand, whether it's help you understand for yourself and your team versus help a cross-functional team understand or your budget team understand. So this is data now. These are hard numbers that you can take and roll up and use to your advantage. Now, bear with me. Some of you may go, Tiffany, Duh, I know Excel has formulas. I know how to use them. I also know we have creatives in this field too. I was sharing this technique of workload calculation with a peer and she pulled out her phone to start to do the math to add things up. So if you are a creative, if you're not familiar with Excel, please know Excel will do the math for you. There's Miss Excel, there's TikToks, there's YouTube channels, there's fun ways to learn how to use Excel. Excel, use it to your advantage. It's an amazing program, pros and cons. You shouldn't be using it to manage your entire development system. But anyways, that's, we've heard about that enough already yesterday. But yes, learn how to use Excel, especially when you're doing these types of calculations. Excel is an accounting tool. It will run all the math and all the numbers and you can do all the rollup so that you're not breaking out a calculator to do any of this. So what do we do with this data once we roll it up? This is an example of a season with, you know, fluffy numbers in it just so I can explain the concept to you. But here we have bottoms, outerwear, tops, and accessories. So that covers Carhartt's product assortment that our team touches. We have how many styles do we have, and then how does that roll up with that hours total? And I don't think I mentioned within those complexity classifications, we assigned a number of rounds of protos. So tying back to that data my team gave me, How long does it take to fit and evaluate and send comments on a proto? We've included multiple rounds. So if it's an innovation style, we guess 3 rounds of protos. If it's a regular new style, a define, we included 2 rounds of protos. If we're sticking a pocket on a pair of pants that we already run in the line, maybe we're going to get 1 proto on average. Maybe we'll do it in 3D. But there's still workload associated with that. So we roll this up. We've got a total workload hours for our team for the season. What do we do with it? Where does that data go? Within tech design, we use that to look at team balancing. So we know based on, we have our team structured already for sort of an average development ratio. We have one accessories tech designer. We have 3 people on our outerwear team. 5 people on our first layer team and they flex across tops and bottoms. So we do have this data roll up. We can use that to compare season on season. What is workload looking like? Then we can also use that to compare across categories. The other way we use this is to look across levels. If we're looking at 2, you know, 2 associate tech designers, do they have an equivalent workload right now? If one of them has a lighter workload this season, can I ask them to take on a special project for me? Do I want them to spend some extra time in CLO building out our digital asset library? Yeah. You know, so this roll-up of data, you know, and applying some approximate percentages of how much time each level is spending within their category and spending on seasonal development, you can then see who's light or gosh, so-and-so, maybe so-and-so is struggling with their performance right now and they're not hitting their deadlines. Oh, well, Oh, it's because their workload's super high this season. So being able to look at that objectively can help in managing associate performance. It can help when it comes around for performance appraisals, because if somebody had a super high workload and they killed it this season, highly effective, right? You know, so it gives you that tool to look at how that workload is showing up amongst your team. These are— this is not my real team names. By the way, usually my presentations have a little more spice to them. This one's data, so I had to throw something fun in. I'm either Thelma or Louise, by the way, most days. So what else can you do with all this data outside of your team? So when somebody says, wouldn't it be great if we could just, couldn't we just, for example, at Carhartt, I mean, we're all on a journey. We all have a limited number of, resources, somebody came to us and said, you know, best practice would be if in our denim bottoms we evaluate a proto for every wash. We fit every wash. Best practice. And it's like, well, cool, but that's going to be a lot more work than what we're doing today, where we fit one wash and expect the vendor to match the fit and size and manage the shrinkage to get to the same fit for the customer on the other washes. But wouldn't it be great if we could? Wouldn't that provide a better consistent fit experience for our consumers? Especially when denim bottoms is one of our growth initiatives right now. It's on our 3-year plan, guys. So how do you quantify that workload? How do you know how much more work it's going to be for your team or how many more team members you would need in order to achieve that goal of that process change? You can then start to look at it. In this example, I use that same bottoms seasonal style count factor, broke it out within our PLM system, pulled some averages of how many denim versus non-denim bottoms, How many bottoms do we have in the line on average? What does that split look like? And then how many denim washes on average do we have per style? So then I could just pop that into our workload calculator. How many workload hours? Well, we were at 2,900 before and we went up to 4,500. Holy moly, that's a 57% increase in workload. I have 2 people working on bottoms right now. I need a 3rd person. If you want me to do that, we can do it, but I need the resources. So I think that's where those if this, then that conversations become really valuable. Because if you keep pushing that workload onto your team, what's going to happen? Performance is probably going to fall. They're probably going to take shortcuts, which makes me shudder as a tech designer. We're pretty strict about our processes. So the more you ask of people, At Carhartt, we tend to have this roll your sleeves up and get it done, hard work culture, which is great, because we get a lot done, but the impact on the teams isn't always the best, because then they feel like unrealistic expectations are being placed on them. So, as a leader, being able to quantify workload asks, or like, yep, I agree that's best practice, we can do it, if we get the resources for it. So certainly special projects, it could be the addition of a PLM system. It could be taking on a new module. Maybe there's cost savings associated with doing something. But regardless, that data, having those hard roll-up numbers, finding a way to quantify that creative process and the complexity of the garments is so, so valuable. And having those conversations, whether it's with your leaders or with your IT team or elsewhere across your organization. Even our go-to-market timing. Carhartt just went through a big renovate of our go-to-market process. Everything's work, hard work themed around us. So, we had a renovation to our go-to-market process. But starting to be able to look at those workload ebbs and flows. I talked about how many seasons are you in at a time? Is it 3, 4, more? As you're managing out one season, you've started a next, and you're getting handoffs for the next one after that. So starting to inform that go-to-market process, you can look at the crunch times in your calendar and say, OK, handoff to tech packs out, I have 3 weeks. And you're going to give me so many styles. I can figure out how many hours it takes to bring a style because my team told me. They told me how long it takes to build a tech pack and send a proto request out. So you can evaluate then what is that style count we're able to accommodate based on the time we have in our go-to-market calendar. So valuable. So because of that, we've then been able to push back to our go-to-market team and say, we need to have a cap here. And here's the number we think it should be based on the resources we currently have on our team. So looking at that, especially those crunch times within your go-to-market calendar, because then you can start to put timing against these. And I'm speaking of time, I'm going to try and talk faster to wrap this up. But you can start to put timing against those crunch times. Times in your calendar against the workload step associated with it. So that way then you know how much workload can we accommodate within this timeframe. I can tell you 'cause I have the data. It's amazing. Supporting resource and headcount requests, I kind of alluded to through this because it's a matter of time, workload, and resources. Time is finite depending how far you stretch your team past 40 hours a week and the number of full-time associates you have. Certainly during crunch times, we all work harder, but it's not sustainable with your associates to do that all the time. You know, so taking on new tasks, new software, a higher style count for a season, that's where this data can be leveraged to support headcount requests, to support push for contract help, whatever that looks like in your organization, because being able to quantify the workload helps you know what to ask for. 'Cause you have the data. And then essentially, yeah, understanding whether new projects and processes can be accommodated based on the resources you currently have, the people, the people resources. Because they're essentially, they're finite. You know, your people only have so much time and energy to be able to invest into this. And of course we can try and get more efficient, which most of us already have. We try and use different software, which, often has a resource allocation associated with it. But being able to use this data to support your team, isn't this guy great? I love him. He's thrilled. He's so excited about his realistic workload. But essentially, allowing your team to be thorough. Tech designers love to be thorough. We really, really love it. We want to do the best job we can. Everybody does. But giving them, The finite workload to allow them to do it right is a huge advantage to helping them feel successful in their role and in their job. You can help your teams learn how to assess the workload so that when you ask them to do something, you know, you ever, can't you just? It's my favorite phrase. If you teach your team these techniques, you can help your team learn how to push back, even against you. I'd rather have that conversation with my team rather than making somebody feel squashed. I'd rather they come to me and say, you know, Tiff, If you ask me to take on this, it's going to take me this long, something else needs to come off my plate. What else? I've got this, this, and this. What can I stop working on or what can I pause? And then that sustainable workload for associates over time. We all are more productive and happier when we can do a good job, devote the right amount of time to the things we're working on, and giving your associates and your team the chance to do that will keep them with you. It'll keep them with your company, and it'll keep them happy, which everybody just wants to be happy at their job. So I think that the data, you know, the data rollup can get complex, but remembering to pull it up, trying to simplify it as much as you can while still allowing some room for complexity, that data is so, so valuable for you and your team and your organization too. Thank you. 5 minutes? Okay. We have time for a couple questions. Mm. How far in advance should these discussions take place, especially around unexpected workload? The sooner the better. And that's where I think prepping ahead and having some of these calculation tools ready for you, or at least having heard about it at a conference or understand the theory behind it, will help you be prepared. So, you know, most of our tools are built around seasonal workload, but you can see how we've used them sometimes to look at additional rollups. So save all your templates, save any of your calculations the preparations you do because you never know when something will come along where you'll then have to jump in and it's like your boss says, your VP comes to you and says like, okay, I need a decision by Friday whether or not we're gonna do this thing. Like okay, if you already have some of the tools available to you or some of those things prepped or the data pulled from your team, you're not gonna be scrambling for that. So it's a good idea to, I mean, I of course have found so much value in these tools. So the sooner you can start working with your team to understand how much, how much time they are investing and looking at those numbers and doing that data roll-up, then you've got it at your disposal. And I find I keep coming back to it to slice and dice in different ways depending on different asks, different projects, or every season we seem to revisit the style count question too. So having it ready to go is going to be to your advantage because sometimes those asks are unexpected. Are you using planned styles and apply a development ratio upfront, or is this all after the season closes. So we typically, on the seasonal development front, we typically check in at line plan handoff, at design sketch handoff, at final— actually, after first proto review, which is not quite our final line adopt, but it's when the line is supposed to be pretty set. And we do that every single season. So we can roll up season to season, how does that workload look, as well as we don't have— unfortunately, we don't have firm development ratios. But I think like most companies, you start with a line plan that merch has. Because it expands when design starts to play and have some options or some fabric options you're investigating. And then at proto review, we cut it back down. It kind of gets this onion bulb shape. And then what we actually take to market's even smaller sometimes than the line plan that we started with. So even though we don't have set development ratios, we can see from the data predictably what happens season on season and then try to have those conversations within that, ideally, proactively before the next season. Gosh, we were over on style count last season. We need to be a little bit lower this season. We can't be over again because that builds when those seasons stack up season on season. So that allows you to have the tools and the data to push back, ideally before the start of the season as much as you can. If you have two people doing the same category, do they need to agree on the time per activity or do you take the average or do you use each person's actual time? When I initially went out to my team and asked for the data, I was surprised by how consistent what I got back was. Of course, there was some variability based on experience, based on, honestly, let's say thoroughness sometimes. You have some people who are more thorough than others. So that enables you to, you can take those and average it, but I was actually pleasantly surprised with the data that I got back and how consistent it was within a category. So I'd be interested to hear from some of you if you go back and implement this, if you find the same or if you're getting wild variability from your team, because that might be in a separate conversation then to say, wow, does it really take you this long? Are you really doing it this fast? If so, how do we help others do it this fast too? So that even might be something you could investigate with individuals in a development conversation or understanding, ask open-ended questions to understand how are they doing it that way or why is it taking them so long? Maybe they don't know about a hack in PLM that's a really good shortcut. So there might even be learnings there that you could share within a team or even make it a team activity to any advice on how to track workload for R&D when workload is less predictable. I think that would fall in more of that project category. So, you know, maybe figure out what, what the, what are the key tasks that you do frequently? Are there, you know, is it meeting with a new supplier? Is it meeting with a new raw material developer? Is it, is it doing exploratory sampling? Are you running field tests? Try to identify what those key activities are. So referencing back to, I think it was my first Excel slide, figure out what those key activities are, and then you can kind of, if you have unpredicted things that come up, you can slot them in and figure out what that associated hours workload is on top of it. Okay, I'm out of time. Please come see me if you have questions. This was a bit of a lightning round. It's a lot of data to get through. You know, but feel free to catch me throughout the rest of the conference today or hit me up on LinkedIn. Feel free to email me. My email's in my profile in the PI app. So happy to talk more about it if you think this is something that would help you in your organization. Thank you.