Episode 9Listen on LibsynListen
How to Design Your Agency Org Chart for Sustainable Growth
Transcript
Sei-Wook Kim (00:26.149)
In today's episode, we'll discuss agency org design and how the structure of your organization is an important factor in facilitating growth.
Peter Kang (00:35.616)
All right, so this topic is something that we've thought about a lot over the years. And one of the things that we come across over and over again when we talk to especially the smaller agencies is how should they think about their org chart and how can they scale better to help the founder not wear so many hats? On this topic today, we'll talk a little bit about some of the important factors with regard to organization design and the org chart. So let's start first with why is the org chart and org design important? Why is it important for agencies to even think about this as they're scaling?
Sei-Wook Kim (01:24.964)
Yeah, thinking back from our early days, we started out the two of us and we started adding more team members organically. And we didn't really think about or design much. It was more like just increase our capacity to do more and more work. But at a certain point, it just became unclear who reports to who, what everyone's responsibility is. And in the early days, it makes sense for everyone to wear a lot of hats, but it got murky as we continued to grow in size.
Peter Kang (02:01.271)
Yeah, and effective org design needs to also reflect the type of work that you do and the way that your project or engagement teams are constructed. So maybe we could start there, especially looking back on the type of work that we did in our agency, which was website design and development. In the early days, it was basically just maybe one of us, a designer, a developer, and that was pretty much it. We didn't even have PMs at the time. Maybe we played a little bit PM, the designer played a little bit PM. So what was the org chart like then?
Sei-Wook Kim (02:50.114)
Yeah, org chart, it was us and a bunch of people executing our projects. You might have designed some projects in addition to some designers. I may have coded projects in addition to some other developers. It was very fluid, and especially as founders who did a lot of the work as we grew and built up, we continued to do the work, we continued to do project management and even — later we called it account management — managing the client relationships. The org chart was very flat in that way. There also weren't many titles or levels. There weren't senior designers or junior designers. Everyone had a very flat title, including us across the board.
Peter Kang (03:34.774)
Yeah, it was just "designer." And although it was clear that some were more advanced than others or could handle more responsibility, we didn't distinguish much in the early days. And amid that, it was fun because there were a lot of projects coming in and we were just trying to keep our head above water and doing the work. But at a certain point there was a need — as we started to have more designers, there was a desire for some degree of leadership beyond the two of us, especially with regard to career growth, mentorship, performance management, all those things. Those were the early indications that we needed more structure. Do you remember how we evolved from there?
Sei-Wook Kim (04:37.277)
Yeah, part of it was also around responsibilities and what each level of person did on a project that could have been different from another person in a different role. We basically went through and created departments — and we could have been the leader of the department. So just defining what are the departments and what are the different levels of roles within those departments. And if there's a natural progression for somebody in that department to become the leader of it, that kind of emerged, but everything was very organic in that way.
Peter Kang (05:24.598)
Yeah, and part of the evolution was, as we developed departments, the projects were getting bigger as well. So that's another factor. We talked about how in the early days it might have been just a designer and a developer. But then as projects got more complex, timelines became larger, more stakeholders, we needed to add a project manager. We might have needed to add a strategist or maybe even a copywriter. And in some cases, as the technical side got more complex, we needed to bring in QA. The project teams went from small two-to-three person teams to, at some points, like eight or ten people — you might have multiple designers, multiple devs. And that required us to think about having more disciplines than just design and development and add more leadership to the org.
Sei-Wook Kim (05:55.502)
Yeah, and to your point, as projects got complex, it's more about role definition. Should the software engineer who's coding the project also be doing the QA for the work? Is it the best use of their time? Can we define the role and the focus for each person? We ended up splitting up responsibilities as much as the project could support it. As project budgets increased, there was more room to define roles. And as the volume increased, you had enough work to support each of those people. And in some ways we also used fractional — it could be a contractor who did QA. We may not have had the capacity early on to have their schedules filled 100%. And that's another thing: thinking about when to go from a contractor to full-time, but all within the same realm of understanding what department, what role, and who reports to who in the organization.
Peter Kang (07:27.154)
Yeah, and one of the pitfalls of specializing more roles within an engagement or project team is that at some point you create extra overhead, extra friction, and it silos the work a little bit sometimes. I remember, for example — and we've been down this path multiple times — we used to have designers who were able to do the brand side, the UX side, and the design side, and even project management. End-to-end designers who were really carrying a heavy load. But then we started to split it out and specialize more. We had UX designers, brand designers, visual web designers, and even junior designers who supported just the preparation of assets on these projects. You start to increase the headcount on all of these projects and all of a sudden you've gone from one person to four people. But as we found through some of these projects, if the budgets don't increase proportionately to support that, you're in for some pain in terms of margins. That's a pitfall we experienced a few times where the teams got a little too bloated.
Sei-Wook Kim (08:51.003)
Yeah, for sure. We've definitely seen some evolution of growing the team, growing roles, then also contracting and simplifying the work structure. I think the other thing we found was when you have one-person departments or a few-people departments, you just need to be clear on who they report to. For example, we talked about QA. Who does QA report to? Is that into project management? Is that into software engineering? Is it a technical thing? And when there isn't a clear path, it ends up just going all the way to the top. Whoever doesn't have a direct manager — the leaders, the CEOs, the founders — end up managing those people directly. And soon you're managing a lot of different people across the whole company.
Peter Kang (09:41.487)
Yeah, definitely. So, to make this helpful to folks listening, maybe we take a step back — and if we're speaking especially to founders who, as of today, are wearing many hats and feeling the pressure to bring in more leadership and build out some structure within their org — what advice can we share on how they can be more deliberate about org design?
Sei-Wook Kim (10:12.809)
Yeah, the first thing for a founder is understanding what your own strengths and weaknesses are. Founders come from a lot of different backgrounds. Someone comes from a creative strategy background where they're very much involved in the work and they have an impact on a lot of the work going out in the company, and maybe the biz ops or the finance side of the business isn't the core focus, but because they're the founder, they're taking on that as part of their responsibilities. Maybe that's an area where they can expand in terms of bringing more people to support in those roles.
Peter Kang (10:55.219)
Yeah, so understanding your strengths and weaknesses — that's a good one. I'd add to that just visualizing the org. This is why the org chart is such a powerful tool. We just didn't know any better and didn't visualize for a long time what the org could look like. But once we started using the org chart as a tool, it was really helpful, because what we do is map out the reporting lines — the two of us at the top, who reports to whom, what departments fall under us, and within those departments, whether there are levels or it's flat. We started really getting a sense of, all right, you have some people that are stragglers here reporting directly to one of the founders — what do we do with those folks? Are they better served by moving them under a department? Is there something we actually have to address? Maybe it's a role we can no longer support. Seeing it all visualized was one step people can take. And once you map out where you are today, you can take the next step of identifying holes and gaps. Then what we started doing was: what could our org chart look like six months, twelve months from now? Part of that might just be, if we stay the same size and are trying to clean it up, what could that look like? But another facet could be, if we experience growth and we're investing in a particular service offering or department, what could that look like? We started putting in different colored boxes to show prospective roles we could fill and grow the company in a deliberate manner. From there came discussions around, okay, that's a role we never had — we need to create job descriptions for that, who does that person report to, how do we measure success for that role? Once we started doing this, it became a quarterly thing where we'd revisit it, and it became a powerful tool for deliberate org design.
Sei-Wook Kim (13:27.626)
Yeah, and part of that mixed with performance management — understanding who are the people on your team now and what are the potential roles you want to fill. Is there a person who, given six or twelve months or additional training, could grow into a role? Or maybe they're already playing that role and you just don't know it — finding the right seat for that person in the company. It's definitely about talking with everybody to just be on the same page about where we're trying to go. And you mentioned job descriptions, and just being clear about all the responsibilities for each of the roles. Going through that exercise with the team and showing people, hey, here are the four or five levels within the department — if you want to get to the next level, here are the skills that you need to grow in, here are the responsibilities that are different. Mapping out a career progression for people — that whole exercise was super helpful.
Peter Kang (14:30.705)
Yeah, absolutely. And just to bring it back to our own experience, this exercise was incredibly helpful. It was probably the thing that gave the two of us the confidence to take ourselves out of the day-to-day at Barrel and move on to the holdco, because I remember the org chart exercise of, what does it look like with the two of us inside the org and then what does it look like once the two of us are out of it? We were able to clearly identify, okay, with Lucas moving to the CEO role and handing over the reins on the people side and other things, who else needs to step into that role? All those things started to make more sense and it just gave us the confidence of, all right, these are clear gaps we need to help fill. And that allowed us to execute that move.
Sei-Wook Kim (15:29.576)
Yeah, that whole process took years to execute on. But a lot of it was letting go of the things that we were doing for so long and trusting — and just being clear on, if there are gaps, helping the people who are going to be filling those gaps with training if needed, but also just trusting it. Letting people learn, make mistakes, and guiding through that journey.
Peter Kang (15:59.056)
Yeah, and it's hard to fathom when you're just wearing so many hats and trying to make it day to day. But one thing to strive for as the organization grows is that as the founder, the leader, you're really trying to get to a point where your main lever of impact is the org design and then recruiting the right people and holding them accountable to results. To use a sports analogy, you're becoming the owner slash general manager who identifies the different positions and also the different folks that need to be in the coaching roles to make sure everything runs. It becomes such a high-leverage position where you're less in the day-to-day but more about making bets on the right people and making sure you've designed the org in such a way that the combination of these people are going to yield great results. That was a big learning. It took us a while to come to that conclusion — hey, this is a people-focused business that we're in, agencies. And so it's about understanding org design and putting the right people in the right seats that makes all the difference.
Sei-Wook Kim (17:22.51)
Yeah, for sure. We've been talking a lot about scaling and growth and future roles as you grow in size. The reality that we've seen is business isn't always up and to the right. You could go through stagnant periods or periods of declining revenue, and the beautiful org chart that you created and aspire to may not be the reality right now. You may need to make changes in the business that are the opposite of what you put in place. Any stories you can share there?
Peter Kang (17:59.801)
Yeah, I remember we did a bit of a round trip there. There was a period in Barrel's growth where we were really excited about achieving some scale and building the org and specializing roles within it. A good example: bringing in more marketing resources, business development resources, or a resourcing person handling the resourcing or trafficking, and then a recruiter on staff. Those were all roles that had been handled in a platoon manner where different people were sharing those responsibilities. But we thought, as we're growing, we need people who are dedicated to those roles — let's bring them in, it's another headcount, and as long as the revenue supported it, it was fine. But once you experience a little bit of a decline in revenue, that overhead — and a lot of these are non-billable resources — just starts to not make sense anymore. Especially if you're decreasing headcount, you no longer need a recruiter, and if you don't have that many projects to staff people on, the resourcing person no longer needs to be there either. The hats that the team wore and then spread out, you've got to kind of go back and put the hats back on again. We went from de-hatting to going back to wearing several hats. That's the cycle of business as it goes up and down. Obviously you want to be on the upward swing, but sometimes that's not always the case. Having lived through that, one of the things we learned is you actually have to get ahead of it as soon as possible. One way companies can get into trouble is as revenue goes down, they still — for whatever reason, vanity, ego, pride, whatever it is — want to maintain the facade of, hey, we built this. There's almost a sunk cost fallacy around it, like, look, we put all this effort into building this infrastructure, let's preserve it. But you're not really facing the business reality of it. You're burning a ton of cash while your business is unable to support these costs. You almost have to see the warning signs and make the decisive move to slim it down. And then once things rebound, maybe you rebuild it again — but maybe you find other ways to do it without adding headcount and you're more careful in the future. That's the experience we've had in that regard.
Sei-Wook Kim (20:54.377)
Yeah, the perspective is helpful, having gone through both directions. And the challenge is sometimes internal. If you extracted certain responsibilities from one person to several, and then as the team contracts, having to put those hats back on can be a challenge. But it's just about being clear and transparent with the team on what's happening, what's the situation, what's the path, and how is it going to be different this time. You may take a completely different approach — like having a full-time recruiter and going from that to more fractional resources. You don't necessarily lose the role or the person, but you may decrease the cost substantially. That person can still be on your org chart under talent recruiting, but it's not a full-time salaried person.
Peter Kang (21:53.507)
100%. One last thing I want to talk about before we wrap is leadership. As you get big, you might have director-level people, you might start having VPs, you might build out a whole C-suite. As you scale, you come across different types of managers — people who are overseeing teams, coordinating efforts of a department or a function, maybe a bunch of accounts or whatever it is. As these folks are in charge of other people, one of the things we've become more sensitive to is just what kind of — how high-level is this person versus how involved can they be? When you're really scaled up and you have layers of management, you don't expect a VP of design, for example, to roll up their sleeves and jump into Figma and start designing stuff. Their role should be hiring the right creative directors under them, having the right senior designers — they should really just be the GM of their own department and manage performance that way. But if you're at a much leaner structure where it's basically a design director and maybe some designers underneath, you want that person to have the flexibility and wherewithal to jump in where needed and be able to do some of the work. That's very important because sometimes you might hire the wrong person at the wrong time, and that can lead to some problems.
Sei-Wook Kim (23:55.184)
Yeah, it comes back to role definition. When we think about what this person is actually doing as a director or manager — how much of their time is spent on one-on-ones with their team, org design, recruiting, different aspects that are non-billable — you can outline all that. And maybe 50% of their time should be allocated to supporting clients. It may not be very on the ground, but maybe it's working with the execution team on the first pass of a design, or thinking through the strategy, or whatever it is. Every organization is different. But at a certain scale, maybe all their time is spent on management or non-billable tasks. It's always a balance, but just understanding specifically how they're using their time and what's the best use of their energy. The other thing — we talked in a prior recording about utilization and what targets you should be hitting — you can look at it also from the utilization of your entire team. If you have many people on the team executing and have high utilization, the director's cost and utilization can factor into the whole team and you can actually yield pretty strong results even if that person doesn't bill that much to the client. It's really just understanding at what scale, how many people they're managing, and what specifically they're doing.
Peter Kang (25:35.136)
Yeah, absolutely. This has been a great discussion on the importance of org design within an agency. The sooner you can get started in really thinking through the org design, the more it's going to yield and help you grow in an intentional manner. Thanks for tuning in, till next time.