• The signals that your current org structure is holding the firm back — and how to read them before the numbers confirm it
• A practical test for whether a manager is actually improving a function or simply supervising it — and why the distinction matters at scale
• How to correct titles that were handed out too early without losing the people who hold them
• The communication cadence for a reorg: who hears it first, in what order, with what talking points, and by what date — because most reorgs fail on communication, not design
• Span of control limits that hold up as the firm scales, and what breaks when you exceed them
• Going back to an earlier structure is a deliberate decision, not a failure — if you know why you are doing it

Jeff Klaumann: Hey everybody, welcome to the Pro Serv Podcast, brought to you by Collective 54. I’m Jeff Klaumann, I’m the president of Collective 54, and I’m your host. If you’re new to the show, here’s what we’re all about — helping you do three things: make more money, make scaling easier, and make an exit achievable. Everything we record here is exclusively for boutique professional services firms. So if you’re in the expertise business, if you market, sell, and deliver expertise, this show is for you.

We have a great org structure topic today. Most of us who run firms treat orgs as a one-way move — we draw the better org chart, we announce it, and we never look back. But the right structure changes as the firm grows, and as the people running it grow. Our guest reorganized his firm around service lines, then moved back to a structure that had worked before. That story is the show today.

To help us think this through, I have Adam Blake on the show. Adam is co-founder and COO of Magna Technology Group, a boutique Salesforce implementation and Anthropic advisory firm. He co-founded Magna in 2017, and since then has taken the firm through two reorgs — and reversed one of them as the firm scaled. He’s a Collective 54 member, I know him well, and he has lived this one from the inside. Adam, welcome to the show, great to have you here. I’ve given everybody the headline, but tell them a bit more about who Magna is for and the problem clients hire you to solve.

Adam Blake: Awesome. Hey, thanks for having me on, Jeff. So we started back in 2017, and we knew we wanted to work in sales and marketing services — that was my background, that’s where we knew we wanted to start. We have grown into an implementation shop for Salesforce partnership. We’ve grown across their entire ecosystem in sales and marketing technology, and now we’re doing some more Anthropic-related advisory work as well — getting started there in addition to what we’re doing with Salesforce, so we’re really excited. We’re about 82 folks, scaled across India and the U.S., and we work across a number of different verticals — from retail, consumer goods, manufacturing, travel, financial services, healthcare — you name it, we’ve done a few projects there.

Jeff Klaumann: Outstanding. Adam, take us back to the early days of Magna, when you were running functional teams. What did that look like, and what pushed you to reorganize around service lines?

Adam Blake: Yeah, it’s interesting. When we first started, everyone was a generalist — everyone had this nebulous analyst term. We didn’t spend a lot of time on correct titles or correct advancement. My partner and I focused 95% of our time on how do we deliver the best type of service, and how do we talk about it so we can sell more of it? That was all of our time. So our website was awful, our titles, our team structures — everything was kind of a backseat to everything else. I was the first manager, leading all delivery functions, and my partner was leading all sales. Up until about 25 people — probably up to 2021 — everyone was doing everything.

We organically grew first-year employees, people fresh out of college, into a manager function, which meant they were responsible for the outcomes of the project and managing people. Looking back, I did an awful job of coaching them — this is how you coach people, this is how you deal with specific problems — but we hired people that were significantly smarter than us, and they figured it all out.

Functional teams grew because we got to a point where we were doing some really technical work, and we realized, oh shoot, we need a developer. The common person can’t do this — we should probably get someone who specializes in it. So we hired our first developer pretty late, a few years after we probably should have. Then we realized we needed someone who could manage developers, because the common person doesn’t speak the same language — that was my opinion at the time, and I don’t share it anymore. So we grew into these functional teams. Project leads managed project leads, a development manager managed developers. We’re a 25-person company, like wild west gunslingers trying to figure this out.

At that point, we realized we didn’t have structured titles. If we wanted to hire someone from the market, everyone up to that point had been hired fresh out of school — built up, grown organically. That works exceptionally well, and it really helped us manage culture. We hired for aptitude and ability over experience, and that served us well. But the challenge is there was no specialization in roles. People were doing kind of everything — you gotta sweep the floor, you gotta build this type of custom work, you gotta make a project plan, deliver documentation and training. You’re wearing too many hats.

So we started to specialize and build functional teams. We built an analyst team, and then in 2023 we decided we needed to build some more platform-focused specialization with a cross-functional team structure — meaning project leads, solution architects, and developers all work together on similar sets of products on similar teams. We moved in that direction because we wanted to open up communication. We felt that if you’re working with the same people most commonly, you’ll get economies of scale by pulling them together. Also in the early 2020s, we didn’t have a ton of managers who were capable of managing people, so we put our best managers in those positions to lead.

What’s really challenging about any type of reorg is that it takes a lot of communication. You’re telling someone: I’m going to change your title, I’m moving you to a different boss, you might be working on slightly different things. Out of all the things we did, I thought we did the communication cadence really well — we had individual one-on-one conversations, we had specific bullet points we’d go through for anyone who had major changes. I had conversations with them in person, sometimes going across the country to find specific people, just to make sure everyone was on board. It wasn’t an announcement of hey, this is happening, good luck. It was a really carefully constructed cadence. I remember being at a previous company and finding out in a room full of 15 people that my boss just got let go, and I remember thinking: man, this sucks. I wish someone would have told me so I could ask questions instead of making all these assumptions.

Jeff Klaumann: That’s super helpful. One of the things I want to put an exclamation point on is what you just described — when you have somebody who’s sweeping floors, leading an engagement, creating a project plan, and everything else, that’s just classic role corruption. It happens so often in boutique firms as they go through the process of growing and ultimately getting to scale. It’s kind of how you get yourself there, but the downside, of course, is that role corruption you were ultimately working to address. So I appreciate that you tackled that.

Adam Blake: Yeah, in that org structure change there was also a lot of role, responsibility, and title shifts. We were giving out “Senior Solution Architect” to people who had 3 years of experience — in our industry, in Salesforce, that could be a 10 to 15 year title you earn at the end of your career. It’s like giving someone fresh out of school a CMO title — it doesn’t match. You put someone on a project with that title, it causes more friction. So in the first reorg in 2023, we were also course-correcting titles. We moved someone from a Senior Solution Architect down to a Solution Architect I.

I give the entire team a lot of credit because they took that in stride. Their roles and responsibilities didn’t change, but the title didn’t reflect the industry — if we wanted to hire someone or put them on a project, it just didn’t make sense. And for this entire restructure, it wasn’t just me. A number of people on the team were working to figure out how to correct titles, how to move people into different teams, how to structure it so each manager didn’t have too many direct reports. We tried to stick to no more than 5 direct reports and no more than 20 on a team. We’ve failed a couple of times where a manager ended up with way too many people, but those are the general numbers we’re aiming for.

Jeff Klaumann: Yeah, very well thought out and structured approach — kudos on that. Well, in the pod structure your team leads were your best people and you didn’t put people in the wrong seat, so to speak. So what broke, or what wasn’t working, and when did you know the structure had to change?

Adam Blake: Yeah, so we just rolled out another change last month — we are going back to functional-style teams. A huge reason for this was that a manager was managing multiple functions, and it felt like nothing was drastically improving across each function. If you have to manage 3 different types of people, that means 3 different types of reviews, process improvement, SOP writing, KPIs, and reporting — it just didn’t feel like anyone was being truly specialized in one specific function.

The other issue is that we’re trying to focus on cross-training. Salesforce has a dozen-plus different types of technologies, and we’re really encouraging each person to get cross-trained onto multiple platforms. Having teams that are product-specific doesn’t really enable that. It’s really hard to say, okay, you need to start working on Service Cloud, but that’s another manager who manages that staffing and deployment — good luck. It just doesn’t work.

I grew up working in restaurants, and I remember on my first day they said: you gotta learn how to be a host, you gotta learn how to run food, you gotta learn how to wash dishes — and then you can start bartending. We try to take that same approach here. When you’re on a million-dollar deal, you need your best people on it. But there are a lot of deals where we can figure it out, and I’d like to cross-train as many people as possible, because deals come in different shapes and sizes at different times — and you need that flexibility. So that was one of the biggest things driving the change back to functional teams.

Jeff Klaumann: So that’s fantastic. A lot of founders maybe wouldn’t have looked back to a previous structure and said, hey, we should go back to that one. I know it’s early, but what are the early indicators about how the functional approach is working now?

Adam Blake: It’s interesting. When you have cross-training plans, knowing where you need to develop new people, working through certification plans — that’s just much easier when you’re in control of the entire function. Our solution architects and our developers were managed by two different people, and it’s just much easier to have more control in one place.

There are no numbers yet, but I will say it just feels like we’ll have a better plan. We’re in our slower time of the year, which is why we did it now — you don’t do a reorg in peak season when everyone’s a foot underwater and then say, oh by the way, you’ve got a new boss now, see you later. We try to pick a time when we’re a little slower so that every manager can have one-on-ones, hold their team meetings, go through conversations about professional goals and how they can support their people.

I’m really excited. There are a lot of new initiatives started by each individual manager in their function. On the dev side, we’re moving to Jira in January, and that’s led by the folks leading the PMO teams. On the Solution Architect side, we’re really working on building better design, better documentation, and cross-training. It just feels like it’s really moving in the right direction. I think everyone feels comfortable with why we made this change. And I always tell people when we’re going through any kind of transition: we can always change back. We’re 82 jet skis, not one big oil tanker — we can pivot really quickly. If this isn’t working, we can always go back. Our first major restructure was at about 25 people, the second at 45, and now we’re at about 82, and that’s the story of how we’ve gotten here.

Jeff Klaumann: I share your thinking. None of this is forever, you can always change, and everything we do as entrepreneurs is a test — you try, and you make adjustments. I agree with that.

Adam Blake: It’s really interesting to also think about what’s going to happen in the future. I think vertical-specific is probably where we’d like to be, but we’re not large enough yet to have vertically specific people. If we get further into AI advisory, I keep thinking about whether we want to be function-specific — a group that really just focuses on operations-related functions, or marketing, or sales. As we continue to grow, we’ll keep our ears to the ground and ask: what’s really important right now, and do we need to shift or make changes? I think our team is just really used to this from being in a startup — they’re used to constant change, so it’s been a little easier.

Jeff Klaumann: Adam, there’s a founder listening to this who is about to execute a reorganization for their firm for the very first time. Knowing what you know now, what would you tell them before they announce it?

Adam Blake: First, make a plan. Talk to the people this affects the most — your top middle management — and walk through the problem you’re trying to solve and the structure and layout you’re proposing. Talk to them individually to get buy-in. You need buy-in from the top to make sure this works.

Then build a cadence. Once everyone at the top is bought in, put together how this will roll out in as much detail as possible. Are titles changing? Are roles and responsibilities shifting? Is comp changing? How does this affect each individual person? Then have those managers go have one-on-ones with their individual team members and communicate what’s happening. Talk to the people who are most affected.

When we did our second reorg, the people I was most concerned about were those going through title changes — anyone getting retitled to something more appropriate. I cared a lot about making sure they understood why. So go through your plan and focus on: what’s the problem we’re trying to solve? Speak to your top people to make sure it actually solves that problem. Map out how you’d execute it. Then build a sound communication cadence — what are the talking points, who do you talk to, in what order? Provide dates, make sure everyone signs off on going through that, and then execute that communication plan until it’s fully rolled out. Then pick a date and say: great, let’s go.

Jeff Klaumann: I couldn’t agree more. You really have to make sure your communication is very well thought through when you execute a plan like this, because the things you don’t talk about, people will make up in their own minds — and that’s where friction starts to form.

Let’s tie this back to how fast a new hire gets up to speed. How long did the ramp-up period to truly being billable take under each of those structures, and what are you aiming for now?

Adam Blake: I’m not sure if onboarding time improved specifically as a result of the reorg, but it has improved tremendously overall. When we first started, it would take about 6 months for someone to get to full billable capacity. I did reports on who the highest performers were that got promoted, and what the onboarding time looked like for middling performers. Now, in about 30 days, someone gets very close to billable capacity. Sometimes it can take up to 3 months, depending on seasonality and available work. We’ve also just gotten a lot better at information on hiring and when to hire — it’s really tough with a small sales team because your sales can be pretty volatile, and our sales cycle can be 2 or 3 weeks, so you’ve got to be ready.

It’s improved a lot from being able to put more structure and focus on 30-, 60-, 90-day plans, building training libraries and SOPs. We have a Google site right now with our employee handbook broken down into smaller SOPs, along with training videos stored on each page — here’s where you need to go to start. And then we pair new hires on projects from day one. We give them simple, easy tasks that keep confidence high. I tell people when they first start: you’re getting thrown in the pool, but you’ve got 82 lifeguards around you. We’re here to support you and give you help when you need it. There’s no 6 months of training before you ease in — you get staffed on projects right away. Maybe your time doesn’t fully count at first, but you keep ramping until you get there. Overall, onboarding has improved dramatically, largely from the team’s ability to onboard new people fast — and I’m sure the reorg has had a little to do with it too, just from having a larger team, but I don’t have the ability to quantify exactly how much.

Jeff Klaumann: Understood. One final question, and then we’ll wrap up. If a founder is thinking about a reorg and needs to get their thoughts together, what’s the first thing you would advise them to do?

Adam Blake: I really love this — I got this advice from another Collective 54 member: build a responsibility chart. It’s not just who reports to whom — it’s what are their roles and responsibilities. If you can tie things even up to a P&L on your org chart, showing what each person is responsible for and what they interact with, and do any type of roles-and-responsibilities mapping as it relates to the org chart, I think that’s really helpful. Yeah, I think that’s a huge part of it.

Jeff Klaumann: Fantastic. Well, Adam, you’ve shown us that an organizational structure must match the stage, scale, and size of a firm — plus, of course, the managers themselves. That’s a real contribution. I really appreciate you being here today.

Adam Blake: Yeah, likewise. It’s been a journey and it’s still moving. Hire smart people — every person I’ve brought on has been a lot smarter than I am, and that’s been tremendously helpful. A lot of these reorgs stemmed from people starting conversations and putting together what this could look like. It’s not me doing each one of these — it’s been a collective effort. I just focus on hiring and bringing on the right people. That’s been something that’s worked really well for us.

Jeff Klaumann: That’s fantastic guidance. Members, Adam Blake will be joining us for our private member Q&A session, where you can ask him your questions directly. And then I have two calls to action for you before we wrap up. First, if you’re not a member and you want to keep the conversation going, head over to Collective54.com and start a conversation with our AI agent and our team. Second, our founder Greg Alexander has a new book coming soon — it’s called The AI Native Boutique Firm: How Founders Build More Valuable Firms When Services Become Software. It’s available for pre-order on Amazon now, so check it out. Thanks for listening. Until next time, I wish you the best of luck as you grow, scale, and someday exit your firm.

‍