The dead-simple framework to estimate and plan anything within a startup with Anders Thue Pedersen from TimeBlock
Summary
Overwhelmed by constant communication, unsure how to keep people accountable, and how to plan todos even just for the coming week let alone several months? Anders Thue Pedersen shares with us his very simple TimeBlock methodology that teams use to plan their work, keep themselves accountable and avoid constant coordination.
Episode
Victor [00:02]
Welcome to Product Stories where we explore how founders build successful software products. This is a podcast about product management, development, remote work, and everything else non-technical as well as technical founders need to know to launch and scale software products. Today’s guest is Anders Theu Pederson, partner in Danish consultancy Abakion and co-founder of startup called Milt. Welcome to the show.
Anders [00:30]
Thank you.
Victor [00:32]
Anders has over his time in IT and software development, he’s come up with a very simple methodology. Well, in theory, very simple, at least the concept is very simple. But we’ll definitely dive into that methodology to estimate and plan software development work. Anders, why don’t you give us a quick background of yourself and how you’ve even found yourself in the position that you needed to just come up with a better framework of managing software development?
Anders [01:08]
Sure. So I’ve been self-employed for 20 plus years, have had consultancies in different sizes, I merged my latest consultancy in Abakion to become part of that, and one of the issues, as I’ve always had, has been when we got larger projects is estimating and tracking progress. But also, when hiring people being able to differ if they were missing technical skills, or they were missing personal skills. Because of technical skills, you can easily do something about personal skills as more hard to work on. So I’ve struggled with Bose for many years, trying to grow my business, and in the end, I ended up going on a Christmas holiday thinking I might as — I had like five or seven employees back then. I ended up thinking I might as well just close down my shop because I had a project that was running aground and I gave up on the entire managing people idea. So that’s my initial, that’s where it started. So it’s born out of desperation, of actually getting things to go right instead of getting things to go wrong.
Victor [02:51]
And so you were in this place, it was Christmas, you had more negative than positive thoughts about your business. You didn’t like managing projects? What changed? What did you find or maybe even read or how did you get to a new framework?
Anders [03:15]
So I’ve always been testing a lot of stuff, and I’ve always been reading a lot of books, and I’ve started attending MicroConf, where we also met many years ago at a conference for soul founded entrepreneurs, and Robin Mike in the podcast startups to the rest of us they talk about in one episode, it’s just a mentioned, but they talk about how it’s you should always be able to break down a task into half-day chunks. I mean, no matter how large or how small, you should always be able to say, the first half of the day, I’ll do this and the other half of the day, I’ll do that.
So that was one thing I’ve heard recently, and giving a lot of thought about that concept of breaking things down because how long does it take? Oh, it takes a week but what are you going to do in that week, and people had no idea what they actually were going to do. The other thing I’ve read was a Paul Graham post. I think it’s called Maker time and Manager time or make a manager scheduled perhaps, which is the difference between being a manager where it’s driven by the Outlook calendar or whatever calendar you’re using you blog in half-hour or an hour at a time and you have a meeting and it’s an hour and you have a meeting that lasts an hour. No matter what you’re doing, basically, and then you have makers, people who actually create stuff, and that can be software developers, it could be writers, it could be painters, it could be all people who are doing creative stuff, actually It doesn’t have to be software developers, I’ve trained other people in the methodology.
And they need flow, they need deep work, they need this concept of forgetting time and space, and being in that sweet spot where you just push yourself enough to forget about all the troubles in your life, but not so much that you are struggling to get progress, and it’s a really sweet spot to locate. But when you’re there, you can really perform and the thing about flow is it has a lead in and lead out. Mikhail MIhai has written a book about it, it’s not the easiest read of all, but it has a lead in, it has a lead out, and if you get interrupted in flow, there’s a lot of studies on the last one, you lose around 25 minutes of productivity, and then I’ve read a lot about transparency and vulnerability and how to get people to that you need those things to have innovation, and all the things came together during that Christmas holiday where I were thinking about what should my next move be? And I decided that I’d made some small, simple rules, and if you didn’t follow them, you would get fired. Well I’m kind of black and white that way. So I was like, either this work, I’m going to fire everybody. Right? And, and I tried it out.
So January 5, the first Monday of the year after New Year’s Eve, and all that. I gathered my team and said, we’re going to try something new, and the new thing is that you’re going to estimate everything you do in these half days’ chumps, we didn’t call them time blocks back them, we call them, whatever, and then you’re going to end I told them, you’re going to do that now. So sit down for half an hour and plan your week. One block, when you meet in on the morning, one block after lunch, and the same for the rest of the week. 10 blocks in total, and then we’re going to sit down and talk about all 10 bucks. What are you going to do? What are you playing for this week? And then next Monday, we are going to do a retrospective on that. So next week, we’re going to say, of those 10 blocks.
What did you get done? Oh, cool, and what did you not get done? Oh, shit. Sorry. Oh, whoops, and then we’ll ask a few questions. Why didn’t you get it done? Because this and that. Okay, so what have you learned? And that’s a much harder question. Because it’s easy to say, Oh, I didn’t do it because bla, bla, bla, and I asked a coworker. So what have you learned? And he said, “Ah, it was because blah, blah, blah”, and I said, “Yeah, but what did you learn?” And the fifth time I’ve asked him, he stopped, and he said, “Oh”, you know, then he started learning. “Oh, I learned that we need to coordinate before we blah, blah, blah”, and I said, “cool”, and then I asked a third question.
So what will you do differently this week? What will you actually change in your behavior to make sure you’re going to accomplish your goals, because the most important thing for makers are to get 9 out of 10 blocks accomplish every week. So they can be a hero, they know they have a job next week, they know that the boss is happy for the progress, and as a manager, I don’t care how much you get done. Basically, of course, I do in a broader sense, but basically, I need to be able to trust you. So it’s more important that if I had to rank them, it’s more important for me to know that what you promise me you will get done, then how much you get done.
Victor [09:15]
And the interesting part here is, of course, that there’s sort of similar concept, but not quite, which now, everybody knows and everybody’s talking about and nobody’s implementing correctly, and back then it wasn’t even that popular yet. But I’m obviously talking about Scrum and the Sprints and estimating and learning from what was the last Sprint establishing once velocity as you call it, which uses the concept of points instead of time blocks to give some meaningful way of estimating but what that doesn’t, is put focus on this flow aspect. Like one giving somebody enough, like half day block to really do something meaningful, and I guess were the differences as well is that in Scrum, you also say that one task shouldn’t take longer than a few hours. So the benefit is okay, I have to break down things into smaller chunks, and that helps me realize what I might have missed in estimating things. But it’s not enough of a guideline, so that people actually get clarity on this. But I think if people get to use in these half day chunks, of which are there’s only 10 in a week, they might get a better sense of their own time. Is that it?
Anders [10:50]
Well, there is multitude of different aspects of “why”. I think this works so well, when you implement it, and one of the things I realized just when you told me about this, now is that when you have these points, I’ve never thought about it this way. But if you have the points, you also have some people who can do more points than others, and let it start becoming a competition, Am I good enough? I’m not as good as developers — Victor Oh, shit, I got to do more points, and then it becomes competition, and I become focused on myself and you become my enemy, and that’s why I talk about, I don’t care how much you get done, it’s more important that you want, if you’re feeling psychologically safe, you’re going to do a better job than if you feel that you’re not as good as your peers.
So it’s moving away from measuring people against each other, to measuring them against themselves, and the reason I thought of this is because on the other end, you know, if if you ask me, as a consultancy you, you have to do billable hours, you have to email an invoice to someone. And, you know, time registration has also always been a huge struggle for people, and I just realized the other day that I think the reason why people hate time registration, or a lot of people hate it, not everybody is because they basically don’t feel they have as much well us, you know, the next guy, because he has more points.
So when they write the time legislation, they don’t feel to give the same value to the world as the peers, and that’s why time registration and planning and all these things becomes hard because it instead of being you know, you’re doing good, you start measuring yourself against other people, and I honestly don’t care, it’s a one on one thing, what you should get in salary and what the star programmer should get. That’s nothing for the group to discuss. So the Monday meeting has a huge upside in building trust, and you have to remember that if we don’t build trust in a team, when the shit hits the fan, everything beeps up. So you have to build trust. While that’s no problem. I have to. I know you don’t have kids yet. But I have a kid, and one of the things about parenting is you need to spend time when there’s not a problem. So when they end up in trouble, you have a relationship that’s strong enough that they come tell you, and it’s the same with the team, if you don’t have a strong relationship with your team, and have built that every week, when a project goes haywire. Everybody starts blaming each other, instead of together solving the problem.
Victor [13:56]
But I think what it also does is that 04 hours is this sweet spot between micromanagement, and it’s impossible to estimate everything in 15 minute blocks, everything’s going to be off in that case, and nobody will pay attention to the estimation anymore, because you just can’t hit it. Versus if you estimate in chunks too large, you won’t notice soon enough that you’re lagging behind. Versus here, you usually do every day notice when something’s just not getting done. So I assume that is also the benefit of this and why this works so beautifully. What kind of projects do you use this on?
Anders [14:38]
I use it on our day to day support of our clients. So I’m not project just on? — Well, one of the things you learn as a consultant is that we have a few clients where we don’t know what but we know they’ll eat a time block or two every week, and if we don’t plan for that, but fill the week out with other projects, and we know the client, on average uses the other ones, then we have to let down both the project client and the ad hoc client. So you learn how much time you have for your products, and you learn how much you have to reserve for other stuff, and it just gives a sense of tranquility for the developer or for the maker, when they meet up Monday morning, after the Monday meeting, that they know what they’re going to do, then they feel safe and leave feel secure and having enough stuff to do for the week, and it’s better to get more done on the project, those we were the ad hoc customers don’t reach out to you than under delivering week after week and it takes three weeks, when you’d get a new team. When I’ve taught people this methodology.
Anders [15:56]
After three weeks, everything starts to click, and people start to plan for the — if you have 10 time blocks, as a developer here, in Denmark, we work around 40 hours a week, you will have approximately 20 hours of development time the other 20 hours is email, chat, meetings; is being interrupted by me or the other line manager or whatever. So you actually only have 20 hours of flow time, but when we plan the first week, people put 40 hours of flow time into the calendar, and I’m like, so do you really think you’re going to do that all this week? “No”, but why are you planning it? And they’re like, “you know, there’s this disconnect”, and then we start removing until people say, Yes, I can, this is a reasonable week for me, and three weeks later, people, they hit the sweet spot of reaching 09 or 10 blocks a week, we want to push our limits, we want to learn, we want to be faster. So we always want to push our limits. But usually, that’s where we end up. Unless, of course, we are talking about the odd employee who — for some reason, insecurities won’t promise anything and won’t deliver, and this is a good methodology to finding the toxic players on the team who actually is not trying to build trust was not willing to be vulnerable, and open up and have a look at what they perform and they shouldn’t be on my teams.
Victor [17:37]
Is there anything that you do or is there some coaching or some second chances that you give? Or what do you do if someone simply can’t get their — I don’t want to call it quota, but make whatever they set themselves for the week and that…
Anders [17:55]
That’s never going to happen. I haven’t seen that happening yet. What I’ve seen is that people — When, I look people in the eye and say, “So, can you commit to that week? Are you going to Promise me that you’ve gotten everything done next week?” And they said, “no”, and it’s okay to say no, the first few times, and I said, “Okay, what should we remove?” And sometimes every now and then, is very rare. I end up with a guy who ends up removing everything before he can promise he gets anything done, and I’m like, “Okay, there’s something really disconnected here”. So it’s not about not, it’s about they won’t commit. They don’t trust themselves, and they don’t trust their abilities, and they are uncertain, and no matter how uncertain you are, how new you are, how green you are, you can commit to something. So if you won’t commit, it’s a different psychological problem, and they’re just toxic. Because they’ll say something. Yeah, I think I’ll get this done, and everybody will count on our team members delivering and they won’t, and everybody will get frustrated by that team member not delivering week after week after week. Again, it’s not about how much you deliver. It’s about being able to trust you. Because Firstly, I’m going to do something I have. I need your delivery Monday so I can do mine Thursday, and if you don’t deliver again, I’m just going to roll my eyes and think bad thoughts about you and the team is going to suffer.
Victor [19:33]
The very interesting takeaway here probably because Startup Founders listening to this may be thinking okay, but billable hours aren’t that important for me or even? Well, I do have deadlines, but it’s more important for me to get some things just right and spend a bit more than having people just promise deadlines but what probably the most important thing or the takeaways here that people who give themselves a scope and not have it assigned by someone but agree on a scope for themselves and then commit to it, actually do it. Is that what it is?
Anders [20:17]
It is. So you build accountability, people have to train their accountability to adhere to this methodology, you have to be accountable, and they train it, and they take it as a personal failure if they don’t get stuff done, and they’re going to reach out, and you want accountable people, you want people who when they see something is wrong, they fix it, instead of thinking that’s not my area of responsibility, especially in a startup. You want people to notice, or this is a good opportunity and do it instead of waiting for someone else to tell them, we want people to be really accountable, and you need trust, and you need vulnerability, and you can only build that when everything is going good.
The other thing, the other takeaway from this methodology is especially and I’ve used this a lot, when using remote teams is that; with my consulting clients, I sent an email out my team sends an email every Monday morning with, we’re paying this and we didn’t get this done last week. But we did this instead, et cetera, et cetera. So when I work with remote teams, I just gently try to nudge them to email me every week, say, this is all the tasks we know, this is what we got done last week, this is what we are planning to do this week. Because again, that builds the trust that they have this accountability, they know what they can do, and they adhere to it and they deliver. I asked every remote guy I’ve ever worked with to do this, and some does, and some doesn’t, and if they don’t I have to call them, I have to check up on them. But if I just get an email every week, I have No — They don’t pop up in my head, like, what are they doing this week? I’ve just know. So I can concentrate on other things to put out fires at other places.
Victor [22:25]
Which is great. You mentioned it, especially in remote environments. Does that also work with contractors who are not full time? Because what I think is that they may want to commit to something, but then something completely unplanned from a different environment than yours comes up as it always does, and that probably destroys that that vision a bit. Have you worked like this with independent contractors as well?
Anders [22:58]
Yeah, and the problem isn’t different from me having clients in my consulting, because the rules, whenever we can’t deliver on something we committed to; to a client, we have to tell the client. As soon as we know.
Victor [23:21]
So it’s also about communication.
Anders [23:23]
It’s about communicate, [crosstalk 23:17] Yes, this is not a methodology to get work done. This is not an estimation methodology. This is a communication methodology. It is a framework for getting the very important communication running. It’s nothing else it’s about communication, and I’m sitting right now I have a remote team, and we’re way behind schedule, I got hit by Corona. Not me, but my team got hit by Corona. Now we have a team member with a broken rib. So it was really going great, and just as my primary on this project, got back from Corona, the remote team got Corona, and everything goes haywire [phonetic 24. But luckily, I knew it the same day as he knew it.
Victor [24:19]
Of course.
Anders [24:20]
And then I could call the client who are depending, really waiting. I said, sorry, we’re not going to — You know, now they’ve been hit by Corona. So now we’re at least four weeks behind schedule, and for the first time my client said, Oh, it’s starting to be a problem because it’s a new ecommerce system we’re building, and we’re starting to lose customers because we haven’t switched over and the old one is an update on the stock info, and I was like, Oh, Jesus, I wish you told me that early, and they said, Yeah, but we didn’t think it was going to be a problem. But now I’m telling you, I’m like, Okay, I’ll build a connector from the new economic system that is working into the old shop system so we’ll can update the inventory and get that working.
Anders [25:03]
So you don’t lose customers because they get angry because they order something that isn’t in stock, and if I hadn’t reacted immediately, on the information from my side, they wouldn’t tell me that they will lose and customer. Trust would start to deteriorate because they would sit in the camp singing, why is Anders delivering that stupid ppppp? And I would be like, why didn’t they tell me bah, bah, bah, bah, bah, bah, bah and think they were stupid, and we would roll our eyes and the cooperation would go to pieces. That’s just by being proactive and honest and transparent. This didn’t happen — And now that you can wait indefinitely for the update, because I’m just going to push the inventory out in the old subsystems. So they don’t have any rush anymore, and it was just one quick 15 minutes call that made — something that could have gone haywire. Just work.
Victor [26:00]
That’s a beautiful takeaway. Maybe a last thing that that we can discuss to wrap this up is now if anybody’s listening and they want to say, Okay, I would like to try it, you already said takes about three weeks. Any tips or takeaways and how to implement this with an existing team to try this on in an easy way?
Anders [26:23]
You have to do it fully for the entire team. At sub teams and teams below, you can do it half-heartedly. So playing with it, it’s as simple as taking — We started just on a piece of paper, and just 10 blocks on a piece of paper, and with post-it notes, you can put them down. I said, “This is my week, do that start there”, and then just be honest about, did you get things done or not? I’ve been at first weekly meeting where people discovered that they didn’t test their software as a thought, where the manager was like, Don’t we have those test cases? No, no, they haven’t been running for weeks or months, you know, skeleton dropped out of every cupboard at all, and it’s not like, it wasn’t there before, nobody just knew.
So it’s more about starting to communicate about what you’re doing, and giving everybody on the team five minutes of time. Nobody should talk less. So if you don’t talk, you just sit silently for those five minutes, but everybody should tell what they’re doing, and then just follow up next week and follow up, and a bit of caution, I’ve been doing this, we’ve been doing this for four or five years, I can’t even remember anymore, and every summer vacation, and every now and then; I am too busy, I have to do something Monday morning, and I’m not there for a month because something our client or whatever, and we stopped doing the Monday meeting and we forget about it, and then all this noise and all these problems start creeping in, and I’m like, “Huh” and we sit down and we do it, and we have a lot of calls to make the first week, and then everything quiets down again, and we’ve seen this four or five times.
So it’s not easy. Because if you have any self-worth issue or self-confidence issues, they will try to argue why this isn’t a good idea. So it’s always a battle between the lazy side of you or the and the side that want to perform, and you just have to consciously decide that we’re doing it. No matter what we’re doing it.
Victor [28:53]
Nice. Got to stay persistent. Awesome. Thank you so much. That was super, super helpful and super insightful. Where can people learn more about you, about the Time block methodology? Where would you like to point people?
Anders [29:09]
Well, they could go to timeblock.com and read a little bit about it, and they should reach out to me, and we can talk about training or coaching. I also do coaching. So there’s a lot of possibilities for improving your performance.
Victor [29:29]
Wonderful. Thank you so much. It was nice to have you.
Anders [29:32]
Thank you for having me.
