Episode 189 · 17 April 2025 · 55:09
How to build a $10M company without meetings or managers, with James Hawkins, Co-CEO at PostHog
Featuring James Hawkins
How to build a $10M company without meetings or managers, with James Hawkins, Co-CEO at PostHog
0:000:00
Tip: click any timestamp below to jump there and keep playing.
Enjoying the show? Subscribe for free
Chapters & timestamps
Click any timestamp to jump the player to that moment.
Who is James Hawkins and intro to PostHog
The type of person PostHog is for
Radical transparency — why PostHog's handbook is public
Small teams over big bureaucracy
Why small teams win on engineering velocity
Duplication, ownership, and 'not owning' as a feature
Team leads vs managers — and why leads aren't paid more
The communication hierarchy and pull requests
interview#communication#pull-requests#management#decision-making
Egoless, permissionless building
When freedom means people leave to start companies
interview#freedom#entrepreneurship#retention#company-culture
Recruitment — how PostHog hires at scale
interview#recruitment#hiring#scaling#talent
Leanne and Al unpack the approach
Show notes
How to Build a $10M Company Without Meetings or Managers — with James Hawkins
Guest: James Hawkins — co-founder and co-CEO of PostHog, a dev tools company generating $10M+ ARR with no managers, no meetings, and no micromanagement.
What would work feel like if you ripped out middle managers, weekly check-ins, and change committees entirely?
James joins Al and Leanne to explain how PostHog runs like a collection of tiny startups — autonomous 2–6 person teams that ship fast, decide for themselves, and publish almost everything in public. He shares why engineers lead without getting paid more, why "just ship it" beats endless validation, and how a dose of organised chaos can unlock innovation if you hire the right people.
Top 3 Takeaways
Small teams beat big bureaucracy. PostHog structures itself into autonomous 2–6 person, multidisciplinary teams. No more than 6 people, full ownership, and no permission-seeking — that's how you keep startup speed at scale.
Leadership isn't a promotion. Team leads at PostHog don't get paid more. They're often less experienced (and sometimes paid less) than their teammates. The role is about coordination, not status — and people are free to say no to it.
Radical transparency builds trust. From salaries to sabbatical policies, PostHog runs almost everything in public. Their internal handbook is online for the world to read — because transparency isn't just a values statement, it's a hiring and trust-building tool.
More From James Hawkins
- PostHog website: posthog.com
- James on X (Twitter): x.com/james406
- PostHog's Newsletter: newsletter.posthog.com
Connect With Us
Get in touch, book a call, or find Al and Leanne on LinkedIn — all in one place: truthliesandwork.com/connect
Mental health support: findahelpline.com — UK: Samaritans 116 123 · Mind 0300 123 3393 — US: 988 — Australia: Lifeline 13 11 14
Truth, Lies & Work is part of the HubSpot Podcast Network.
Full transcript
Expand full transcript
James HawkinsI'm James Hawkins. I'm the co-CEO alongside Tim, my co-founder of PostHog. 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. So 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 Like 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 6 people. It is multidisciplinary. So the point is that teams can do work entirely as an island. We want to make sure that the team's well-rounded. Like, it needs to be able to ship the entire product by itself. The biggest challenge is, 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 2 or 3 people working on something rather than 100 people kind of like probably doing the same thing.
Al ElliottLet's talk a bit about the actual, the type of person for whom this would appeal.
James HawkinsWe 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—
Leanne ElliottHello and welcome to Truth, Lies and Work, the award-winning podcast where behavioural science meets workplace culture. We are brought to you by Hi, the HubSpot Podcast Network, the audio destination for business professionals. My name is Leanne. I'm a chartered occupational psychologist.
Al ElliottMy name is Al. I'm a business owner.
Leanne ElliottAnd we are here to help you build amazing workplace cultures.
Al ElliottToday we are joined by James Hawkins, the co-founder and co-CEO of a company called PostHog. They're revolutionizing— revolutionizing— easy for me to say— 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, PostHog operates as a collection of tiny autonomous startups, and they're scaling faster than most traditional organizations could ever dream of.
Leanne ElliottWith 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. PostHog 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.
Al ElliottAfter 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. 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.
Leanne ElliottAfter 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 ElliottThe dirty little secret is that most businesses think they know their customers. They have the data, the records, the history, but it's scattered across 3 teams and 4 systems. And in our case, it's about 216,000 spreadsheets, which means nobody can actually use it.
Leanne ElliottWhat you should be doing is using HubSpot, because why? HubSpot connects it all— every interaction, every support ticket, every conversation— into one platform. Every team can work from. So when sales talks to a customer, marketing already knows the full story. And when you know more, you grow more.
James HawkinsNice.
Al ElliottCheck out hopspot.com, the agentic customer platform for growing businesses.
Leanne ElliottLet's go and join Al and James and hear how PostHog does everything just a little bit differently.
James HawkinsI'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 in terms of what we're famous for, probably just being like incredibly intelligent, strong, and good looking. But apart from that, mainly for being very transparent online and sarcastic. So you can like 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.
Al ElliottLooking 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?
James HawkinsUh, in the early days, it was about trust. We, when we were just 2 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 thought, well, transparency is kind of the foundation of trust. So if we're much more transparent than a normal startup would be that puts like 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 mark your homework. If your internal wiki or Notion or whatever isn't exposed to the world, it's going to be kind of badly written and not that well thought out most of the time, or it's kind of very secondary to most companies, I think. 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.
Al ElliottSo let's talk about the tweet that 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 teams, but just give us the context. What is a small team to you? And what does it have to have and not have?
James HawkinsSure. So a small team is first of all, no more than about 6 people. Um, it is multidisciplinary. So the point is that teams can do work entirely as an island. Um, we want as few dependencies as possible between them. Um, so for example, at PostHog today, we have a team for each product that we offer. Um, and they're like 2 to 6 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. And that lack of dependency and need for alignment or coordination or meetings is the part that's been particularly important to us. So what it actually looks like in practice, to give you a bit more flavor maybe, is it would often just be, for us, it could be like 4 or 5 just engineers, but we're trying to make sure that we have 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 like all backend engineers or all front engineers or all designers or all PMs. Um, some of the teams will wind up with someone who's less technical in the team too. Um, but yeah, the primary thing is like, this needs, this team needs to be able to build products without outside interference.
Al ElliottThat seems to me from the outside, it seems like it's all about small team startups being like scrappy. Is that where the idea came from? What made you decide, yep, we're going to do small teams here?
James HawkinsI'd say there are 2 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 structured the company, we were asking ourselves about product strategy. Like what, well, 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. 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. And kind of like what AWS is to infrastructure, we're kind of like that to 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.
Leanne ElliottYeah.
James HawkinsAnd 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? And it just felt obvious that startups will ship the most per person, where there's like 1 or 2 people will build an entire thing.
midroll (Phil Agnew, Nudge)Yeah.
James HawkinsAnd then Y Combinator has like, I think in our batch, there's probably like 250 startups. So probably in total about 500 people. that will ship, um, probably like 800 or 900 products. Because a lot of people will build one product, it will fail, they'll build something else. It'd 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 2 weeks or so you have office hours with, uh, one of the YC partners. And the YC partner is kind of like your You know, spiritual guru kind of, uh, 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 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. Sometimes it's just encouragement, like, hey, this sounds great, just keep going. Other times it's like, hmm, sounds like no one cares about your thing and you're screwed. 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. And so we wanted to create, we felt PostHog like a series of small startups, essentially each with their own metrics and tracking and all this stuff. we think would feel very similar to work in. So we'll probably be more productive and there's like no committees, no meetings or whatever. And then the other example we had was, 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 like lots of startups. And I was like, oh, I can also see a really good example there. If I look at like You know, we're a developer product. AWS is like an $80 billion run rate business, and it's hundreds of small teams. So we could see an example at extreme scale in one company pulling this off, which was kind of enough for us. So that was kind of the reasoning and then the inspiration for it.
Al ElliottSo we have the advantages of small teams give you the advantage of engineering velocity, engineering velocity, I think you said. Um, 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 it right.
James HawkinsYeah, absolutely. Um, but it can also mean not having ownership can be a good thing if your team are smarter than you. Um, so I would also argue that, um, I'm 100% certain our company would not be as 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 2 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. I think it's actually given us a— 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. 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. I could go on for ages about this. Like, for example, uh, like if you read about— yeah, I was reading a book on how do empires rise and fall.
Al ElliottAs in Roman Empire?
James HawkinsUh, this is 15th century. Um, but it was sort of how come all these like tiny little European countries dominate the entire world, even though they're so small? Like, they don't have as many resources and stuff. And the book's kind of making the argument that there's chaos in Europe where people, you know, there's always like warring going on and it leads to someone inventing the Like gunpowder, and then suddenly you have this massive advantage. And now one small country can have an empire that spans the world kind of thing. So 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. Because I'm not like Steve Jobs or something.
Al ElliottYou've already said Apple wouldn't, that your way wouldn't work necessarily at Apple when they have to be pixel perfect, when they're just, they're obsessed by design and stuff. But let's talk about something like, let's say Buffer. So you, you are something like Buffer where you've got one product. Would you, if you were in charge of that, do you, would you still break out into small teams? Even you would?
James HawkinsYeah, I would split the product conceptually into different like use cases, for example, or I still think you can get much greater productivity if you're able to pull 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. But the way I'd approach that if I were Buffer would be like, okay, 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 maybe like the editing experience. I have another team that work on like 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 semi-separately.
Al ElliottYeah.
James HawkinsBecause 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 2 or 3 people working on something rather than 100 people kind of like probably doing the same thing. I think there's just this effect in engineering where it's like the first few people working on an idea, could go so much further. Like, it's so ridiculously disproportionately far compared to like the 50th, the 51st person, the 100th person you add to a team that, because of accountability, basically, 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 so that you can have better ownership everywhere from your engineering team.
Al ElliottYou 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 6 teams, each between 2 and 6 people in it, and they're all working on different, either different contexts of one product or different products. I'd be worried about 2 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 teams?
James HawkinsI think there's actually 2 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 a bird might poo on it, for example. Where it's like, well, just wipe it off and keep going. Overall, you have a Porsche. And it feels a little bit like that to me. Okay, cool. Let's take 10 steps forward and then one to the side and one backwards by accident. But net, we're probably up 9 steps compared to where we would've been had we still been doing the pre-meeting for the pre-meeting for the meeting to plan the thing. 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 There's probably a little bit too much to keep on top of. I think the second, but there are a couple of other places. So for example, in our all hands, because we prioritize like velocity and shipping basically, and because it's the primary thing we're good at and winning on, 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 couple of little bits like that that can 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 in the 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.
Al ElliottYeah.
James HawkinsAnd figure out if maybe one or the other of you should build it, but not both of you, or if you want to pair 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 learns something, how do you spread? Um, uh, this is something we're still trying to get better at. I think there's been 2 areas that we're discovering for this. One has been infrastructure. We have a platform team for infrastructure. Um, and very recently and very topically, like AI stuff is its own beast in terms of how it gets built. And like, you know, 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 a 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 infra 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 like natural language to a chart of a data visualization, one of the AI people will move to the, will go to like live in the product analytics team for a sprint, 3 sprints, whatever. And they will pair with one of that team so that the other team is owning the functionality still, but they've been able to like 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 like a month or 2 months or 2 weeks, whatever it is, The team are left still able to run kind of independently because there's not maybe like a permanent need for like an AI specialist in a product team. If you actually have an expert come in and do it with them over the course of like 2 weeks or 4 weeks, you might be able to save yourself 6 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 of 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. So that's what we've— 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 2 weeks for our engineers. It's totally optional, where an engineer will just talk about something they've learned. Like, I've been working on scalability. Here's all the stuff I've learned. Um, uh, this is very kind of freeform. So those are the kind of 2 ways that we've approached this so far.
Leanne ElliottAfter 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 organization. Don't go anywhere. Did you know that the UK's number one management podcast— that's us, by the way— and the UK's number one marketing podcast are both on We actually have a lot in common.
Al ElliottWe both use behavioral science to help people do better at work.
Leanne ElliottAnd we both had to wrangle Rory Sutherland on an episode.
midroll (Phil Agnew, Nudge)And 2 out of 3 of us are devilishly good looking.
Al ElliottAnd you're not going to say which. Fel, host of Nudge, UK's number 1 marketing podcast. It's brought to you— we need to do this in 3s—
Leanne Elliottthe HubSpot Podcast Network, the audio destination for business professionals.
midroll (Phil Agnew, Nudge)Seamless.
Al ElliottSeamless. Tell us about your latest episode, Phil.
midroll (Phil Agnew, Nudge)Uh, we've just done an episode on fake fandom and how New York indie bands are paying agencies to create fake TikTok videos about how much they like their work. And we talk about the behavioral science behind fandom and how that encourages people to enjoy the music and all of that good stuff and do some big things about how this affects the world of politics, business, and brands as well.
Al ElliottIt is.
Leanne ElliottIt's such, it's such a good show. Of course, you'll hear all the stuff you wanna hear about How to grow your business by using behavioural science in your marketing. But there's also just some really interesting episodes that'll be right up your street. Personally, I enjoyed Can Balsamic Vinegar Make Beer Taste Better?
midroll (Phil Agnew, Nudge)It can.
Leanne ElliottAnd Are We All Just Status-Seeking Monkeys?
midroll (Phil Agnew, Nudge)I am.
Al ElliottGo and listen to Nudge wherever you get your podcasts.
Leanne ElliottBut come back.
Al ElliottYeah, come back.
midroll (Phil Agnew, Nudge)Definitely come back because Nudge isn't as good as this. So come back.
Al ElliottI'll cut that out.
James HawkinsKeep that in.
Leanne ElliottWelcome back. Let's get straight back into it.
Al ElliottWell, 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, uh, you have secondments between teams.
James HawkinsYeah.
Al ElliottUm, I think the question I would 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, we'd be like, well, is there going to be some friction if someone is seconded from one team to another? Is Does that, is that different for developers or engineers?
James HawkinsI 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, going to 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 to form 2 teams, for example. And then each team has a team lead. So 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 we have just embraced, my co-founder's Dutch, 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— you use one-on-ones to convince everyone this is a good idea. Then you make the change. So there are no surprises. Uh, and, but then you look back and you're like, I've basically just spent like 7 hours making this change. Um, and it's taken 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 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. Um, and they should take this person, this person with them. Um, this is a zero context, no warning note. Um, 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 no one ever objects to it. It's been super, it just 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, 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. And we don't pay, the other thing is we don't pay managers differently to people doing individual work. work and we almost downplay, I would say we almost have a culture of making fun of management, but like kind of, we really downplay the role of manager and we try and centralize a lot of traditional management work. So we don't kind of, 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, which is great from our perspective. Again, the kind of people we like hiring as managers, we can go into this if you like, is people that kind of reluctant managers, I often think are the best kind, at least in engineering, in small engineering-oriented teams, probably with very direct. totally transparent about these changes. 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 going to make loads of changes. We can spend loads of time convincing everyone 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 team to trust that when we make team changes, we have thought about this quite hard. And you have, like, tell us if you think they're dumb. But almost invariably, because there's quite a lot of philosophy around when we'll have small teams, like, hey, if we've got 2 products in a team, that should be 2 teams. Or if the team's getting past 6 people, that should be 2 teams. Because people are kind of bought in already to the handbook 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.
Al ElliottYou've mentioned 2 words there. You said team lead and you said manager. Are these the same people?
James HawkinsYeah, 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 4 people. One of them is the team lead. That person is also made the line manager of the other 3 people in the team. So that's kind of one level of management. We have an exec team that's tiny. So there are 4 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. Um, in practice, how that actually looks and feels is my co-founder and I are project-based. Like, we'll, um, we try to have almost no direct reports at any time. And then we have 2 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. So she has like 7 or 8 teams reporting to her. Charles has a whole bunch of other teams reporting to him and go-to-market, and then Tim and I will hop into teams. For example, I've just spent a couple of days with one of our small teams working on all our AI stuff that we want to build through this year, because there's a lot changing. The week or two before, I joined one of our other small teams to work on a rebrand of our website on an individual kind of level. And my co-founder's kind of similar, and he specializes more in new products. And I tend to specialize more in things that are a little bit more design or brand oriented in general.
Al ElliottSo we've got a team of 4 people.
James HawkinsYep.
Al ElliottUm, you did, am I got this right? You have decided that those 4 people are together and you have decided that person A is going to be the team lead. Is that the right way?
James HawkinsUh, yes.
midroll (Phil Agnew, Nudge)Yeah.
Al ElliottWhat happens when you join that team? Do you work for then the team lead?
James HawkinsUh, 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 be like, hey, Michael, 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 standups or go to an offsite or something. And I'll cherry-pick this team. 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 or 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. Whereas once the team's in like a state where we have like thousands of customers and stuff, I'm just not as good at looking after it, I've found. 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. But we have had no, 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. 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. 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 because 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 6 months or a year or whatever, where they're gonna, like, I'll still talk to them, but like, I'm not gonna 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. We also don't do one-on-ones, for example. There's like lots of other stuff we've removed. Um, to say, yeah, there's a couple of things here that look very different to what you're supposed to do.
Al ElliottDid you say that the team lead gets paid the same as everyone else in the team?
James HawkinsYeah. Um, sometimes less, depending if they're, if they're like less experienced as an engineer, for example.
Al ElliottSo if I was Raquel and you were like, okay, cool, Raquel, you're leading this team of 4 people and you're going to 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. Does that happen?
James HawkinsYeah, I think so. Sometimes people will say no for that reason. And I'm like, great, this is actually quite good. Like if someone, 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. And we are kind of like a hypergrowth 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 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, we're not going to be able to change easily or quickly and it's going to be really hard. So we're pushing flexibility really matters. It's partly for that kind of reason. But yeah, it does. Some people will just want to do it though. 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 6 months is they tell you that they hate it and they want to swap back. One of the ways to not get hired at PostHog is to say, I want to manage loads of people, for example. 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 Kind of empire building, because I think this corresponds with the— oh, this correlates with engineers who will want to keep building even when stuff's harder because they just love the underlying work. 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, 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 the, they might have a slightly broader picture of the business, for example, 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, 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. Um, so yeah, there's like some interesting stuff, but yeah, we absolutely will get pushback and we've had people refuse before, um, to do this. 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. I think both of us would be happier. And then we'll just pay, and then often we'll just end up making that change.
Al ElliottYou 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?
James HawkinsYeah. So we have kind of a communication hierarchy that we've published into, I think it's in 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.
Al ElliottJust for those people who aren't technically minded, a pull request is?
James HawkinsYeah, it's basically like, if you build a new feature or you ship something, the pull request is the like thing an engineer publishes with all the new code in it.
Al ElliottUm, so, so if I was writing an email and you had 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 email?
James HawkinsYeah. 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 going to spend a month thinking about it. It's like, no, I've just spent a week building it in practice. Let's find out. Because again, I think there's like a lot of, 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 as a startup was, I think if you read a lot of like product management stuff online, it's all kind of thou shalt Validate your ideas, thine ideas. I don't know. You should validate your ideas upfront before you waste time. 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 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 or spending money. 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 when we've tried to validate stuff upfront, like, we've just had clearer lessons still when we've just built something, put our energy into building it in a way where we're happy to throw it away if it doesn't work and getting it into people's hands. And so, yeah, so our preferred method of communication from an engineer is not to spend ages like super validating your product, blah, 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, let's just, 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. Yeah. Next up is then public communication. So after, like, actually don't bother communicating, just do it. Underneath that is then public communication. So we would often use GitHub issues. GitHub issues are like, for those who don't use GitHub, GitHub's where code goes, your codebase lives. Issues are where you can track feature requests or bugs in your code or whatever. We also use them to track 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? So kind of communication in public, like literally in public, is our second. preferred form of communication. And then third is like, okay, a Slack public channel internally. And then last of all is Slack DMs, private groups, definitely email. No one uses email at all at PostHog. It's only for customers. Oh, bottom of the list, because they're ephemeral. These kinds of things, the knowledge disappears from them. And so there'll be context in Slack threads. from 5 years ago that will affect my thinking now that new employees won't see at all, which is why a handbook is a great thing to prioritize. This is a public channel. Essentially, if we put stuff into our handbook, we won't have to repeatedly have this discussion. So, to give you a really tangible example, we had an employee who asked to go on a sabbatical, and they'd been here a while. They're like, can I take a 4-month break or something? And so, it's like, okay, we now need to figure out— so, I don't want to answer that question.
midroll (Phil Agnew, Nudge)Yeah.
James HawkinsWhat I want to do is, 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 in order that we don't have to think this through again. So we're consistent as a company, and we don't make a different decision next time, or at least if we do, it's intentional rather than accidental. And third, it's more clear. So 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, there's kind of, there's more leverage 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.
Al ElliottSo 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 ships stuff, I'm thinking, and I don't know how to say name, the French guy on Twitter with the crazy hair, Lou something. Uh, you'll, 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 thinks, sits down on Friday and goes, I'm gonna do this.
midroll (Phil Agnew, Nudge)Yeah.
Al ElliottAnd then Saturday, somehow he's made $1 million from it and nobody knows how.
James HawkinsYeah.
Al ElliottUm, obviously a talented, probably not, 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.
James HawkinsYeah.
Al ElliottWould 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, sod it, I'm doing it?
James HawkinsYeah, I would say yes. Um, 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, um, 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. They're 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. 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 and change your roadmap around? So if he would like be willing to look at the guidance and roughly follow it, great. 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, okay, I'm going to build like Uh, I 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. Um, so we have a level of, 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. We think a good product manager is more chaotic than what the industry norm is, where it's really validated upfront and stuff. But yeah, I think if Peter Levels is over here on the craziness scale, and a product manager at Google is over here, we're probably kind of about there, I would say, is what we want. So he's probably slightly too far over or not institutionalizable enough. But like the kind of person that would be very happy working at Google is probably going to be really unhappy working at PostHog because they won't have any, they'll just like, there's no boundaries or spoonfeeding or resources available to them that there's not enough support provided, I think is how it could feel. So we are looking for like, we have lots of ex-YC founders or generally ex-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. 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. And people who are a little bit broader skillset-wise, who are a bit more flexible, I think will 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, you know, 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 like slightly frontend-oriented engineers because we think they're slightly stronger at product. And we give them principles to operate.
Al ElliottI 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, people are just going to go, Oh, that's great. I'll go and do this myself then and leave.
James HawkinsYeah, I think that does happen. Like it's one of the main reasons that more people leave PostHog to start a company than to join another company. By quite a way, I would say. The normal reason though, why people won't do that, often what ends up happening is 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. Whereas at PostHog, we have lots of distribution. We have like 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 software you've been working on. And so I think there's a lot of kind of, it's almost the other way around where we tend to hire people who 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 much more of an 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 like, because the company's growing so quick, we, like our stock price and stuff is like rocketing all this and we do secondary so employees can sell shares on a regular basis. It's something we've been doing. So that, okay, yeah, you don't own the whole pie, you own a slice of it, but the pie is growing extremely quickly. So we're able to, yeah, it's not perfect, but there are enough other benefits that it just feels 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. Um, and if your real passion is just building stuff and getting people's hands and improving it, like we can, it would probably be a better spot for that.
Al ElliottI am aware we are running a little bit on, um, low on time. So can you just talk us through recruitment? Like, do you do things differently?
James HawkinsYeah. So there's a few things. I think one, having a handbook and being quite unusual and opinionated and clear means that we don't have to do outbound, also being all remote. We don't do outbound recruitment at all, even though we're scaling quickly. Like we have to source lots of candidates. So the number one thing is like the other big advantage of Putting onto the internet how you work is, if it's actually interesting and different and thought through and designed from first principles, I think 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 so our recruitment's been—
midroll (Phil Agnew, Nudge)Yeah.
James HawkinsSomething we're incredibly grateful about is like, we basically just put job ads live and we'll get thousands of applicants for every job, which means that We can scale really quick if we want to headcount-wise. So that's one effect that's been really important. I think the second is we do a couple of bits you'd expect in the interview process. We do 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. 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 were, I can see us changing the direction of what happens in the decision still. Um, but the bit that's unusual is we do a super day. So we will basically pay you to do some actual work. Oh no, 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 you for a week of your time or whatever. We've been able to get that 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, let's, here's a job spec that's gone up. Here are the candidates that are coming in, do some interviewing with us or whatever it might be. So we'll get people to do as close as we can to real work. And it's been, that's been incredibly helpful. Like there have been so many candidates where One of the things 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, 4 out of 4, this person's brilliant. It's the next, you know, it's like Einstein or something for this role. And then on the Superday, you're like, oh, this is like really underwhelming. But like, thank God we didn't just hire them and learn this later kind of thing. And so the Superday is the highest rejection rate of the, I think 1 in 4 people get through the Superday, but already you've got through like a 1 in 2, multiple, like 1 in 2, 1 in 3 kind of steps. The Superday is a big test, but it's been really valuable to us. I think it's meant that we've avoided a ton of mistakes. And the thing we're prioritizing for an engineer in the Superday is how much useful stuff can you build basically in a day? It depends on what the other roles are, what the priority is. But 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. There's remarkable difference between what candidates say and what they do. Um, when you watch them work, 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, it might be $1,000, 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 mis-hired, for example.
Al ElliottTrying 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 are we reconciling this? 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?
James HawkinsThat's a really interesting question. 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 better. He's clearer, more direct. I'd say he's a stronger communicator. And kind of as a result, he's actually, he's better at the execution side by quite a way. I'm better at just pushing up the level of ambition in the company. 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. Like, our website is a good example of this. We've got this, our website is really cool. And we get quite a lot of recognition on the internet for it. 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 little group of people go fight. It's like a David versus Goliath kind of thing, I think, of, um, seeing a small group of people go, you know, like we have a data warehouse product. The biggest competitor in data warehouse land is Snowflake. It's a $55 billion company. And we basically had 2 guys like, uh, self with, I think I'm getting this right. It was like a guy called Eric and someone called James. And it was just funny watching Eric and James go fight Snowflake, like 2 engineers versus like this big conglomerate thing. But it worked and it was very fun. And 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. 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 whilst other people increase it. We don't do outbound sales at all as a business, for example. And we're speeding up, we're getting faster and faster and faster without any need to do it. And so— Yeah, I think it's maybe like this underdog thing, because I've always felt professionally like I'm never that well. I just don't quite have the sparkling standard tech resume of Stanford or 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.
midroll (Phil Agnew, Nudge)But yeah.
James HawkinsYeah, I think my dad was actually similar. Like he was also like, it didn't really get, he didn't, he wound up being really successful. He actually screwed up and lost all his money later on. 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 effect, 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 2 guys working on, for example.
Leanne ElliottWell, that was really interesting, Al, from James. What an unconventional approach to building teams. Um, and I, I, I like data and science and order in 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. Um, wow, that needs to go on a poster or something. Um, I think, I think, yeah, I think we can think that structure and control is essential.
James HawkinsYeah.
Leanne Elliottin businesses, particularly as they grow. But really, it's, it's, it's about structure that serves the business, that serves the people, and provides that autonomy and empowerment. Um, it's not just structure for structure's sake. So I think James is proving that beyond any doubt, and also the, you know, incredible potential it gives to a business in terms of innovation.
Al ElliottTotally agree. Totally agree. I, 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 probably go— 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 PostHog, 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.
Leanne ElliottYeah, it's very nuanced, isn't it? Because too much change can be really stressful and actually 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 with push things forward without all the bureaucracy. Um, but I think what makes James's approach really quite cool is how he's kind of grounding everything in engineering velocity and getting products into users' hands 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.
Al ElliottTalking of unconventional, if you want to find out more about James and his work, then go to the Unconventional PostHog website. at posthog.com. I never asked him why it's called PostHog. I need to look that up. Uh, 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, feels like I'm reading his diary or feeling— reading his internal stuff that I shouldn't really be able to read. And definitely go and follow James on Twitter. He's @James406. I don't know what 406 is. I wonder if there's just like— he was the 406th James to join Twitter. Uh, but definitely go and follow because he's known obviously for his transparency, but I love him for his sarcasm.
Leanne ElliottSo yeah, very cool. Go and follow, follow James. Um, bit of admin for you. If you've enjoyed this episode, maybe you wanna, you wanna click on that subscribe button. Maybe you wanna double-click on it, go a bit deeper.
Al ElliottThat's from, that's from Tuesday.
Leanne ElliottYou know, you know. Um, yeah, no, subscribe. That'd be really nice wherever you get your podcasts. If you fancy getting in touch, maybe have a question for Tuesday Surgery, Um, 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@truthliesandwork.com.
Al ElliottExactly. 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.
Leanne ElliottDo you know, I actually had a listener connect with me who said, I heard, I hear Al's grumpy, but you tend to be here, so I thought I'd connect.
Al ElliottThat's exactly right.
James HawkinsMade me LOL.
Leanne ElliottUm, 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.
Al ElliottHave a fabulous weekend. Bye-bye.