189. How to build a $10M company without meetings or managers, with James Hawkins, Co-CEO at PostHog
55:09 Share

I'm James Hawkins. I'm the co-CEO alongside Tim, my co-founder of PostDog. We are a dev tools company. I've never worked for Facebook or Google or Netflix or somewhere sexy. I've kind of always worked for like random little startups that have always had a hard time. And so I think I just want to back the underdog constantly. Y Combinator, you know, has like, I think our batch is probably like 250 startups. They're probably in total about 500 people.

We're going to go from, I think, about 80 people to 190 people, something like that. We wanted to create a series of small startups, essentially, each with their own metrics and tracking and all this stuff. A small team is, first of all, no more than about six people.

It is multidisciplinary. So the point is that teams can do work entirely as an item. We want to make sure that the team's well-rounded, like it needs to be able to ship the entire product by itself. It's challenges. It's not everyone fighting to be the manager. It's people fighting to not be the manager. Then we've also had managers swap with one of their direct reports and the manager has proposed it going, hey, I think Joe Bloggs who reports to me, Mary, should actually be my boss and I should report to them. What you'd end up with is...

Cool, now you've got two or three people working on something rather than a hundred people kind of like probably doing the same thing. Let's talk a bit about the actual, the type of person for whom this would appeal. We absolutely will get pushback and we've had people refuse before. The normal reason though why people won't do that, often what ends up happening is...

Hello and welcome to Truth, Lies and Work, the award-winning podcast where behavioural science meets workplace culture. We are brought to you by the HubSpot Podcast Network, the audio destination for business professionals. My name is Leanne. I'm a chartered occupational psychologist. My name is Al. I'm a business owner. And we are here to help you build amazing workplace cultures.

Today, we are joined by James Hawkins, the co-founder and co-CEO of a company called PostHog. They're revolutionizing how tech companies structure their teams. James has built a $10 million dev tools company by throwing conventional management wisdom out of the window.

So instead of having these rigid hierarchies and planning meetings and all that kind of stuff, Hostog operates as a collection of tiny autonomous startups, and they're scaling faster than most traditional organizations could ever dream of. With so much focus on optimizing workplace processes and leadership structures,

We rarely talk about the psychological impact of giving people genuine autonomy. The research consistently shows that when teams have real ownership over their work, engagement skyrockets and productivity follows. Yet despite this evidence, most organizations still cling to outdated management models and don't even train their managers in them. They prioritize control over creativity.

Post hoc has taken a radically different approach, one where engineers ship first and ask questions later, where team leads don't earn more than their teammates, and where the CEO might temporarily join your team to help with a project before disappearing for months. In this episode, James offers a refreshing perspective on how organizations can build cultures of radical transparency, eliminate unnecessary bureaucracy, and create environments where people can do their best work.

After spending an hour with James, I realized he's taken everything I thought I knew about running a fast-growing company and turned it completely upside down. So maybe you're a business owner struggling with slow decision-making and wondering why your teams can't move faster. Perhaps you're a manager drowning in meetings instead of doing real meaningful work. Or maybe you're an employee who feels micromanaged and you wish you had the freedom to actually build things faster.

Over the next 45 minutes, James will tell you the story of how he uses small, high-performing teams that operate with minimal oversight to deliver exceptional results and very, very fast growth. After this very short break, join us as we discover why the future of work might not be about better management, but about creating environments where management is barely needed at all.

Al, you've spent hours on Tumblr, haven't you? Yes, I have. I'd jump on for just like five minutes and look up and it would be 11 o'clock. Well, guess who's just solved a huge problem for Tumblr? Mm-hmm. I think I know the answer. You do? It was HubSpot. HubSpot to the rescue yet again. So this is what happened, right? Tumblr needed to move fast to produce trending content, but their marketing team was stuck waiting on these engineers to code every single email campaign. And Al, you know how engineers want everything to be perfect.

Well, fast forward to today and they now use HubSpot's customer platform to email real-time trending content to millions of users in just seconds. And the impact? Well, it's had three times more engagement and double the content creation. Very nice. I know. If you want to move faster like Tumblr, visit HubSpot.com.

Let's go and join Al and James and hear how PostHog does everything just a little bit differently. I'm James Hawkins. I'm the co-CEO alongside Tim, my co-founder of PostHog. We are a dev tools company. We aim to help developers build successful products and we give them all the stuff they need to do that. We have like 14 products at the moment.

I think it tells what I'm famous for, probably just being incredibly intelligent, strong and good looking. But apart from that, mainly for being very transparent online and sarcastic. So you can look up how we work

uh in the open we have like hundreds of pages of how our entire company operates and stuff on the internet um and we kind of regularly go viral for kind of talking about how we work basically looking at your website it does feel a bit like i've got unauthorized access to your notion wiki it does it feels a bit like i shouldn't know these things um i've got i've got loads of questions about small teams but just so i understand what made you decide to do everything in the open uh in the other days it was about trust we when we're

just two idiots building something from scratch with nothing. We're like, well, how can we get people on the internet to kind of trust who we are before we were remotely kind of legit? And...

I felt, well, transparency is kind of the foundation of trust. So if we're much more transparent than a normal startup would be that puts just a one-page website up, I think it will help give users the confidence to use our software before we've got any kind of reputation. So it kind of started from almost a marketing and external branding kind of perspective. But the reality is it's wound up being much more important internally for how we operate because there's this interesting effect of...

it's like having someone else market your homework like if your internal um wiki or notion or whatever isn't exposed to the world it's gonna be kind of badly written and not that well thought out most of the time or like it's kind of very secondary to most companies i think um

But if you know that you'll get like angry mobs on the internet talking about your like policies around hiring or firing people or whatever it might be, it just means you have to be a bit more rigorous in how you think through stuff. So let's talk about the tweet that I caught your eye or that caught my eye was the one about small teams. So I want to get into how you, why you decided to go small team, but just give us the context. What is a small team to you and what does it have to have and not have? Sure. So,

A small team is, first of all, no more than about six people. It is multidisciplinary. So the point is that teams can do work entirely as an island. We want as few dependencies as possible between them. So, for example, at PostDog today, we have a team for each product that we offer. And they're like two to six people on each team can entirely decide what they're going to work on, ship it and improve their stuff.

in an ideal world without any dependencies on any other team whatsoever um and that lack of kind of dependency and need for kind of alignment or coordination or meetings um is the kind of part that's been particularly important to us so like what actually looks like in practice you a bit more flavor maybe is um it would often just be for us it could be like four or five just engineers but we're trying to make sure that we have kind of people who can do a bit of we want to make sure that the team's well-rounded like it needs to be able to ship the entire product by itself um

So you can't just have all backend engineers or all front engineers or all designers or all PMs. Some of the teams will wind up with someone who's less technical in the team too. But yeah, the primary thing is this team needs to be able to build products without outside interference. That seems to me from the outside, it seems like it's all about small team startups being scrappy. Is that where the idea came from? What made you decide, yep, we're going to do small teams here? I'd say there are two things that

led to this decision the overarching theme was our product strategy is to build every single piece of software that a software team needs which means like a ton of stuff and so like okay what are we and we asked ourselves kind of first before we structure the company we were asking ourselves about product strategy like what what are we trying to build like we're going to basically i'm a huge believer in your kind of ship the org structure um

And so it's like, well, okay, what are we trying to ship here? Okay, we're trying to ship potentially 100 products at some stage or another. It kind of like what AWS is to infrastructure. We're kind of like that for two software. And so what are we winning on? Are we winning on kind of, do we want an org that's designed around kind of control and design and polish? Or do we want an org that's geared around kind of velocity? And there is kind of a trade-off, I think, between the two. And we concluded like, we're not going to win on design polish here. We're going to win on engineering velocity. So the entire company is...

designed to ship quickly okay well who has the greatest engineering velocity like where can we look for examples of particularly productive organizations per person um and it just felt obvious that startups are will ship the most per person where there's like one or two people will build an entire thing um and then y y culminator you know has like i think our batch is probably like 250 startups so probably in total about 500 people um

that will ship um probably like eight or nine hundred products because a lot of people will build one product it will fail they'll build something else it'll be like wow that is like a ton of products whereas there are big companies that would take that many people to ship one product obviously it has to scale more and so on and we're like okay what is it like being a yc company and basically you have complete freedom like you live in your own apartment together you just build whatever you want um and then kind of every week or every two weeks or so you have office hours with a one of the yc partners and the yc partner is kind of like your

you know, spiritual guru kind of coach who can pattern match across the other couple of hundred startups or thousands of startups they've dealt with. And so they can kind of just help

steer the ship a little bit if you're going wrong so you'll show up being like oh no one's paying for my thing what should we do like should we pivot should we keep going and they can help you with these big directional kind of decisions but they're not going to tell you like what to build at all um sometimes it's just encouragement like hey this sounds great don't just keep going um other times it's like hmm sounds like no one cares about your thing and you're screwed um and so we kind of

we're like well how can we build an org that feels like that it's also super motivating to work in that kind of environment because it's a really high ownership um and so we wanted to create we felt a postdoc like a series of um small startups essentially each with their own metrics and tracking all this stuff we think would be would feel very similar to work in so we'll probably be more productive and there's like no committees no meetings whatever and then the other example we had was um

I went to a talk by Jeff Lawson, who runs Twilio. He's ex-Amazon. And he opened the talk with, I think that Amazon's greatest innovation is small teams. And he talked about it's kind of run by lots of startups. I can also see a really good example there. If I look at like your word developer product, AWS is like an $80 billion run rate business. And it's hundreds of small teams. Yeah.

So we could see an example at extreme scale in one company putting this off, which was kind of enough for us. So that was kind of the reasoning and then the inspiration for it. So we have the advantages of small teams give the advantage of engineering velocity, of engineering velocity, I think you said. A lot more ownership over the product.

But it sounds like the trade-off is that, A, you don't get, as the owner, as a company, you don't get control over what gets shipped necessarily. And B, it might not be perfect, if I understood that. Yeah, absolutely. But it can also mean not having ownership can't be a good thing if your team are smarter than you. So I would also argue that I'm 100% certain our company would not be successful had I been able to control everything anyway. Because our...

some like i would say our most impactful ever idea was going from one product to two products and that came from an individual developer having the freedom to just build what he wanted if you have a genuinely really strong team that can cope with lots of autonomy and there are loads of implications for kind of how you hire and the kind of people that will succeed in this environment um i think it's actually given us a

we've we've gone from like a series of local maxima as a business like we've been at the top of a curve that seems pretty good like we're making some money in the early days compared to no money at all um but we've changed strategy multiple times because of this because it's created a lot of chaos and our strategy has been us kind of labeling what's good in the chaos that can unfold when you have lots of people working quite independently of each other um i could go on for ages about this like for example uh

I was reading a book on how do empires rise and fall. That's in Roman Empire. This is 15th century. How can all these tiny European countries dominate the entire world, even though they're so small? They don't have as many resources and stuff. The book's making the argument that there's chaos in Europe where there's all this warring going on and it leads to someone inventing the gunpowder and then suddenly you have this massive advantage and now

um one small country you can have an empire that spans the world kind of thing um so it's a little bit having a little bit of chaos in an appropriate dose um can lead to a greater outcome than the like grandiose vision you have in your head as a founder and because i'm not like steve jobs or something you've already said apple wouldn't that your way wouldn't work necessarily apple when they have to be pixel perfect when they're just they're obsessed by design stuff

But let's talk about something like, let's say Buffer. So you are something like Buffer, where you've got one product. If you were in charge of that, would you still break out into small teams? You would. Yeah, I would split the product conceptually into different use cases, for example. Or I still think you can get much greater productivity if you're able to put off small teams versus having like an engineering org of like 100 people or something. And then like a bunch of product managers in a different

silo um but the way i'd approach that if i were buffer would be like okay um we'll have a team who focus on like the activation flow into the product for example like a growth team i would have a team working on like um maybe like the editing experience i have another team that work on like the api connections to systems that it publishes to so i would probably try i would work pretty hard i think to try and consider each of these things um semi-separately because i'd also argue that i don't think buffer is a product that

anyone uses because of its slick design like it basically just lets you post content across lots of different places pretty easily but it's not like oh it's like the inspiring aesthetic beauty of its ux is the reason i adopted it i would advocate for that because i think what you'd end up with is cool now you've got two or three people working on something rather than a hundred people

kind of like probably doing the same thing um i think there's just this effect in engineering where it's like the first few people working on idea could go so much further um like it's so ridiculously disproportionately far compared to like the 50th the 51st person the 100th person you add to a team that um because of accountability basically um and freedom and not having to get committees and stuff so yeah i would still advocate for breaking what might look like a single product company into multiple products um

so that you can have better ownership everywhere from your engineering team. You just mentioned duplication there. Now, this, I think, would be one of my biggest problems is I've got, let's say that I've got six teams, each between two and six people in it, and they're all working on either different contexts of one product or different products.

I'd be worried about two things. First of all, are they working on the same problem and are we wasting resources? And secondly, even if they are, how are they sharing the knowledge between the team? I think there's actually two distinct problems there. I think on the duplicate effort is one of the downside risks. But I think it's kind of like saying,

oh if i buy a porsche there's no point because like a bird might poo on it for example i was like well you know let's just wipe it off and keep going like overall you have a porsche um and it feels a little bit like that to me like okay cool let's take 10 steps forward and then one to the side one backwards by accident but like net we're probably up like nine steps compared to where we would have been had we still been doing the pre-meeting for the pre-meeting for the meeting to plan the thing um so i think that it is one of the potential downsides i would argue it works is less likely to occur i think in a remote organization where there's a written culture like

We're very transparent and people can just see what every single team is working on. And so that's like one way that information bubbles around. As we're getting bigger, like we have about 27 teams, I think at the moment, something like that. There is now a ton of

there's like so much written stuff happening every day that um there's probably a little bit too much to keep on top of um i think the second but there are a couple other places so for example in our all hands because we prioritize um like velocity and shipping basically and because it's the primary thing we're good at and winning on um we do like a demo section every single all hands to make a point of like hey show off what you worked on last week so there's just like a

just bubble to the surface bigger projects that are going on um so people do generally catch this stuff like it's been really unusual there's only been like a couple of times where we've sort of built the same thing twice but it's been so such a small problem it's just not been a huge deal basically or like a worst case maybe like and i think as again if you're

like a team lead or you're an exec team like you should also be keeping an eye out for this kind of stuff like a lot of the interaction i'll have with teams um is like oh just so you know like this other team is working on something kind of similar like maybe just go talk to them and figure out if maybe one or the other of you should build it but not both of you or if you want to power on it for a bit or whatever on the second on your second question or the second point i think you're making around like what if like one team learned something how do you spread um

This is something we're still trying to get better at. I think there's been two areas that we're discovering for this. One has been infrastructure. We have a platform team for infrastructure. And very recently and very topically, like AI stuff is its own beast in terms of how it gets built. And I would imagine pretty much every company in software, at least, is building with AI. And we've got kind of one, we now have kind of a platform AI team.

And they have much deeper expertise on how to build things with AI, what's kind of possible and what the infrastructure should look like, how to build it and so on. If any of the other teams want to build AI-based functionality, like, hey, I want to build natural language to a chart, a visualization, one of the AI people will move to the, will go to live in the product analytics team for a sprint, three sprints, whatever. And they will pair with one of that team and

So the other team is owning the functionality still, but they've been able to piggyback on the expertise of an AI-oriented engineer. The point being that when the AI person then goes back to their home base, maybe in a month or two months or two weeks, whatever it is, the team are left still able to run independently because there's not maybe a permanent need for an AI specialist in a product team. If you actually have an expert come in and do it with them,

If the course of like two weeks or four weeks, you might be able to save yourself six months of engineering work going in the wrong direction or whatever. So being quite willing in the platform teams to like send, if it is kind of a more a platform type thing, using people to like hop into another team temporarily can work quite well. So we will very frequently move, we'll move people around these teams to reflect the nature of the work that needs to happen. But we will aim to distribute the knowledge of a platform team out into these teams through this kind of missionary approach. That's what we're,

I don't think we've totally nailed this. Like this is kind of where we've gotten to after like a few years doing this. I still don't think it's perfect, but that kind of approach seems to be the right way. We do a couple other bits. Like we have a brown bag session once every two weeks for engineers. It's totally optional where an engineer will just talk about something they've learned. Like, oh, I've been working on scalability. Here's all the stuff I've learned. Yeah.

It's a very kind of free form. So those are the kind of two ways that we've approached this so far. After this short break, we'll be back with more of James and Al and they get into the nitty gritty of how you can implement this in your organisation. Don't go anywhere.

Leah, do you know who I think is awesome? Me. Well, yeah, of course. Yes, of course. But also my long-term hero and former guest, Joe Thea, who's the host of Hustle & Flowchart podcast, brought to you by the HubSpot Podcast Network. Of course. I remember when you booked Joe as a guest last year and you were so excited. Yeah, he's just an awesome guy. I've been listening to his podcast since about episode 100, long before we joined the network. And I tell you what, if you like systems...

mindset tweaks, reframes and strategies to actually enjoy the process of being in business. And this podcast is right up your street. Now it's true. Joe does love talking about building business systems, which isn't entirely my bag. But when you bear in mind that he loves talking about these systems so he can work less and live more, I'm there for it.

He also has loads of guests I know our listeners are going to love too. Yeah, like episode 644 with a guy called Robert Glazer, who's an author and an employment expert. He's advocating for a new way to manage the resignation process. He's got a book called Two Week Notice and explains why two weeks notice is the wrong way of doing things. And well, obviously, I'm not going to spoil the surprise. You need to go listen for yourself. Episode 644 with Robert Glazer. Listen to Hustle and Flowchart wherever you get your podcasts.

Welcome back. Let's get straight back into it. Well, so we've got here now, what I like about this is that you're sort of clearly outlining that you've got small teams, they have ownership, you have secondments between teams. Yeah. I think the question I will be having as a manager, I'm going to come on to managers in a second, as a manager or an owner of this company will be like, well, is there going to be some friction if someone is seconded from one team to another? Is that different for developers or engineers? I think this would be very easy to get.

wrong if you want to move people around frequently um because it and also when you're forming like we're scaling quite fast like i think this year we're um uh gonna go from i think about 80 people to 190 people something like that and i think the um so really really often like every week i would say a team is getting split in half uh to form two teams for example um and then each team has a team lead so you could you could argue it could be pretty contentious because like

oh, who's the boss of the new team? Like, how come it's not me, for example. And so,

uh we have just embraced my co-founder's dutch um and we've just embraced like full dutch directness on this stuff so i think traditionally if you're like moving people around or you're like splitting teams up or forming new teams i think the very conventional way to do this is you kind of like as an exec you've created the idea already you already know it's going to happen and then you basically do politics you convince every use one-on-ones to convince everyone this is a good idea then you make the change so there are no surprises uh but then you look back and you're like i've basically just spent like

seven hours making this change um and it's taking me a week and a half and it's creating effectively a culture of politics i would argue um like convincing people of an idea that i already know is going to happen so um the way we do this is in slack we will put a slightly over the top message with like a bunch of like warn warning bells and axe emojis and just be like

I'm proposing that we split this team in half and I think this person should be the new boss of the new team. And they should take this person, this person with them. This is a zero context, no warning. No, if anyone has any feedback or disagrees with this change, let me know. Otherwise, let's make this change today. And then we just make the change and like no one ever objects to it. It's been super, it feels much more honest and direct. And this is now happening so much. It's kind of no longer a big deal anymore. But yeah,

uh yeah the first time we did it it felt kind of brave but now i'm like wow this just means it takes like 10 minutes to make a team change um and we don't pay the other thing is we don't pay managers differently to um people doing individual work and we almost downplay i'd say we almost have a culture of making fun of management but like kind of um we really downplay the role of manager we try and centralize a lot of traditional management work so we don't kind of

um like a lot of the time actually one of the biggest challenges is not everyone fighting to be the manager it's people fighting to not be the manager um which is great from our perspective again the kind of people we like hiring as managers i mean going to this if you like is um people that kind of reluctant managers i often think are the best kind at least in engineering in small engineering oriented teams probably we're very direct totally transparent about these changes um and we make them kind of when we actually want to make them versus

trying to get buy-in we just don't try and get buy-in from the organization culturally we've just gone hey we're gonna make loads of changes we can spend loads of time convincing around they're a good idea or we can just ask for in the same way that i would trust a small team to ship whatever they want i'm asking the small teams to trust that when we make team changes we have thought about this quite hard um and you have like tell us if you think they're dumb um but almost invariably because there's quite a lot of philosophy around when we'll have small teams like hey if we've got two products in a team that should be two teams um or if the team's getting past six people that should be two teams

Because people are kind of bought in already to the Hamburg and the philosophy that we have. It's been really smooth to make these changes much quicker. And it just feels kind of funny compared to, it feels a little bit cult-like, I think, compared to like how a normal company would approach this stuff.

You mentioned two words there. You said team lead and you said manager. Are these the same people? Yeah, pretty much now they are. And to start off with, it wasn't really the case. But yeah, so the normal structure would be, say a team is four people. One of them is the team lead. That person is also made the line manager of the other three people in the team. So that's kind of one level of management.

We have an exec team that's tiny. So there are four people in the exec team at the moment. And the exec team, one of the execs is responsible for... Every small team will go up to one of the execs, basically. In practice, how that actually looks and feels is my co-founder and I are project-based. We try to have almost no direct reports at any time. And then we have two other execs who just make sure the company runs smoothly. One is go-to-market ops and finance oriented. The other one is she's engineering oriented.

oriented so she has like seven or eight teams reporting to charles has like a whole bunch of other teams reporting to him and go to market and then tim and i will hop into teams like for example um i've just spent like a couple of days with one of our small teams working on our all our ai stuff that we want to build through this year um because it's a lot changing um the week or two before i was i joined one of our other small teams to work on like a rebrand of our website um on the like an individual kind of level my co-founder is kind of similar and like he specializes more in new products um

And I tend to specialize more in things that are a little bit more design or brand oriented in general. So we've got a team of four people. Yeah. Um, you, and I got this right. You have decided that those four people are together and you have decided that person A is going to be the team lead. Is that the way it works? Uh, yes. Yeah. What happens when you join that team? Do you work for them, the team lead? Uh, it's pretty informal, if I'm honest. I think we, um,

Sometimes I'll say, hey, we have this AI team at the moment. I'll go, hey, Michael, I'm who runs the team lead. I'm proposing that I'm your boss for the next few weeks. And then I'll hand you back to Raquel probably at the end who manages the team so it's in a bit more of a steady state. So I will temporarily become the boss of the small team. I'm just going to probably turn up to a bunch of stand-ups or go to an off-site or something. I'll cherry-pick this team

uh is in a more existential mode where we're trying to figure out what the overall strategy is or something or we're building something unusual that doesn't fit with how we normally would work or it's something kind of a little bit different or it's a zero to one kind of problem um whereas once the team's in like a state where we have like thousands of customers and stuff um i'm just not as good at looking after it i've found um so yeah but we'll swap like i will swap who i'm managing quite frequently too again you're not supposed to swap managers all the time um

but we have had no uh we've just had no issues with it you end up with like a couple of you actually have quite close relationships with the team leads anyway um and because i think normally that's problematic because you have like oh one manager's pulling me in this direction the next manager's pulling me in a different direction um but i think the reality is like we're not that heavily influencing what actually gets worked on most of the time with these teams so i don't think the manager like kind of no one cares almost is how it feels um because i

we're not really influencing like in the short run i am like i'm spending like a week on this particular team to influence the direction quite heavily but then we'll just leave them alone for like it could be six months or a year or whatever where they're gonna like i still talk to them but like um i'm not going to be up in their grill around what they're working on so the management component of how important your manager feels i think is really reduced um we also don't do one-on-ones for example there's like lots of other stuff we've got removed um

too so yeah there's a couple of things here that look very different to what you're supposed to do did you say that the team lead gets paid the same as everyone else in the team yeah um sometimes less depending if they're like less experienced as an engineer for example suppose raquel and you're like okay cool raquel you're leading this team of four people and you're gonna go and do this cool thing i'd be like yeah but i feel like i'm getting more work

and i'm not getting any extra money is that is that does that happen yeah i think um so sometimes people will say no for that reason and i'm like great this is actually quite good like if someone um there's like multiple reasons why we will just force it to be this way one is that we want to be able to swap teams around a lot and so if it starts affecting people's pay making changes your org's not very flexible um and we are kind of like a hyper growth sort of company and thus we are changing our structure over and over again it's been like having like

in sales we took forever to give people um commission like we really really delayed having any kind of commission structure because we're like well so much is going to be in flux if each change we make can affect people will affect people's pay um we're not gonna be able to change easily or quickly and it's gonna be really hard so we're

pushing flexibility really matters um it's partly for that kind of reason um but yeah it does some people just want to do it they like they'll want to you know a lot of engineers will pick it up going hey i would like to see what it's like like we have loads of engineers for example who they might be curious about what's it like actually managing a couple other people and then what happens in six months is they tell you that they hate it and they want to swap back one of the ways to not get hired at postdoc is to say i want to manage loads of people for example um we'll hire people that

are just very passionate about building stuff in general and that's kind of what motivates them it's not really money it's not um kind of empire building um because i think this corresponds with the this correlates with engineers who will want to keep building even when stuff's harder because they just love the underlying work um and some of them are a little bit curious so i think it's almost like a

development point for some people we might wind up saying hey you're getting kind of effectively more senior like because you've been leading the team that's influencing this now um but it won't guarantee any kind of correlation kind of thing so um i think people often can end up as stronger individual engineers if they have managed a few people because they kind of get

they might have a slightly broader picture of the business for example so they have a slightly better understanding of what the company cares about which is kind of nuanced or I think people who've been managers are easier to that they require less work to manage I think often as well because they can empathize with what it's like when you have to deal with a bunch of people so yeah there's like some interesting stuff but yeah we absolutely will get pushback and we've had people refuse before to do this and we've also had managers swap with one of their direct reports and the manager has proposed it going hey I think Joe

Joe Bloggs, who reports to me, Mary.

should actually be my boss and I should report to them. I think both of us will be happier and then we'll just pay and then often we'll just end up making that change. And you just explained that the managers, they get out of the way. They're there to make things easier. But we've still got the problem of meetings and the problem of all these Slack messages or emails or whatever. Have you got a different way of coping with those? Yeah. So we have kind of a communication hierarchy that we've published into, I think it's our handbook as well, but it's basically like our preferred method of communication is a pull request as in like, here is the code.

Just for those people who aren't technically minded, a pull request is... Yeah, it's basically like if you build a new feature or you ship something,

uh the pull request is the like thing an engineer publishes with all the new code in it um so so if i was writing an email and you had a suggestions for it then a pull request would be you going hey i've just rewritten it do you want to add that to your yeah so it'd actually be more extreme so it'd be something like uh so yeah communication could be like do you think i should build this thing or whatever but we prefer that an engineer is just like i've built this thing um let's test um as opposed to like okay i'm gonna spend a month thinking about it it's like no i've just spent

a week building it in practice let's find out um because again i think there's like a lot of um i think there's this kind of one of the other learnings i think we've had is one of the things that's been quite different in our experience compared to what it looked like it would be on the internet when we were learning about how to do everything um as a startup was i think if you read a lot of like product management stuff online it's all kind of um thou shalt uh validate

your ideas up thine ideas i don't know you should evaluate your ideas up front before you waste time um but i don't think this is really i think that's like a cultural thing from really risk averse extremely large companies that might spend like 20 billion dollars on some new thing and they need to be ultra risk averse whereas with a startup like you're screwed by default like you're going to fail like you're on a dying path as soon as you start hiring people spending money um

And so you need to, like, you shouldn't be working in a risk averse way. You should be really embracing stuff. And I think the, when we've tried to validate stuff up front, like we've just had the, we've had clearer lessons still when we've just built something, put our energy into building it in a like way where we're happy to throw it away if it doesn't work and getting it in people's hands. And so, yeah,

So our preferred method of communication from an engineer is not to spend ages super validating a product, blah, blah, blah, blah. Just build something real, ship it. You'll get feedback from the team afterwards being like, hey, why did you build this? It seems weird or dumb. Most of the time it won't though. And they're like, cool, we can actually just learn clearly if it was dumb because we'll see if anyone used it or not. So we'd rather have some risk-taking over what gets built in an extremely low consensus environment is our preferred way of building stuff. Next up is then public communication. So

like after like actually don't bother communicating just do it underneath that is then public communication so um uh we would often use github issues um github issues are like for those who don't use github github's where code goes your code base lives um issues are where you can track like feature requests or bugs in your code or whatever um

We also use them to track like how the company, because we have a public handbook, the code for our handbook is also in GitHub. We use issues to track things like, oh, we are considering building a new team, for example. Or I might, we have a private repo that will include things. We have a private version of it where just internally I'll put an issue saying, I think we should think about fundraising in December, working backwards. This is the stuff I think the company should do.

does anyone want to add anything to this list of stuff for example so we're properly prepared um so kind of communication in public um like literally in public um is our second preferred form of communication and then like third is like okay slack public channel internally and then last of all is like slack dms private groups definitely email like no one uses email at all a postdoc is only for like customers um

uh or bottom of the list because they're like they're ephemeral like these kinds of things the knowledge disappears from them um and so there'll be like context in slack threads from like five years ago that will affect my thinking now that new employees won't see at all which is why like a handbook is a great thing to prioritize like this is a public channel essentially like if we put stuff into a handbook

we won't have to repeatedly have this discussion so for it to be a really tangible example um we had an employee who asked to go on a sabbatical and they'd been here a while like can i take a four month break or something um and so it's like okay we now need to figure out so i don't want to answer that question what i want to do is like okay what is our principle for how we handle sabbatical requests and let's think through the principle properly and then we'll publish that into our handbook and then we'll send the link to the person um in order that we don't have to think this through again um

so we're consistent as a company and we don't make a different decision next time. Um, or at least if we do, it's intentional rather than accidental. Um, and third, it's more clear. So like next time around, an employee will have already seen what our policy is for sabbaticals. And if we don't want to do them, they won't even, they'll know that we don't offer them already at the point before we even hire them kind of thing. Um, so, uh,

yeah, it's more leveraged if you're more transparent and more public with your communication, with your thought process, which ends up being that like there's just less management overhead with running the company in general. So...

what we've got here is egoless, almost permissionless because people just build something and go, is this any good? Um, I really like that. Let's talk a bit about the actual, the type of person for whom this would appeal. So in my head, when you're saying someone who just ship stuff, I'm thinking, and I don't know how to say name the French guy on Twitter with the crazy hair, Lou something. Um,

You'll know who he is. You'll see his... Peter Levels is a better example, I think. So, Peter Levels. So, he just basically sits down on Friday and goes, I'm going to do this. And then Saturday, somehow he's made a million dollars from it and nobody knows how. Obviously, a talented... Probably not the best developer in the world, but certainly someone who's very good at pushing something. However...

Imagine he was in a team. Would you want him in a team? Like, this is nothing against Peter. Sorry if you're listening, but there's nothing against Peter. But would you want someone who's that kind of like, sorry, I'm doing it? Yeah, I would say yes. The handbook acts as principles. So it's not like people can decide what to build, but we'll give guidance over how to prioritize. So for example, we have loads of products and an engineer could easily just be, so, okay, I own product analytics. It has tens of thousands of companies using it.

what should i build next kind of thing and like we'll give guidance over like okay here's how to answer that question for yourself and we'll work on that guidance and we'll iterate and improve it over time so we'll say you know like hey we'll create a list of stuff we think we should build at the start of each quarter for each team um you could go there you could listen to what customers are asking for what if like a big enterprise is pushing for some feature that we don't have like do you listen um and change your roadmap around so if he would like be willing to look at the guidance and roughly follow it great um we do say this is just guidance like

you can ignore it if you think it's stupid in a particular situation. It's not going to capture the nuance of everything that's happening. I think if an engineer then decides, like, I'm going to build, like, I don't know, like, a flying simulator or something instead of the next, like, okay, if that repeatedly is happening and their ideas are all failing, they are too rogue to work here effectively. So we have a level, it's not just, like, build, it's build whatever you want, but we'll give you principles over, like, this is how, this is kind of a framework for how to think. Like, we're trying to

we're not just totally hands-off let engineers kind of chaotically ship random stuff it's sort of like okay we're trying to help our engineers be instead of providing a product manager who tells the engineers what to build we're trying to help our engineers be good product managers um i we think a good product manager is more chaotic than um what the industry norm is where it's like really validated up front and stuff but

um yeah i think if peter levels is like over here on the like craziness scale and like a product manager at google is over here we're probably like kind of about there i would say is what we want so he's probably slightly too far over or not institutionalizable enough um but like the kind of person that um would be very happy working at google is probably gonna be really unhappy working at postdoc because they won't have any they'll just like there's no boundaries or spoon feeding or resources available to them that there's not enough

um support provided i think is how it could feel so we are looking for like we have lots of x um yc founders or generally generally x founders or like i'm a disgruntled cto of a struggling european startup that just wants to write code but i have to deal with all these idiots all day long um like these are the kind of people that will be really successful in a higher autonomy environment but yeah the hiring is very important with this structure um

And people who are a little bit broader skill set-wise are a bit more flexible. I think we'll also tend to do better. For example, if you're like, I'm an entirely backend-oriented engineer, I think there's a phenomenon of like,

If you have a hammer, everything looks like a nail. And if you're a very backend-oriented engineer, you're going to probably have a propensity to do lots of backend engineering and make everything really scalable. Whereas in reality, you might be much better off just building a new feature from scratch that has 10 users to validate, like, oh, we're getting requests for this new product or something. So we like hiring slightly frontend-oriented engineers because we think they're a slightly stronger product.

um and we give them principles to operate i would be worried about giving so much freedom to people who are essentially entrepreneurial with their ideas that you're just going to be set you people are just going to go oh this is great i'll go and do this myself and leave yeah i think um that does happen like it's one of the main reasons that more people need postdocs start a company than to join another company um by quite a way i would say um

the normal reason though why people won't do that often what ends up happening is uh we hire ex-founders who have tried to build something from scratch already and then they're like oh this is less fun than i thought it would be because literally no one cares um whereas opposed to we have lots of distribution we have like um hundreds of thousands of users and so kind of anything we build and our product principles kind of work like it kind of means anything you build if you're roughly following our guidance just will get usage and so it's like if your actual joy in

as a person is like building stuff getting into users hands and the craft of building things we're going to be a better environment than building a startup from scratch where no matter how much you care about the craft of what you're working on if no one cares at all about the idea in the first place no one will even use the like beautiful utopian um software you've been working on and so i think there's a lot of kind of um

It's almost the other way around. We tend to hire people who are like, it is so horrible trying to start a startup from scratch when no one cares. That is so cool that I can have the freedom of building a startup, but with actual users. And I can get into this feedback loop really quickly. It makes me feel like I'm having a much more impact. So we will sometimes lose people who get overexcited about some new idea and they just can't help themselves. But it's not been as bad as you would think, I think. And then because the company is growing so quick, we...

like our stock price and stuff is like rocketing all this and we do secondaries so employees can sell shares on a regular basis it's something we've been doing um so that okay yeah you don't own the whole pie you own a slice of it but the pie is growing extremely quickly um uh so we're able to yeah it's not perfect but um there are enough other benefits that it just feels uh irrational when you actually question the motivation of the people who work at what they really care about and usually and like what we're interviewing for and looking for is like

It's cool you've been a startup founder before, but the thing we actually like about it is you like building stuff with a lot of freedom and you're good at thinking like a product person would and also as an engineer. And if your real passion is just building stuff and getting in people's hands and improving it, we can probably be a better spot for that. I am aware we are running a little bit low on time. So can you just talk us through...

recruitment yeah like do you do do things differently yeah so there's a few things i think one having a handbook and being quite unusual and opinionated and clear um means that we don't have to do outbound also being all remote um we don't do outbound recruitment at all um even though we're scaling quickly like we have to source lots of candidates um so uh the number one thing is like the other big advantage of putting into onto the internet how you work is

um if it's actually interesting and different and thought through and designed for first principles i think um it will really resonate with some people will hate it and some people will love it which means that the people who love it will just show up and and so our recruitment's been uh something we're incredibly grateful about is like we basically just put job ads live and we'll get thousands of applicants for every job uh which means that we can scale really quick um if we want to headcount wise um that's one effect that's been really important um

I think the second is we do a couple of bits you'd expect in the interview process. Like we do like a screening with a recruiter. We have a technical interview that's not like a whiteboarding exercise. It is a chat. And then there'll be a culture kind of interview from me or my co-founder. Like the two of us will both interview every person that we hire. And because we've just heard anecdotally, this is, I can still see that we turn away candidates that other people would, I can see us changing the direction of what happens in the decision still. Yeah.

But the bit that's unusual is we do a super day. So we will basically pay you to do some actual work. We used to pay you to do literal work with us, as in like, hey, here's something we intended on building as a company. Do you want to try and build it with us? And then we'll just pay for a week of your time or whatever. We've been able to get it down to a day, but we basically pay people to do a day of work. Well, if you're an engineer, it'll be something like build something from scratch. If you're a recruiter, it might be like, hey, here's a job spec that's gone up.

here are the candidates that are coming in um do some interviewing with us or whatever it might be so we'll get people to as close as we can to real work um and it's been that's been incredibly helpful like there have been so many candidates where one thing i've learned is you never get good surprises on a day like this basically it's like you can get candidates where everyone's like four out of four this person's brilliant it's the next yeah it's like einstein or something for this role um

and then on the super day you're like oh this is really underwhelming um but like thank god we didn't just hire them and learn this later kind of thing um and so the super day is the highest rejection rate of the i think one in four people get through the super day but already you've got through like a one in two multiple like one in two one in four three kind of steps um let's see plays a big test but it's been really valuable to us um

I think it's meant that we've avoided a ton of mistakes. And the thing we're prioritizing for an engineer in the super day is how much useful stuff can you build basically in a day? Um, it depends on what the other roles are, what the priority is. But, um, yeah, I would very heavily advocate for some kind of paid day of work. That's as close as you can make it to what real life would look like. Um,

there's remarkable difference in what candidates say and what they do um when you watch them or at least we're not good enough at the early stages to avoid having this bit at the end of the process and it costs money like it might be 500 bucks it might be a thousand bucks um that we end up paying um but it's just way more it's just so incredibly worth it um to not because we'd spend so many times more than that if we mishired for example

trying to get my head around this in your company you're like okay i don't mind being wrong i don't need to be the leader yet in your private life you're reading about building empires so how do we reconcile this what what is there a point in early james's life that we need to know about to understand why you are the way you are today that's a very interesting question uh hmm

I am a very ambitious person and like that's often like I think out of if you compare me and my co-founder Tim he is uh better he's clearer more direct I'd say he's a stronger communicator um and kind of as a result he's actually he's better at the execution side by quite a way um I'm better at just pushing up the level ambition in the company um but I don't care if it comes from it doesn't have to come from me as in like I want our engineers to ship work they're extremely proud of um

uh like our website is a good example of this we've got our website is really cool uh and we get quite a lot of recognition on the internet for it um and it is really pleasing to see like oh that team are able to build stuff that like people on twitter will regularly talk about like they'll talk about like how we've done our terms and conditions page because it's done in a really unusual way for example so um yeah i really like seeing these teams bite off it's really cool to me seeing a

go fight it's like a david versus goliath kind of thing i think of um seeing a small group of people go you're like we have a data warehouse product the biggest competitor in data warehouse land is snowflake it's a 55 billion dollar company and we basically had two guys like i'd start with i think i'm getting this right it was like eric a guy called eric and so i'm called james um and it was just funny watching eric and james go fight snowflake like two engineers versus like this big conglomerate thing um because it worked and it was so it was very fun uh and i think like i think

I think it's probably for me. I think maybe it's professionally, actually. Like, I've always worked for companies that have struggled. I've never worked for Facebook or Google or Netflix or somewhere sexy. I've kind of always worked for, like, random little startups that have always had a hard time. And so I think I just want to back the underdog constantly. And it's the same with, like, our ICP, like,

where like the ideal customer profile that we have, like one of the core things I'm interested in is like what happens if we just never drop caring about individual users at all costs? Like we'll just always do the right thing. Like we've been cutting pricing over time once other people increase it.

um we don't do outbound sales at all as a business for example um and we're speeding up we're going faster and faster and faster without any need to do it and so um yeah i think it's maybe like this underdog thing because i've always felt professionally like i'm uh never that well uh i just don't quite have the like sparkling standard tech resume of like you know stanford or um

one of these bigger companies or something so yeah i think maybe that might actually be why i find this compelling now i think about it a bit um but uh yeah i think i think my dad was actually similar like he was also like it didn't really get he didn't uh he wound up being really successful he actually screwed up and lost all his money uh later on um but he

very randomly stumbled into like London in the 80s and everything kind of took off and stuff so yeah I think it might be that kind of fact but like I like backing underdogs and that's what these like little teams feel like to me when they're competing with companies with like 200 engineers building the same thing that we've got like two guys working on for example

Well, that was really interesting, Al, from James. What an unconventional approach to building teams. And I like data and science and ordering the workplace. I kind of like this idea of introducing chaos once in a while. I like how James said having a little bit of chaos in an appropriate dose can lead to a greater outcome than the grandiose vision you have in your head as a founder. Wow, that needs to go on a poster or something. I think

I think, yeah, I think we can think that structure and control is essential in businesses, particularly as they grow. But really, it's about structure that serves the business, that serves the people and provides that autonomy and empowerment. It's not just structure for structure's sake. So I think James is proving that beyond any doubt. And also that, you know,

incredible potential it gives to a business in terms of innovation. Totally agree. Totally agree. I love chaos as it's exciting, but if you've got a company the size of PostHog, you need to get that right balance, I think, as well. And what probably goes against all of the rules in the workplace Bible is how James just decides to make a change, then implements it the same day with a message on Slack.

if you've heard some of our previous episodes on change management, you probably think this is crazy and it might well be, but it works at post-hoc and it might work at your company too. Just be very careful with it and go back and listen to exactly how James does those changes because he doesn't come in and say, this is what's happening. Well, he does, but he does it in a very specific way. So just be careful. Yeah, it's very nuanced, isn't it? Because too much change can be really stressful and actually quite

quite exhausting. But yeah, these small autonomous teams I think are really interesting with that clear ownership. They will consistently outperform larger groups because as we've heard, you can be more agile, you can make change quicker, people can take control in their roles and push people forward, push things forward without all the bureaucracy. But I think what makes James' approach

really quite cool is how he's kind of grounding everything in engineering velocity and getting products into user terms quickly rather than just that that endless planning it's all about balance but it's interesting to see how thinking unconventionally can actually be really quite effective talking unconventional if you want to find out more about james and his work then go to the unconventional post hoc website at posthog.com i never asked him why it's called post hoc

I need to look that up. It's basically an internal wiki that you can read publicly. It kind of feels a bit weird, as you heard me say to James. It feels like I'm reading his diary or reading his internal stuff that I shouldn't really be able to read. And definitely go and follow James on Twitter. He's at James406. I don't know what 406 is. I wonder if it's just like he was the 406th James to join Twitter. But definitely go and follow it because he's known, obviously, for his transparency, but

I love him for his sarcasm. So yeah, very cool. Go and follow James. Bit of admin for you if you've enjoyed this episode. Maybe you want to click on that subscribe button. Maybe you want to double click on it and go a bit deeper.

That's from Tuesday. You know, you know. Yeah, no, subscribe. That'd be really nice wherever you get your podcast. If you fancy getting in touch, maybe have a question for Tuesday's surgery or even a guest suggestion, then you'll find us on LinkedIn. That's where most of our audience chatters between shows or you can email us directly at hello at truthliesandwork.com. Exactly. Make sure you tag us on anything you say on LinkedIn and we'll share your post with our lovely listeners and also you'll get Leanne replying. You won't get me because I don't go on LinkedIn. Exactly.

Do you know, I actually had a listener connect with me who said, I hear Al's grumpy, but you tend to be here. So I thought I'd connect. That's exactly right. Made me lol. Anyway, we will see you on Tuesday for our regular episode with our weekly news roundup, our spicy hot take and our world famous workplace surgery where Al puts your questions to me. Have a fabulous weekend. Bye. Bye bye. Bye bye.