Ep. 019: What the Holacracy? The Basics & Benefits of Flat Organizations in Development | w/ Special Guest Geoff Vandegrift of Ad Astra

You're listening to another episode of Open Source CXO, the podcast designed to share insights on how to excel in your business using technology, regardless of the industry. Host Robert Kehoe is a self-taught software developer who has grown to the role of CEO. Renowned for his collaborations with organizations such as Stanford University, Nelnet, and Louis Vuitton, he continually seeks new challenges to conquer in the world of tech. Joining him is Don Blackburn, a veteran COO with over 25 years of experience in cultivating diverse relationships and driving innovation in various technical projects.

Each week, they'll be sitting down with some of the nation's foremost technology leaders to develop an open source playbook, drawing from their firsthand experiences in the field. Let's talk some tech. Today we're with Jeff Vandergrift. Jeff is CTO at Ad Astra.

Welcome. It's good to be here. Thank you for coming. So, to start things off, why don't we talk a little bit about Ad Astra?

I'm sure not everybody's familiar, although it's been a company that's been around for quite a while. It is. They are, I think, celebrating their 28th birthday this year. I'm not sure exactly when it is, but so they've been around for a while, a software company for a while.

Their mission, it's one of the few companies I've worked for where I actually can quote the mission. It's to graduate more students faster. So, they are just about building solutions that help higher ed institutions meet their students' needs in a more planful way, you know, from making sure you're offering the right courses in the right format, the right place. It's actually startling how higher ed is not great at being thoughtful and planful about how they build their schedules.

So we help them do that, and as a result, you know, more kids are able to graduate on time. So it's mostly for the administration or the users? So we sell to, it's not for students at all. That's right.

Yeah, we sort of sell to the highest level because it's a strategic sell, but it's kind of the boots on the ground, like department chairs, registrars, those sorts of folks that use the software. And I'm guessing it's one of those things that's probably used in a whole ton of universities and... So our footprint is about like 500 institutions, and there's maybe, I shouldn't know the exact number, but higher ed institutions in the United States. We're purely North America.

It's like 4,000 or something like that. What's the development team look like at Astra? So my department is officially referred to as product engineering. So it has product management, testing, user experience, software engineering, of course.

And we've got 24 developers, I think, total. And I think the seven testers, we have a couple of folks that specialize in handling escalations out of support. And one experienced designer, three product managers, and then there's, it's a relatively flat org. There's just three managers basically for that org.

So like my director of software engineering has 24 direct reports. Are they all located here in the US? Everybody is in Kansas City. Oh nice.

We're in the office. And I think that's a really important part of developing software. I sometimes say that... Couldn't agree more.

Developing software is a social endeavor. There's people booing you right now. I know, I know. I get a lot of hate for it too, surprisingly.

That size of team, that actually sounds very similar to our size. It is. Even just the makeup of the entire team. That's really cool.

It's great. And the fact they're in Kansas City is even better. I love that. Big fan.

Absolutely. So interesting and totally side topic, nothing we've discussed before, but so you've got seven QA testers, 24 developers. Is that about the right ratio? Because that's something we're struggling with right now.

That's something we're getting into is QA versus development team and what's the right ratio there. Yes. I mean, I'll tell you my opinion. So we prefer sort of what I just call small, cross-functional, durable teams.

And by small, I mean like three developers. If four is okay, if you get to five, that's really too big. It's been our experience. And we want each of those teams to have a professional exploratory tester.

So that's basically how the math ends up working out. Our testers don't do any automation. That's all on the engineers. I don't like to separate those things, which leads to testing.

Leaves the sort of the professional creative testing to a human being. And that's what I have found. I did a stint at Perceptive Software where I sort of took over the quality group to try to get them up speed. And one of the surprising things I learned is that testers don't like executing manual test scripts.

Remember the old days? They'd write these test scripts down. I thought, isn't that what you guys like? Oh, that's the worst.

I hate that. But the ones that are really good at it really love kind of the creative, let me try this weird thing and really exercise those skills. So that's just what we've totally leaned into. And so we have testers that really love what they do.

And they're absolutely a first class citizen on the team. Their developers love these guys because they find so much good stuff. Yeah. Cover up the mistakes.

And then I give my developers trouble every once in a while going, now you're going to get lazy because you don't have to worry about working out all the bugs. You just throw the code over the fence and see what the testers do. I hope that's not what's happening. Yeah, I'm kidding.

That's interesting. So what was it like then at Perceptive, a much larger organization? Similar kind of a breakdown? It was actually, actually, yes.

Because they're still, that was still a SAS kind of. So, well, when I was there, it was they were in the middle of that transition. You know, they had been on-prem application for years and years. And then they were slowly moving into the host space.

And then I don't know, it was when I left, it was it was hosted was their cloud presence. And I don't know what they've done since then. But they were really in transition mode. Yeah, similar organization.

They you know, they had slightly bigger teams. They had more hierarchy in place in terms of management. But it was also a bigger team. Sure.

One of the things that, you know, on the SAS side, we've got a number of clients that are, you know, SAS related, have SAS products. But one of the things that we've talked about recently on recent podcasts was how to get the vision and everything down to the development level. Is that a big deal at AdAstron? I'm guessing because you've got to.

Well, you mentioned that you kind of have these small groups and teams, you know, just structuring those for one would be a question of mine. But how do you guys get that vision across the entire? It's a good question. I would say this is an area where if I, you know, you might have to guide me a little bit here if I'm understanding you correctly.

I do oftentimes find that things that I think are clear, I find out aren't. And what we've really been kind of trying to leverage recently is just this notion of objectives and key results, OKRs, it's relatively new to us within the last year or two. And by, you know, like we just as an example, we're getting ready to go into Q3 here. One of our things that we have to do is integrate with student information systems being that we're working higher at Workday.

You guys might use Workday for your HR provider. A lot of companies do, but they also have a student information system. So, one of our objectives in Q3 is that we need to basically be able to support integrating with Workday student information, Workday student, I think it's called. And so, like there's a couple of key results on there with two critical clients to be clear that by September they need to be live.

So we try to use stuff like that that is maybe less about the vision, but more about sort of the overall execution of the business, right? What are the business goals we're driving toward? But even just recently, you know, some stuff got lost in translation with another customer of ours where I thought it was clear to everybody that no, they're going, we've got people up there implementing them and they're going live on this date and then came to find out that wasn't clear to everybody.

It's a challenge. So it is a challenge. Do the developers get to understand who the client is and get to know the why behind things? We try very hard.

Again, it's one of these areas we struggle. We favor hiring developers that maybe, you know, I hate to stereotype, but maybe are a little less about the code and a little more about problem solving, like talking to customers, like, you know, and we have been successful in getting developers like that, but we aren't always great about getting them, you know, on calls with customers. Oftentimes, the product managers have to kind of play that liaison. It's logistics, but you do your best.

But the other thing I guess I have a little bit of luxury on, if you just talk about sort of the softer side of the overall mission and strategy is we have a very mission oriented CEO. You know, he just like will turn down money if it isn't aligned with the vision because he believes in the mission of the business that much. And so he every, you know, once a month we get together in an all hands meeting and he always takes an opportunity to cast the vision of where we're going and why it matters and all that good stuff.

So that helps me a ton. Yeah, I love that. And it's something that after that recent discussion, I was kind of we kind of went back out with the directors and went, you know, hey, maybe we should maybe we're failing a little bit here. Maybe we need to get a little more, you know, make sure everybody from, you know, the every single developer and QA and UI, UX, everybody really needs to understand the client vision and the why behind it.

You know, the why is the client building this product? But I also think you're right, developers jobs, not necessarily code. It's there's a lot of problem solving going on. And I think that applies personally, I think that applies to every player in the on the development team.

You know, not just not just leadership. So I think that's big. One question I did have, you mentioned smaller teams. How do you structure the development across multiple small teams like that?

I assume you guys are working on the same sort of application platform. Is it the same or do you guys have like just multiple products? So we are we have our legacy product, which we haven't we haven't touched in a while. And it is a it was an on prem thing that is at this point we don't actually I think we might have one or two remaining on prem customers.

But for the most part on that on that platform, it's all hosted. But since then, we're you know, cloud native, SAS first, you know, serverless architecture, all that kind of stuff. That's where everybody works now. Basically, we haven't had to do any patches on that old platform for, I don't know, four years or something like that.

But but but I assume you're asking like, you know, how do we how do we manage the work? Yeah, just curious. A little bit of overlap. Too many chefs in the kitchen kind of thing.

Right. That that can be that can be a challenge. I mean, we we we try not to have I'm kind of an anti orchestration guy. You know, I like I like let's just have the beast start eating away on it and you know, do what you need to do to go solve the problem that you're working on.

So again, objectives are sort of the for like for coming up on Q3, there's going to be three objectives and we've got I guess that works. I guess seven teams total. And and there will be some clarity about what objective are you attached to. So we'll have like three teams on one objective, two teams on another and two teams on another.

And then they work with their just work with their product manager. The product manager worries about these are the kind of things we need to go build. We think we need to go build. We try we're trying to get better to about guiding the development we do with like meaningful numbers like adoption and stuff like that.

Looking at our we use Gainsight looking at our Gainsight numbers to measure adoption. Not great at kind of closing the loop on that. We just sort of watch it and they're like hmm, it's not quite going up like we'd like to. But we got all this stuff to go build.

So let's go build that. But the product managers typically worry about that. Now again, our our CEO, we you know, he's he could also be called our chief product officer. He's founder CEO.

So he cares very, very deeply about how we're building this thing, what we're building. So weekly product manager, head of product, me, our head of sales, sit down with the CEO and talk about, hey, this is what we're in the middle of building. Still good. It's cool.

Yeah. And then and the teams just are you know, they are all in the same platform. We don't have hard ownership. People touch what they need to touch to get the thing done that they're building that, you know, that has its challenges.

But overall, we found that to work and we've experimented a little bit with hard or, you know, slightly harder ownership. It didn't get any traction. Actually, everybody was like, no, we like it better the way we were doing. So it you know, we just sort of like, here's the the chunks we need to eat this quarter and teams just start kind of what's the tech stack?

Are you guys in it? We're in AWS. It's node backend, react front end. We use all kinds of wild data storage technologies.

Dynamo, Snowflake, there's even some Postgres in there and others that I'm sure I'm forgetting. Just hopefully not Mongo. They were experimenting with Mongo when I started. You're not having luck with Mongo?

No, it's fine. I'm just I'm not a huge fan of Mongo myself, but it's got its use case. Again, probably people booing right now. Yeah, I get people booing me all the time.

I'm so used to it. Yeah. So speaking of that's a good transition into the management style. One of the things you and I talked about when we were on the phone was your transition into Milo in particular.

So you were you were progressive and then or Lex Marklin and then and then that you and a couple other guys transition into Milo. I'm interested in this Holacracy. Is that what it is? Yes, Holacracy.

I was hoping you'd talk about Holacracy. You threw that at me and I went I have no clue what that was. I immediately googled it. Yeah, it's going.

That's interesting. I googled it too. I thought it was interesting. I'm going, is this does this work?

Yeah, it depends on who you talk to. So I wanted to give you a chance to talk about it. It seems odd to me. Maybe there are some industries where it might work better than others, but specifically in I don't know.

Did you guys do that with that Astra or was it a different company? Milo. Oh, Milo. So that's a division of Lockton, right?

That was a ride. Although my understanding is they've sold it off now. I think going by private equity. So did you guys get together and go Holacracy?

Let's do that. Kind of. That's kind of what it was. So there were a handful of us that were like I had mentioned on the phone were disillusioned with middle management and like this is for the birds.

Let's go do something interesting. And I did not find it. Somebody was like, hey, you know, there's this thing out there called Holacracy or there aren't any managers. Why don't we go do that?

And we had this sort of in with the people that were founding Milo and sort of the handshake agreement we made with them was we'll come be your tech team if you let us do this wacky Holacracy thing. So they were like, OK. So we went and did the training. The guy that invented it is a guy named Brian Robertson.

He's written a book, pretty interesting guy. And they actually run training classes. It has gotten you may not be surprised to learn, but it's gotten a lot of more uptake adoption in Europe, actually, is where now they're these guys are all Americans based all over the country. But but they do training overseas fairly frequently.

So we got to go do that. And you know, I think I sometimes joke it was almost like a religious experience for me. I mean, my I got into software not so much because I was passionate about it, but because it was a way I could pay the bills, feed the family, that kind of thing. And there were aspects of it that I really enjoyed.

But it totally changed the way that I looked at work. And they have since they don't use it anymore. They got a CEO in at Milo that was like, yeah, this is not going to work for me. And she shut it down.

But but it was very eye opening for me. And I learned a ton. I don't know that I would like if I were going to go and maybe this is what the real litmus test is. If I were going to put my money on the line and start a business, I don't know that I would do Holacracy.

I think there's a couple of kind of fundamental challenges there. But boy, did I learn a ton. And it changed the way I operate. And I brought a lot of what I would call the principles or concepts from Holacracy with me to add Astra.

I mean, doing so having been in middle management and then doing the Milo thing, I was really primed for you know, I was a very reluctant leader when I got promoted into management at Perceptive. I was like, please, no, I don't want to do this. And and then but but after those two things back to back kind of realizing, I think I could I think I'd like to run a software shop. I think I could do some cool things.

And luckily, at Astra, the CTO that was there at the time knew me and kind of knew the wacky ideas I had rolling around in my head. He's like, why don't you come do that over here? So that was a really, really good opportunity. So so you know, I had a lot of fun getting getting it all set up.

And again, we still have a very flat organization, which I'm really proud of. And I think it makes for just a better way to do things better way to live for leaders to So what are the basic principles on holacracy is basically there's no management. There's that's right. It's extremely flat, right?

There's no. So what what Brian Robertson, again, the inventor would say is that it's not like there's no hierarchy. There's a lot of there's there actually is a lot of hierarchy, but it's it's abstract, you know, it's and it's easy to put people in and out of that abstract hierarchy. So one of the like, I think, critical concepts, if you just take management for a second, if you're looking to hire a manager, what are the skill sets you're looking for there?

There's a lot for like a subject matter expert, an administrator, a project manager, somebody that kind of gets the HR side of things, hiring, firing, performance management, that kind of stuff, you know, internal political navigation, you know, external partnerships, it's just on and on and on and on. And finding somebody that can do all that stuff, that's a unicorn. That's really hard. Yeah.

So one of the one of the I think, I mean, it seems obvious in retrospect, one of the things that holacracy does really cool is it's like, well, no, you can slice all that up. And then, you know, people in the in the business can fill any particular roles that they have skill in or passionate about. So like an ad astro, what I I use that to break up certain things like we don't call them roles, we call them annotations. So engineers can pick up annotations that are, you know, in the system, you know, but we have like this notion of advisor, and the advisor is the is the person you have your one on ones with.

And this and that person's charter stole this from Kim Scott's radical candor, that person's charter is to give a damn for the people that you advise, you give a damn. So if that person doesn't show up to work, you care about that. You know, what, how are things going, making sure that, you know, maybe career conversations, that kind of stuff, but you're not evaluating doing performance evaluations. So you've got certain people that like that kind of stuff, certain people don't like that kind of stuff.

No problem. You know, we have a notion of each of those teams I was talking about those cross functional teams. They they have a team representative and the team representative is actually elected by the team. And they get to decide so that person I might reach out to if I need information about something the team is working on or we have a weekly department meeting where the the team reps come to speak up.

But but so that's one of the one of the principles and holacracy that you slice up those responsibilities and people just opt into what they have talent for. And even if it's not normally traditionally in there. That's in their purview, so it allows people to branch out a little bit. It absolutely does.

And it allows them to even experiment with it. Right. Like, you know, like, hey, I think I'd like to try out that advisor thing. OK, cool.

Three months later. That's terrible. I hate it. OK, no problem.

So you're no longer advisor. It was not a promotion. There wasn't a pay change associated with it or anything like that. You know, and that that's or maybe, hey, I've got to really I got a lot of crap going on in my life right now.

I need to like opt out of some of these things. That's fine, too. Interesting. But it could be anybody.

It could be a developer. It could be a QA person. It could be a seems like a little hard to manage. Like, how do you know you're fulfilling all of, I guess, on manatations, all of the skill sets that you need to be covering?

Well, I mean, for like the advisor one is maybe the easiest it would be. That would be at the discretion of right now. It was me, but now I have this director of software engineering and he would care for whether or not the advisors are doing a good job. And so it could it could be a mutual conversation like, yeah, I don't think you're really fit in that kind of that role all that well and could then say, you know, try again later by somebody else.

And there's multiple. Is this a software led sort of structure? Do you guys when you mentioned that they could pick up these, you know, annotations or these roles or skill sets? Is it something they see like a list?

I mean, we don't have tons of these things. There's like three or four. Oh, OK. OK.

Yeah. So they're most of them are obvious, like team rep and the advice. Here's how far you break down. Yeah, not very.

Not too far. Anything beyond that would be more organic. OK, that makes sense. Is this you talked about and I don't want to beat the Holacracy thing to them, but it's obviously been adopted across the country, right?

Yes. What are some of the other big shops? Yeah, the most famous is Zappos. Oh, that's big.

And it's funny Zappos. So every time you turn around, there's a bunch of noise about Zappos has decided to abandon Holacracy, but it's it's always fake news. This never actually happened. But they you know, Tony Shea, when he was still alive, was kind of a crazy guy, did all kinds of crazy stuff, and he decided to adopt Holacracy.

And my understanding is Zappos runs really well. And when they were purchased by Amazon, they let them continue running Holacracy. Again, in my understanding, I'm not super close to it. But beyond that, I don't know that there are any other super recognizable names, at least that I'm aware of.

Right. Right. And how do you find that? Do you think most of your employees love that?

Well, you're not doing it now. But yeah, I mean, again, it's you know, we have a flat org. So there's a lot of flavors rhymes with Holacracy. But but yeah, I mean, it's it's there's there's sort of a self selection mechanism.

Like when we're when we're talking to people, we have to be very clear, right? Like this is just, you know, kind of a self managed, you know, organization, you need to you need to be a self starter. If you're like looking to climb a corporate ladder, we just don't have that here. You know, we we don't we don't even have architects, actually, you know, and with kind of the idea that we sort of permissionless innovation, just go build cool stuff.

We have a lot of good guardrails in place to keep us from going, you know, off the road. But but it tends to be a self selection thing like that. I you know, I think most people when they hear about it, it seems cool. We hire a lot tend to hire pretty new and career folks.

And so that's a great opportunity for them, right? They can come in and start, you know, doing all kinds of gravitate to where they're comfortable. Right. For sure.

So, you know, it's it. But not the place if you want to be a VP or director. That's right. There's not a whole lot of space for as it turns out.

But you know, in my experience, this isn't always the case. But in my experience, engineers, you know, that's they just want to build cool, build cool stuff. They typically aren't looking to do all that, you know, like me. Don't make me a manager.

Don't make me a manager before I realized it can be interesting. Right. Right. So have you gotten into is one of the things I always like to ask is we're going through these because it's everybody's different at this point.

But have you gotten into AI? And it's such the topic anymore is AI, not in any sort of organized capacity. You know, it's sort of like ground up. I know some folks are experimenting with some of the things like co-pilot or whatever.

But beyond that, no. Now, I do think in our space, there is room for some meaningful machine learning. But we've got, you know, at this point, lots of nuts and bolts to care for. So so no, nothing formal.

I guess. How about you guys? We're starting to hear it more and more. And you know, it's one of those things that's so prevalent in the media, right?

That's all everybody wants to talk about. So obviously, the clients are going to get it. Well, they usually come to us. Hey, what can we do with AI?

So we'll have to lay out a plan. That's why I figured you'd be hearing it too, right? From your clients, from the universities going, how can we make this better with AI? They usually get more funding access when they can tell their investors, hey, we can do AI.

You know, to be honest, I don't know that we have gotten a lot from our our institutions, actually, I think they, you know, higher ed is not super. And yeah, no, I've got one of my best friends works at Austin P. and they are he's a great dev but they are slow at it. Yeah, they're not.

I wouldn't call them at the cutting edge. No, that's true. Typically a little far behind from the IT perspective. But wow, you would think the leadership though would be going, hey, how do we do it?

What can we do? And you're right, funding. Yeah, you know, there's plenty of funding out there for everything. AI.

Now, this is great, though, man. And I do appreciate you taking the time. I hope you felt good about it. Oh, yeah, absolutely.

Great.