In this episode, TJ Pitre, founder of South Left, joins the podcast to trace the real evolution of digital production — from the early days of Flash and Fireworks to today's dynamic, system-driven workflows. TJ shares his journey bridging design and development, reflects on the rise of modern tools like Figma, and explores the shift toward more connected, production-ready design. Along the way, he breaks down the growing role of the design engineer, the impact of AI on creative workflows, and what the future holds for building smarter, faster digital products.
Guest
TJ Pitre is the founder of South Left, a boutique front-end agency that lives at the intersection of design and development. With roots in illustration, UI design, and engineering, TJ helps teams transform static ideas into dynamic, production-ready systems. He’s a passionate advocate for design engineering, smarter workflows, and the evolving future of digital production.
Transcript
Chris Strahl [00:00:00]:
Hi, welcome to the Design Systems Podcast. This is the place where we explore where design development and product overlap, hear from experts about their experiences and the lessons they've learned along the way, and get insights into the latest trends impacting digital product development and design systems from the people who pioneered the industry. As always, this podcast is brought to you by Knapsack. Check us out at Knapsack.cloud. If you want to get in touch with the show, ask some questions or tell us what you think, send us a message over on LinkedIn. You can find a direct link to our page in the show Notes. We'd love to hear from you.
Andrew Rohman [00:00:25]:
Welcome to the Design System Podcast brought to you as always by Knapsack. I'm Andrew Roman, standing in for our regular host Chris Strahl. Before we get started with our guest today, just a quick plug for some other upcoming Knapsack events. We have a feature release webinar coming up here at the end of April on the 30th where you can learn all about some of our latest features related to prototyping and composition and letting anyone adopt and build things using your design system components. We also have a Patterns Design Leadership Summit coming up will be in New York City on May 15th. Head over to Knapsack.cloud/events to check out all of the latest events and content. Coming up with me today is TJ Petrie from South Left. South Left is a boutique agency focused on front end design and development, really centered around design system work.
Andrew Rohman [00:01:11]:
Really excited to have you here today tj to speak to your perspective given the sort of wide range of work you do and the rapidly evolving state of digital production. Welcome.
TJ Pitre [00:01:20]:
Thanks for having me here Andrew. Big fan of Knapsack and all of the things that you all do. So happy to be here and talk all about design systems.
Andrew Rohman [00:01:28]:
Well, let's start a little bit with even broader zoomed out from Design Systems. Just the role of design, the role of engineering. The whole world of digital production seems to be evolving so rapidly and I think specifically around this ability to work a little closer to code. And so talk to me about what you're seeing out there and just that evolution of the design to code workflow at sort of the highest level.
TJ Pitre [00:01:52]:
Yeah, design code, the discussion that never ends, that transcends time and space. I've always considered myself one of the in between people because my background is in design within illustration and then kind of transitioned into design. But I've always been fascinated with code and like if anybody who's gotten into Flash back in the day, like Old Macromedia Flash. That was a moment when it felt like it perfectly blended the two. Because you can have like a stage where you can build shapes and import images and then you can either use like a tweening timeline to move them around and animate them, but if you need a more advanced interactions, then you go to the ActionScript Code Panel and then you can actually start coding things in there. So that was like the first step into like. Well, I like doing both of these things. And then once I started to like get into the industry, I had some internships and some various jobs throughout my youth dabbling in graphic design and web design.
TJ Pitre [00:02:51]:
And it always felt like there was this division back then. I think the two sides was like the staunch design and designers can't code and there's developers and developers can't design. It's like they perpetuate this fictitious thing that's like, it's impossible. They can never do that. And I think over time we'll visualize the gap between what is design and what is development. Over time I think it's narrowed, but it's almost kind of just become more prickly. Even though it's not just design and development, both areas have expanded so much so it just feels like there is different parts of design that really can't or just refuse or maybe are reluctant to dig into some of the more development pieces because development is now front end development and full stack development and DevOps and all those different things. So the emergence, like fast forward 10, 15 years to where we are today.
TJ Pitre [00:03:45]:
Like, I'm loving the concept of design engineer. To me, that feels like it's that role that kind of sits neatly right in between the way I visualize it is in the design to development side. On the very end of the design spectrum is like the creative. This is the conceptual thoughts, the things that you know, these are the colors that evoke these emotions. And this is the typography that presents whimsy and all those pieces. And as you kind of of whittle down on that side, maybe it's more of a funnel visual. You get more into like, how do I create systems out of these aesthetics? And I go, I like that red. That red feels like the one that we should leave with.
TJ Pitre [00:04:24]:
Maybe that red is the primary. And then you start thinking about all of these different typography patterns and color palettes and spacing as systems. And I've always felt like that's kind of where I was. But then I also enjoy the coding part and I like to be able to take those pieces and then put them in elements that I can apply to code and then make them themable. I'm all for the don't repeat yourself and keep it simple stupid models. So modular and component based development has always been something I've been interested in. So I feel like once you get that systematized approach to designing things and apply it to this modular based way of developing things, that's my sweet spot. That's where I want to dig.
TJ Pitre [00:05:04]:
10, 15 years ago, five years ago, even that still would have been like, nah, we don't like try filling out an application for a job or try getting a team or a manager to hire somebody for that. It just didn't feel like there was a fit for it. But I'm loving the progress today to see like, wow, this is actually starting to gain steam. And I'm seeing literal job roles looking for design engineers. And if I didn't own an agency, I run this agency. If I was looking for a position, that's the one that would go for. Because I feel like there's a lot of other people out there just like me thinking, I don't neatly fit in this box. But I also don't neatly fit in this other box either.
Andrew Rohman [00:05:40]:
To me, what that's an interesting reflection of is this convergence that you can see happening all across the industry in terms of tooling, which we're certainly going to get into here in a little bit in terms of this role. I love the historical perspective you bring up because I think about this art going back to like early modern software, let's call it the 70s or so, when everything was engineering out right. There wasn't software design, it's just whatever they build, it was very functional. And then we got into sort of the early, you know, graphic user interfaces in the 70s to the 90s kind of space. As we got into the web, we started having a lot more design. We got into web 2.0 and it was like everything was designed at least expectation wise. And that's when we also felt the most pain of like, well, what do you mean? It doesn't look like that. Why is the fold there? Where's the cta? Make the logo bigger, you know.
Andrew Rohman [00:06:23]:
And now we're approaching this convergence where I think in the last 10 years or so, and this is where Knapsack has been trying to play so far, is how do we just help close that expectation gap where we still have design and engineering working way too separately generally. But can we throughout the process bring more awareness to the Gap and the differences and just awareness that we're doing design in this infinite canvas medium and we're delivering in a different medium. And so like we should acknowledge that difference and that gap as we work. I think that we're seeing the convergence in terms of that awareness and perspective that's leading to roles that are in this hybrid state. We're also seeing that in tooling and the ability for people to work closer to the medium of destination. And even before we get to the AI conversation, there's this ability, especially in the systems world, to go from. We're using reusable elements in design and code that represent each other to accelerate design and build to like, well, if they already have these reusable things, why don't we just work with them and then only design the things we don't have? Right. The idea of designing with components and a design tool that all exist in code is starting to make less and less sense to a lot of the folks that I speak with.
Andrew Rohman [00:07:33]:
So how are you seeing that evolution of process and systematic design and production happen, especially from like a tooling standpoint as they talk about convergence?
TJ Pitre [00:07:42]:
I'll start with the way that things kind of used to be in the early days when it's like everything was kind of being built in Photoshop, which like Photoshop couldn't give two shits about ui. Or like, I mean you could build some beautiful pictures of web pages that you might want to frame and put them on your wall, but the likelihood of those actually being built, the expectations are too high. This is just a common pattern that front end developers would always have to live with. Like you go show the stakeholders this beautiful picture of a web page and they get sign off on the whole thing and all of a sudden it's like, well go ahead and build it. Like wait a minute, you know, it's 2002, the web can't do this yet. Like there's so many things. I think it's both the advancement of tooling and the acknowledgement of the importance of UI and how important it is to actually create tools that do UI well. And I'm going to throw out fireworks there.
TJ Pitre [00:08:34]:
Like not fireworks, like legitimate, like the actual application fireworks. I feel like it went like Photoshop. And then a lot of people were comfortable with Illustrator too because vector graphics seem to translate better to UI elements depending on what type of UI you're building. But Fireworks was the one where it's like there was a lot of people who said, you know what, I think we should start paying Attention to these UI designers, like designers who are actually here to build and design elements for interfaces. So that was kind of like, all right, now we got this. Fireworks was like my jam back in the day. I love Fireworks.
Andrew Rohman [00:09:07]:
Everyone misses Fireworks. It had so much figured out so early.
TJ Pitre [00:09:10]:
Macromedia, Macromedia, man. If it wasn't for Macromedia, if I didn't have a torrented or pirated version of Macromedia, I probably wouldn't be standing here today because that's where I was. Big Freehand, Flash, Fireworks, Dreamweaver. That was the one where it felt like I can literally do anything with all these applications. So Fireworks, actually that whole Macromedia was really the one that pushed the envelope for let's give these UI designers the tools they need to really create some beautiful interfaces. That was like the seed that was planted, that blossomed the sketch. Adobe xd, obviously, figma, pen pot, you know, all the ones that we're kind of using today.
Andrew Rohman [00:09:49]:
The truly purpose built vector GUI design platforms.
TJ Pitre [00:09:53]:
Absolutely. And back then the way that they were doing the handshake with the development teams was like just little things in Fireworks, like allowing in the design to place a hotspot or like allow in the design to say what element could be a hyperlink or a mail to. That was kind of like the beginning stages of the respect that the UI graphics software was trying to say, okay, we're going to help the designers out by like, you can export this. We're already going to have some code in here for you and then it's up to you to go ahead and take this and update it, refactor it, whatever you want to do with it. Fast forward to today. Sketch is great. Zeppelin was a great way to export components and then inspect all of the things that you need in order to really focus and isolate the little component pieces. Back then everything was like, here's the homepage, go build the homepage.
TJ Pitre [00:10:42]:
I love that. Now it's all like, well, go bid the car, go build the hero, go build the button. Obviously the elephant in the room is like Figma owns this space now. Figma pretty much is the one that has really gotten into the granular details of exactly what developers need, speaking specifically about design systems. But also they do other excellent work when it comes to interpreting developer needs. It's really nice how they'll offer developer mode and they'll offer some pseudo code kind of stuff that'll work, but it's never really production ready stuff that you can just shovel over into a code base and then expect it to work. But it's the addition of having all of the properties for component based designs where it's almost speaking the developer's language. When you say things like slots and props and variants and things that we think about when we're trying to think about managing UI from a development perspective, the way that these software developers and these organizations just continuously keep pushing it, that gap just keeps getting narrower and narrower and it's just the advancement of tooling.
TJ Pitre [00:11:48]:
So at some point I've got some predictions about where Figma might go and things like where webflow pick up because I feel like there's going to be some overlap with those two tools. But it's an awesome time to be in this space.
Chris Strahl [00:12:01]:
Hey everyone, I'd like to take a quick break and tell you about Knapsack's leadership summits. Every month we host an exclusive in person event in different cities all around the country, bringing together design, engineering and product leaders. These summits are all about sharing our learning with tailored discussions to address the challenges you're facing. The best part, it's totally free. Head over to Knapsack Cloud Events to find an upcoming summit near you and apply to join us. We'd love to see you there.
Andrew Rohman [00:12:28]:
I think one of the interesting things when you look at tooling and a tool like Figma and the evolution of industry and features and everything that a company like that drives, there's such a wide range to address for them in terms of types of companies and types of users and states of maturity. Especially when it's talking about the things we're talking about dramatic evolution in the way digital products get created. Some of them don't have design systems at all. Some of them design systems is everything about figma. There's no idea of code. Some of them are trying to do less in figma. Right? Dan Mall, a year and a half ago was like, hey, we want to build better products faster, spend less time in design and more time closer to code. That's a push from one end.
Andrew Rohman [00:13:04]:
For others, that's incomprehensible, Right? And I actually think that's part of why whether it's Figma or any other tool working at that scale gets, you know, lampooned. When they roll out a first iteration that doesn't feel broad enough, I'm like, the amount of people and situations are trying to address is incomprehensible, right? So it's really interesting to look at the tooling landscape from especially that perspective, understanding what they're dealing with. But that said, your company at South Left and knapsack. We primarily work with rather large, rather mature organizations at pretty decent scale in that space as they are pushing towards more automation, more AI. There's a lot of push for AI, even if they're not sure how and where. Where are you seeing sort of achievable progress? Not the flashy stuff, but like, hey, this is something we can really depend on. I'm really curious, what is that doing for kind of the balance of where you're relying on computers and where's the human element now focusing?
TJ Pitre [00:13:56]:
Right.
Andrew Rohman [00:13:56]:
Is it more on governance and control? Is it hopefully less on defining error states in a vector tool? But how are you seeing people approach this tooling shift in a really approachable way at kind of big scale?
TJ Pitre [00:14:07]:
Yeah. So from where we stand, we have the opportunity to be able to work with some amazing organizations. It's a fun space for us to work in because a lot of times they allowed us the freedom and flexibility. As long as we're transparent with them upfront about what we'd like to do and get permission to test some things. It's a great spot for us to dabble a little bit in this space. So the goal with incorporating AI with a lot of our development practices and design practices isn't to eventually build a product that we can market, that we can contribute back to the community that Full Sail manages all your design token architectures, manages components and composes them into larger level components and then build them all. When you think about it from that perspective, then it's daunting and then you'll never start because it's like the finish line is 80,000 miles away. It's like one of those things that you apply to anything working out diet.
TJ Pitre [00:15:05]:
It's like if you think about the end goal, it's overwhelming. You have to think about step one. So we think about that first step and it's like, what are the problems that we're having right now? And one specific problem that we're trying to address was keeping the source of truth being figma. So we're working with these amazing designers and designers who know code well and they're doing all the right things in figma. They're assigning all of the props, all of the slots, all of the properties that go into all of these components, all the states. And so we're trusting everything that's in there. And so a lot of these conversations that we're having on the design side before it really even hits the code base is having a developer's eye work the designer to ensure that everything is in a good spot to be almost exported directly into code from figma. And so this also includes the naming of the tokens.
TJ Pitre [00:15:56]:
So like when you're creating your token architecture in figma, ensuring that there's like namespacing and other things that we're likely going to end up having. Name spacing isn't completely necessary because we could take care of that with like style dictionary or another tool, but ensuring that they line up correctly. So the first thing that we want to address is keeping figma as a source of truth. And what should we do then? We should probably do something that communicates with the Figma API. So we made a little VS code extension where we could put in an access token to allow us to access the Figma API. We put in a destination path on where we want that component to end up, but also analyze the other components that are in that directory and then we go in the Figma library, right click on the main component, copy the link to that component and drop it in the input field. It makes a call to the figma API, it grabs all that meta that's associated with that component, including styles, properties, variants, everything, and then generates a directory filled with in this particular instance it was a web component based design system component library using LIT and CSS modules, using SCSS and TypeScript. And then in that object that it's grabbing from the API, it also has all of the different variants, so it knows to create stories that have all those variants.
TJ Pitre [00:17:16]:
And also a little switcher, like a dropdown where you can choose like whether you want warning or info or success or like if we're building like a banner of some sort. So that sucks it in analyzes all of the other components, the sibling components in that directory knows that you're using certain code structures as certain comments like, oh, it wants to follow all of those things to be consistent and then plops it in there. And then once it's in there, I mean like for some of the atomic level components, like it gives it like 80% of the way there and it looks good. Like you can see in the code that it's referencing actual CSS custom properties that map to the token architecture that we already have in the code base. So I'm not saying it's 100% perfect, but the problem was enough for us to start testing the waters of what can we do without getting ourselves overwhelmed about like, oh man, we need to have this giant crazy software that will eventually sell as a service and it's going to Be great. But just for our one little use case in this one little project that we're working on, it helped us out in something that would probably have taken six months. We shortened it into like three or four months.
Andrew Rohman [00:18:22]:
That's amazing. I love this. The guidance of start with something relatively small and relatively achievable. Hey. Doesn't sound that different from things we typically advise. Design system teams of, right, don't go build 30 components and then hand them off and hope it all just works. In the early days, it was always like, hey, build a button and get the button into production somewhere and then you know, you can do all the parts, right? And then everything else is scaling. So I think especially in the AI world, that makes a lot of sense.
Andrew Rohman [00:18:44]:
I'm curious as you see this progression, you said something earlier about the role of design and the unique value of bringing in the UI designers that are solving human experience problems and that need hasn't gone away. A lot of what you're talking about is making it easier to close the gap and work within the structure we have, which that's the whole point of the system, right? We've defined parameters that when we work within them, we think we can go really far, really fast. It doesn't mean never break them, it means go really far, really fast and then make all the other decisions with intention. I'm curious, like, how are you seeing, maybe it's about governance, maybe it's about how do you still have that creative element? Because I think we all agree we want to reduce the amount of time we have those annoying ripple effects that come from someone broke a component unnecessarily upstream and then we want design systems to focus creativity, not to eliminate it. So how are you seeing that part of the creative process evolve in this more automated, AI driven world?
TJ Pitre [00:19:42]:
I think right now we're in a point, at least in a lot of the projects that we work in, where we keep FIGMA as the centralized source of truth, where figma kind of holds all the data that we need in order for us to at least put things together from a visual perspective and then understand if this happens, then this should be the tokens, the colors, or whatever needs to be applied to it. There are guardrails and guidelines to systems. It is a system. So it's just kind of the way it is. I do feel like things are going to start shifting because as these tools start to adapt to developers, it's starting to feel like, well, why are they spending so much time in development effort? Like the makers of Tools like Figma in creating this whole dev section, when we can just do it in a development environment and then make that the source of truth. Code tools are way more advanced than the features that you get for development in Figma, so it just makes more sense to define all those things. So instead of having designers sit with developers to look at components in figma, have designers sit with developers to suss out the properties and all the things that are needed from a developer's point of view. And then what I think that would do is it frees up the designer to design.
TJ Pitre [00:21:02]:
It really depends on the type of designer you are. Like I was saying earlier, there's like, on the other end of the spectrum, there's the creative mind, the one that can't be locked down by systems, that needs to be able to think openly and freely about the way colors evoke emotions and all of those things. And that's totally legitimate. There is definitely a need for that, especially when things kind of start going down that funnel into creating systems on that beautiful creativity. This may be just my hypothesis, but it feels like some of these tools are getting too close to development. It just feels like if the designers just had the freedom to create and then communicate it to the developers, and this is where the design engineer can kind of sweep on one side or the other. Right now it feels like a little bit more to the tools that are available in things like Figma. And I feel like there's going to be this pendulum, slow, pendulum swing to the development side where it's going to be like, all right, what's the point of me doing this for you when you're the one who does this? This is like your thing.
TJ Pitre [00:21:59]:
I'm here insinuating what you want in this tool. It's going to end up getting, being exported into your code base anyway. So let's just start it there and do it there. Then I could back up. I don't have to create 87 instances of a button. Like, I can just focus on like the aesthetic of the button and like, maybe if there's some subtle animations and like little user interactions and things like that that are nice, and then they could focus on prototyping things instead of focus on all the nitty gritty little granular aspects of these pieces.
Andrew Rohman [00:22:27]:
I couldn't agree more with what you said. You know, with Knapsack, we work to enable, with teams as this, you know, if you can compose things within the structure of what you already have, and a lot of the teams we're working with are web focused systems. And so in that case you've got the components which have structure in terms of properties and slots and things like that. You've got your themes which have in most teams parlance this day, you've got collections and modes of your different variables and tokens. And then you've got, you know, the web browser and just how the Internet works in a web browser. And that all represents structure that is going to define the parameters within which the end experience will exist. And so if we can let teams work within that structure to then inform what they design, it's so powerful. And then everything you do, you know, you're making or modifying things that you absolutely need to and should, or you've done the cost benefit analysis of like, well, I could make it do that thing that I think would be amazing, but wow, that would take an extra week and that doesn't seem worth it.
Andrew Rohman [00:23:19]:
And like, what an elevated way to be producing. What I think is the most interesting part about that though, that I haven't seen good solutions for really yet, although we're on the edge of it, is how is tooling going to evolve to support working within that gap, right? Because if you can really quickly see what you can do with what you have, I imagine a world where AI can do things like not only say, okay, well you didn't have the things you need for this, or here are three different approaches that are high, medium and low effort. Right? You could use 90% system coverage and ship this thing quickly and all you have to do is design this little piece and then how do they design that little piece? Right? How automated is that? How human element is that all the way down to, hey, you want to make this thing super bespoke? Here's a really low brow way to do it. Still doing design and development, but taking advantage of the whole point of systems, right? Enabling better production by way of really leaning into reuse. And I think that's been the stumbling block so far is for five, 10 years we felt like we're reusing things, but because we're reusing different representations of the same thing, nothing feels that different. Most teams I talk to, they're like, I use Lego pieces, I got the comp done faster, but we ultimately didn't ship the thing more than maybe 10% faster. And so I'm excited to see teams get to that, ship things 80% faster, 90% faster, combine it with data and start to get some optimization based on performance. All these things become enabled when we work within these sort of system Structures and you know, I feel like tooling is just starting to catch up to the opportunity here.
TJ Pitre [00:24:40]:
Yeah, absolutely. The ROI on and there's a lot of design system component measurement tools that are out there and I think they're all really important. There's a lot of conversations around like what is a recipe and what is an organism and what are patterns and all that kind of stuff. And this has a lot to do with that. I think. One of the things that I think Knapsack is poised to do is having playgrounds where there's like a library of your components. This is like one thing that I haven't really seen done really well. I've seen existing design systems like Polaris from Shopify has a good version of this where there's like a playground where you get access to code and an interface and you can like just move things around, create your own little layout.
TJ Pitre [00:25:21]:
That's a really powerful way of kind of testing design system theories before you create your recipe. Create your recipe. Like you can go in there and move things around. It's like this layout works or this heading structure, this footing structure works using the existing atomic and molecular elements that are already in there. And then I feel like at that point you should just be able to export as code and then it'll put in the slots where you can slot in those particular components and then give you what would be your to call layout or whatever. It's like maybe it's a layout with some variants that makes it flexible, but that feels like the thing that's poised to make the most impact if it were built into some design system tools.
Andrew Rohman [00:26:04]:
Yeah. And a lot of the use cases that come up in figma that FIGMA supports well, that are still necessary to support the creative process. But today, the way I see them play out, I'm going to zoom in on the one. When someone breaks a component in figma and that causes a ripple effect we talked about and it's hard to communicate, do we need to do it? General chaos downstream. It's not that the intent of that designer was malicious necessarily, maybe it was a bad decision. But you're going to have plenty of cases where you need to go beyond the system, modify something. But when you're working removed from the medium of destination, all of those challenges just talked about are so present. Whereas we're working on this, I'm excited to see other tools solve this problem of one, making it more approachable for anybody, designer or product manager, to work in the medium of destination.
Andrew Rohman [00:26:50]:
Like that's happening. Right, that's. I mentioned in our T up we got a new consumer role. New. It's all about letting designers, marketing managers, product managers make stuff with your system and code, knowing about code, drag and drop interface. Right. Like that is all possible. But I think that being able to turn that into a modern workflow and seeing how we also accommodate that creative part.
Andrew Rohman [00:27:11]:
Right. We do not yet have all those pieces solved for how do you work within the gap? Does that feed into Jira and feed back into figma and it works today? Or do you allow people to still do the act of breaking a component, you know, as the example, but in a way that is sort of expected and feeds into coherent, cross functional workflows? Because it's not that the need goes away, it's that we want to be able to do it in a very clear, managed, cross, functionally aligned way and not just like, oh, I think somebody might have done that a month ago. This is where it feels like we're at today. So there's so much to be solved there, but it feels like we're starting to make digital production, you know, take advantage of the possibilities of the digital medium, which 30 years in, it's nice to see us start to round that Corner or maybe 50 years into 60 based on my timeline earlier today.
TJ Pitre [00:27:56]:
Yeah, I feel like as the field exponentially grows, as much as we try to narrow that gap, the more names or roles and like I was saying before when it was just development and then it kind of went into like full stack development in front of development and everything just kind of got partitioned into all these different things. It's like as much as that gap is closing, it's rigid and have this like tighter areas and looser areas and tighter areas. I think as all these things grow, there's always going to be like the. But I do this. I've always heard the saying friction creates movement or something to that effect. So having that and the constant pursuit of trying to make these things be one and the same might be healthy because I think it sparks a lot of really great conversation if you go to Design System Slack or go to a LinkedIn Design Systems community and just post your opinion or a hot take on one side or the other. And if you're looking for engagement, that's the one that's going to get it for you because people just have really strong opinions about this particular topic and it's always been that way. I think it's going continue on.
Andrew Rohman [00:29:01]:
Awesome, man. Well, we could go on this stuff all day. I really appreciate your time and perspective and we got to save some of it for next time. We'll have you back on in a year and talk about what Skynet's doing for digital production at that point.
TJ Pitre [00:29:12]:
Yeah, totally great.
Andrew Rohman [00:29:14]:
Anyone, if you're needing some just amazing support services or just want to have a great conversation with TJ and his team talking about everything you've heard about here, check them out south left.com or if you happen to be in New Orleans, hit him up. I'm sure he'd join you for a coffee.
TJ Pitre [00:29:27]:
Absolutely. Or a Sazerac.
Andrew Rohman [00:29:28]:
There you go. Even better. Thank you so much. We'll catch you next time.
TJ Pitre [00:29:31]:
Awesome. Thank you very much.
Chris Strahl [00:29:33]:
Hey everyone, thanks for listening to another episode of the Design Systems Podcast. If you have any questions, topic suggestions, or want to share feedback, go ahead and reach out to us on LinkedIn. Our profile is linked in the show Notes. As always, the podcast is brought to you by Knapsack. Check us out at Knapsack.cloud. Have a great day everyone.