Getting Real, small teams and technical debt

Are we starting? Let's start. I think that's it. Because, man, our viewers complained about why it's not in 4K. 4K, man, our viewers who prefer not to give their name, not to give their name, our however-many viewers, we can start whenever you're ready, by the way. Okay, I'm just checking something quickly. Is it in the draft, or the copy sheets or whatever? Right. I don't get it. Anyway. I'd pulled out some questions we should ask ourselves. We'll ask ourselves that later. Okay.

Right, that's how it'll be anyway. I couldn't find it. Was it something about taking the lessons from the book and applying them to ourselves, or was it something else? Right, let's not be too open about that one, man. Okay. Alright, let's start then. Let's start. Hi everyone. Hello everyone, from a new episode of our podcast. Hi Barış. How are you? I'm good. Don't even ask. Honestly good. Still hustling. How was your weekend? Man, good, actually. I was going to say, ever since you told me about Ghost of Yōtei, all I want to do is play it, but I haven't had the chance.

Go play it at home, boss. I've got things to do, let me finish those, if I finish early. Honestly, on days you plan for that, things never actually finish early, something always comes up. Anyway, I think I'm going to set aside next weekend entirely for it, shut everything else out. Really great recommendation, by the way, genuinely. I'm not saying that just because I recommended it, but I loved the game. If anyone hasn't played it, go buy it and play it. This week's guest, well, it's actually one of the books written by the duo we constantly bring up, DHH and Jason.

Getting Real. Your camera dropped again, man. Yeah, I'm trying to fix it, but it's probably buffering. No, I think it just fully cut out. Should we carry on? Give me a second. It seems to have really dropped. Hey, you've got those toy models behind you, right, should we grab a shot of those instead? Shouldn't there be something that pops up automatically when the feed drops? No, there's nothing right now, right? Completely blank. Nothing, yeah. I think the connection dropped on your end. I heard an Apple notification sound though.

Yeah. I wonder if your phone's up to date or not. No, it's actually up to date, man. Like, my WiFi just dropped, so it's probably because of that, but I don't know why the WiFi dropped. Right, it does need to be on the same WiFi. Yeah. Give it one more second. If it doesn't work I'll switch to the other thing. Alright, it's gone. I'll unfortunately just carry on like this. What, the regular camera? Yeah, that camera. Should we make a big deal out of it? No, there's nothing we can do about it.

Audio's fine. If the audio's fine, we're not in trouble, man. Audio matters. Right, right. Anyway, we won't cut this, let people see what we're actually going through. Let them see the two, three minutes of what we're dealing with. What were we saying? Right, this week's guest, so to speak, is one of the books written by the duo we've been talking about for ages, Jason and DHH, called Getting Real. They'd periodically put out books about the concept of adapting their own frameworks to the company. There's also It Doesn't Have to Be Crazy at Work.

One of them is a book they wrote out of building Basecamp itself, one of them is Rework, and Getting Real is one of them too. Overall, for anyone who doesn't know the company, it's worth underlining that they're a fairly, let's say, innovative and anarchist kind of setup. So going in, since Getting Real is entirely something they produced themselves, a framework built out of their own experiences, what we say here isn't necessarily gospel truth, but we can start by saying we take a lot of inspiration from it.

Yeah. I think that's something worth understanding properly. We keep asking ourselves this too, there's no claim here that this is the one right way to do things. It's just that these guys genuinely built, I don't know, thirty-four companies, or let's say thirty-four projects under one parent company. And along the way they say, we made these mistakes, we got these things right. That's really the position they're coming from. It's simply impossible to take all of it and apply it wholesale to your own company.

But I think there are a lot of points in it that really opened our minds. It's basically like a to-do list, there are like ninety-five mini-topics or so. Chapters. Right. There are chapters. Right. And each one just briefly touches on something and moves on, touches on something and moves on, that kind of structure. It's almost like they fired off ninety tweets, ninety short little pieces, almost like aphorisms. But honestly, they're such precisely targeted little things that...

Actually, let me say this, maybe we'll come back to it later, but the chapters do circle around certain core concepts. To give an example, if I go through the ones I personally liked or that caught my attention, a lot of them are action-oriented, there are loads of points about that. There must be eighty, ninety points just on cutting and trimming anything that won't turn into action. They clearly put a lot of weight on that side of things. Especially on the software side, for example, we can mention one of them like this.

The ship analogy is a really good one, changed my mind on this. So it talks about being a load-bearing weight. The more people you hire into the company, the more people are forced to communicate with each other hierarchically and bureaucratically, and that creates a load, and it compares that load to a ship. Like, a small rowing boat, a canoe, you can turn left and right very easily, but a huge transatlantic ship is very hard to turn. It's the same idea here. The bigger the load a company actually carries, the harder it is to steer.

That's why they always try to stay small. That was one of those points, for example. Right, there's a lot on that: keep the code simple, keep the headcount low. There's one point in particular I really liked, and it goes against the usual startup-world mindset, something like, a problem that hasn't happened isn't a problem yet. You might remember it. Basically, don't waste time worrying about a problem that hasn't happened just in case it might. They say this a lot about scaling, for example.

Right, on scaling for example, it says, why are you worrying about scaling when you don't even have millions of users yet. Think about that once you actually have millions of users. Right, and honestly that makes sense to me, because I think it applies to us quite a bit too. That was actually one of the questions I raised for ourselves: what are the things we're over-engineering right now? I made a note of that. Because you inevitably start thinking ahead, like, what happens if this happens?

What happens if this starts? Sometimes you genuinely need to internalise the idea of fixing the caravan while it's already on the road. As the team grows, you get more and more of this, this could be a problem down the line, so let's solve it now. But honestly, we're still at too early a stage to be worrying about that. I think the whole startup world gets caught up in scaling, will this scale, how will it scale. You end up building these elaborate systems as if five hundred thousand new companies are going to show up and start using it tomorrow.

Of course there was a note there too, one I really liked. There are quotes from various people in there too. It basically says, plan all you want, once you actually reach a million users you're almost certainly going to have to redo the whole system anyway. Because there'll inevitably be so many things you didn't know about and missed. So don't bother, just let it flow, you'll figure it out when you get there. I think that's very, very true. And honestly, at some point what we've been doing lines up with that quite closely, there's a lot of overlap with us.

We've got a lot of overlapping bits. We started out exactly like that too, doing whatever came to mind. Let's add this here too, let's throw that in there too. But there's something really interesting, it says, don't respond to a customer request instantly, say no, definitely say no. Whatever the customer asks for, say no. Then look at this, it says: does it repeat? Meaning, do other people share that same request? Does anyone else share that same frustration, or that same feature request?

If it repeats, if it's a recurring request, put it on your roadmap, it says. And there's a part where it's kind of ambiguous whether you should focus on annoying bugs or prioritise these customer requests. Actually there's a part where I was genuinely torn. What do you think? I'm curious, because they talk about this, like, say no to everything, ignore the customer's requests a bit and stay focused on the core.

So it says, basically, any decision you leave up to the customer is friction you shouldn't be leaving behind. For example, it says, on our site, in the reports section, you can see the first twenty-five. It shows up in the table twenty-five at a time. We didn't add an option to view fifty or a hundred, because then the customer would have to choose. Or, say, ranking, it can be sorted newest to oldest, but you can't sort oldest to newest, for instance. There's a part where they say we deliberately don't leave that decision to the customer. And that ties into the next point.

Minimise every nice-to-have feature in your product and put all your energy into the must-haves. I'm a bit torn on that one. Adding twenty-five, fifty, a hundred as options doesn't seem unreasonable to me either, on some level. What it's really saying there is that a settings or preferences section inside a web app is actually a developer's escape hatch. It's an easy way out, basically, instead of deciding on the default settings themselves, they offload it to the user as an option, which creates this whole settings, this whole configuration area, and...

the more of that there is, the heavier the load on that ship really gets. I've noticed this myself, for example. In more lightweight apps, config is like three, four toggles, connect, done. But go check the settings on something big, like Salesforce, or check Apollo's settings, man, there are like fifty-five settings. And there are settings inside settings already. Whole categories of settings and everything. Right. I think that genuinely ties into this point too, man.

I think that's a great point too. It says, if your IT team becomes a team that just responds to customer problems, and it uses this analogy: the chef who cooks the food also doing the waiting tables. If your developers, your IT team, can directly handle these requests coming in from customers, it says that builds industry knowledge too. Weren't we literally talking about exactly this a few months back? There's a lot of overlap here. It says if the IT team also has that industry knowledge, they can respond to customer needs and know exactly what to avoid or not avoid in those configurations.

Man. Yeah. That's a really good point, I genuinely think we should sit down with the product team at some point and think through what's nice-to-have versus must-have inside Hardal itself. Because, for example, our settings section used to be pretty simple. Now that I think about it, it's not that simple anymore. Actually, wait, there isn't even a settings section anymore. There's this new config section that's got a ton of stuff crammed into it.

That part just doesn't get used anymore. It's basically dead weight now. Right, that whole section needs a proper hose-down. Yeah, like scrubbing it out with a toilet brush. What are you actually using, what aren't you using, man? Honestly, this is something we've genuinely lived through, we'll just build whatever comes to mind, put it in the product, and figure people will use it somehow, but it never actually worked that way. We always bring up that SQL example, right, let's add a SQL generator or a SQL field so people can build their own reports right there, except people are already frustrated by the time they log in, and the last thing they want to do is deal with SQL on top of it.

They just want to click a button and download it right away. I think that's really important. One of the points I think we can genuinely take a lesson from, there's a line, I made a note of it: half, not half-assed. It basically says, do a job halfway if you have to, but don't make it sloppy or full of holes. You don't have to do something completely, but at the very least, if you're doing it halfway, don't let that half be full of holes.

Even that half, do it like an expert, it says. I think that's one of our own points too, when it comes to positioning Hardal and not turning the product into a mess, because when we look at some competitors, we look at a lot of websites and ask each other, what exactly does this even do? I genuinely think it's best not to be like that, and these guys say the same thing. Yeah. I think there are some things we've had well set up from the very start. Like, for example, I'm happy that we don't have a ton of internal meetings.

We don't lose much time in meetings. I was actually thinking about this. Back when we were just four people, every meeting genuinely had all four of us in it. I used to wonder, man, what happens once we're fifteen people? Now we genuinely are fifteen people, and meetings still just happen with two, three people and move on. There are no pointless meetings with ten people, eight people sitting in. That's honestly one of the things I'm quite happy about, about how we work. Maybe we should actually go into this, what they talk about is roughly that company culture where meetings are meaningless, where nothing useful ever comes out of them, but if I tie it to that strategy, let me explain how closely it actually maps onto us.

It says, to build a product I need three people: a developer, a designer, and a jack-of-all-trades. A wildcard. Someone who runs around doing everything. Handles growth, handles product, handles whatever else. I think that concept works incredibly well, and it's really valuable for internal team communication. Our product team, if you've noticed, is so tightly interwoven for exactly that reason, it's the product team, but we don't have a finance team, or a separate HR team or anything like that.

When you're structured like that, unfortunately you do end up needing some meetings, or you can get communication gaps. But anyway, that whole concept of keeping the team small is, I think, one of the number one things we'll write down. Growing isn't automatically a good thing, achieving big things with small teams is really what they're getting at underneath all of it. And I do get the human side of it too. I understand why teams grow. Because I think there's a perception at play there. There's this perception that if I just hire one more person, things will get easier, or we'll move faster.

But then it turns out that's not what happens, you don't actually speed up. The load just genuinely increases. You feel it. I think it's the same for the product too. Every feature comes back to you as a load later. It comes back as technical debt, of course, and for everything you didn't finish properly, you have to go do it eventually anyway, with a promise to pay off that debt. So, say, if something isn't at a hundred per cent, if you shipped it at eighty per cent, it says you absolutely have to go pay off that remaining twenty per cent as debt at some point.

So, does this whole thing, meetings, internal communication, staying small, does it have to apply to every department or every company? I don't think so. This is somewhat startup-culture-specific, somewhat specific to a company that builds a web app, so it maps very closely onto our own strategy and we can draw a lot of parallels, but for people who have to do physical, hands-on work, of course, of course. Say, for instance, you've got a startup doing land surveying, and you genuinely have to go do field analysis.

You need people physically going out there. I don't think this framework maps well onto that kind of business, but for companies like us that build a web app, it's an amazing resource. So, what do you think about this, though? I don't remember exactly when it came out, but generally it touches a lot on product and the development process. Now, with AI, a lot of these processes have gotten easier, but at the same time things have also gotten a bit sloppy.

Do you think everything they talk about still holds up? Does it still carry the same validity, or do some things need a slightly different approach now on the development and iteration side? I think this book's about ten years old, by the way. Maybe more. Yeah. Yeah. In fact, they were the first to point out things like, say, being constantly distracted by Slack or other communication tools, attention getting fragmented, or being in the office and someone going, hey Barış, got a second?

Got two minutes to go over this with you, that kind of thing, not having anyone say that or need to say that to you. These guys really did spend a lot of time thinking hard about exactly these topics, and they're topics we really enjoy too. But with AI now in the picture, I think these frameworks need a version two. Maybe we're the ones who put it out. Why not, honestly. I actually see us that way to some extent. I see startups in our generation as the Gen Z of this whole space.

So they're a bit more, let's say, boomer about it, they think Slack notifications are distracting. And we think so too, honestly, but maybe for a younger generation it's not that distracting at all. It might actually help them focus on work instead. But we could keep that same underlying structure and refresh it, modernise it further, I think. You mentioned AI, that's a great example. I noticed something the other day, man. We used to say, DHH, how on earth does this guy write code and also do a podcast.

He builds and develops the product, runs five companies, races in Le Mans, does whatever else. I checked out his GitHub the other day, man. They've actually added Claude into their GitHub workflow now, the same Claude he used to throw shade at. So Claude is now pushing commits into their GitHub projects. I looked at the top contributors, Claude's sitting in second or third place on that GitHub project. So they're clearly starting to bring it in gradually, I think, and 37signals even released a skill, in the same framework, which means they must have trained the AI accordingly.

So I think that side of it genuinely needs to change too, along with all this. Yeah. Yeah. I'm a bit torn there too, honestly. Because there are certain things, like, how do you build a feature, I've got an idea, jump straight into action. Taking action is actually really easy now. Going from an idea to a prototype, which used to take certain steps and a certain amount of time, is now incredibly fast. That speed really needs to be calibrated properly.

It genuinely feels like this part could use a fresh look. Or, like that thing you mentioned a moment ago, Slack is getting to a point where tools are starting to run directly inside Slack itself. We keep talking about this too, right, where's analytics headed, what's going to happen. Once tools are running inside Slack, it's become a real question whether it even makes sense to pull yourself out of Slack anymore. And there's a point in the book about that too, it says...

Don't carry those negative office habits over into remote, it says, like, hey, got two minutes? Right. But now there's a whole remote-working culture that didn't exist before. And what's that look like? In an office you can't shout across the room to open a task in Linear for you, but now you can basically do that in Slack. While you're typing, you hand the floor to an agent mid-conversation, or tag an agent, for example. Man, that's a genuinely brand-new thing. User behaviour, definitely, there was even talk recently about AI companies starting to build their own keyboards, that kind of thing.

There's just one button on the keyboard. You're actually recording your voice, dictating it. So much of what we type these days is dictated that you almost don't need a keyboard anymore. And because people started dictating things out loud in cafes, someone actually built this acoustic device thing, man, it seals off the sound around your mouth. Kind of like those Dune stillsuit things, that kind of character design, sealing it off like that, and they've run a hose-like cable underneath it, man.

Are you serious? I've never seen anything like that, man. Incredible, honestly, whether it's an AI-generated thing or an actual prototype, I don't know, but conceptually, logically, this is what it's promising: you can now dictate silently in a cafe. It's trying to make that happen. Genuinely interesting habits developing, like, soon everyone's going to be walking around hooked up to something like this, cutting off the acoustics and doing whatever else. We're basically becoming people who operate computers through dictation now. I think this could actually form the backbone of this whole updated framework.

It's not just about speed. Actually, like you said, there's a lot in the book about this too. Something they insist on again and again: if you're going to sketch something out, start with just HTML and CSS first. Design the layout. Solve it from the core outward first. What's the word they use there? Epicentric, or something? There's a phrase for it. Really nice phrase. Basically, start from the centre and work your way outward, so you do the details later. It's really similar to that thing we always say, don't get hung up on the colour of the door handle. Let's build the building first, that concept.

As a concept, it's great, but I think there's a point where it needs updating. We'll see, maybe we'll be the ones to update it, who knows. Yeah, and by the way I think, on the other hand, this nice-to-have part is actually even more critical now than it used to be. It's become so much easier to drown a product in features. Of course, that's exactly why it matters so much, genuinely, I'd say every product team, every app-building team out there, should periodically sit down and ask, why do people actually use this product, and clean up everything around that core.

There's usually this question people ask, what would you like to see in the product? We actually want to ask the opposite. If you had to remove one thing from the product today, what would it be? Which feature could disappear and it wouldn't matter? I think that's a genuinely critical question. Even more important at this point in time, honestly. We could even combine that with, if we genuinely figure out what to remove, that would shape the integration a bit. Because the example for this is a great one too.

For example, people genuinely don't use dashboards anymore, they're communicating through MCPs woven together across different apps. People don't even log into a dashboard to check something anymore. Exactly. They've connected an MCP, and they just ask, what were sales like over the last five days? Or, generate me a chart about this. So, are you going to access this through an SDK, or through Claude? I think, since we're so much more interconnected now, even concepts like this mean we could genuinely modernise this book.

Let's actually put this on the agenda. Honestly, I think it'd be great. Right. Call it Getting More Real. Getting More Real. Getting Real, but we've squeezed 'more' into the middle of it like that. We've crossed out Jason's name and written our own in there instead. They definitely won't mind, right? They definitely won't. By the way, people can find this book in every format. It's fully available on the website as documentation, but there's also a normal printed copy. Enes has a physical copy of it too, by the way.

He was kind enough to get it signed for me. We made a whole physical thing out of it. Genuinely a great moment. I actually made a note of one last line from the book, man, and I want to mention it. This is roughly how I'd translate it. It says: a happy generalist versus a miserable expert. What a pairing, right? A happy generalist beats a miserable person. Beats a miserable expert, it says. So the versatility inside, hmm, we even had an episode about this with Rıza.

You joined us for that one too, you'll remember. We were genuinely talking about this exact thing there, being a generalist and so on. We were saying that specialising in one job, that whole enthusiast angle, doesn't really matter as much anymore, being a generalist matters more than being a specialist. Man, I really loved this line. Basically, build your strategy so that a happy generalist who's willing to run at anything beats a high-ego specialist who's constantly causing friction and taking jabs at people.

A million per cent agree, man. Let me wrap up the topic like this then. When you're deep in the middle of something, you sometimes overdo it. You take what you're doing very seriously, which isn't a bad thing in itself. But sometimes you genuinely need to remember why you're doing it, the purpose, where the whole thing came from, and not lose sight of things like actually being happy and making the people around you happy too. Thankfully we do keep thinking about this constantly, and honestly, that makes me happy too.

That's exactly our happiness too, really. Genuinely, make sure that person is happy and set up their environment, their playground, in a way that that employee, through creative thinking, actually produces better work than the specialist would. That's basically what it's predicting, logically. So I think it's really, really good, and there are genuinely great areas here for us to learn from. Let me check if there's a topic we skipped, a chapter we missed, is there anything you think we haven't touched on?

There's stuff like, for example, they argue interfaces shouldn't use placeholder copy like lorem ipsum, that kind of thing. I think there's a lot more, we could talk for another half hour and get through the second half, spending about a minute per point or so, but I think we're at a good stopping point, maybe we do the second one today. Sure. If you want, we could just carry straight on as Part 2 from here. Another twenty minutes and we'd have two episodes out of it. We'd just go through the remaining general points. How many of those are left, by the way?

About ten or so. I think ten works, man. Sure. Sure. Alright, short ad break and then we'll continue with our second episode. Don't forget to watch Part 2. And don't subscribe to the channel, by the way. Right? I think we said something like that last week. Let's not do that one. Didn't we just ask for comments? Something like that. If they want to leave a comment, sure, but that's not required either. They can like it, but they shouldn't turn on notifications or anything. Since we're literally talking about SDKs here, so people's attention doesn't get fragmented.

Let them connect an MCP to Slack instead, man. Let the news come to them through Slack. Let them ask for a transcript at the start of every episode. Alright then, see you around. Bye for now.