Fog Creek

Using TimeBlocks to Increase Maker Efficiency – Tech Talk

In this Tech Talk, Anders Thue Pedersen, founder and CEO at TimeBlock, explains a lightweight, Agile working method created with makers in mind. He describes his own personal experience in using it to organize work at his own company and how it can improve project efficiency and transparency, between makers, managers, and clients.

About Fog Creek Tech Talks

At Fog Creek, we have weekly Tech Talks from our own staff and invited guests. These are short, informal presentations on something of interest to those involved in software development. We try to share these with you whenever we can.

Content and Timings

  • Introduction (0:00)
  • Theory Behind the Method (2:46)
  • How The Method Works (7:03)

Transcript

Introduction

I’m going to talk a little bit about TimeBlock, which is an agile working method I stumbled upon or invented, whatever you want to call it. The reason for my invention was actually that I had a project that failed catastrophically in December last year, and I was really wondering what was happening, why it happened. I went on Christmas vacation for 14 days, and I was really thinking that I had to stop being self-employed, stop running a company since this wasn’t the first time that a project failed. I didn’t really have any insight into why some of my projects went really well and some of the projects went really bad. During my 14 days of vacation, I realized I wanted to give it another try, and I thought a lot about what had happened with the latest project. One of the things that really inspired me from other companies like Buffer and Baremetrics is the transparency. I’m running a pretty transparent company myself, but I realized during the vacation that my workers, my employees, weren’t as transparent with me, especially about what they did get done and what they did not get done, how fast they were moving forward, and in what direction.

So on January 5th this year, I made a lot of changes in how we were working. Three weeks later, I realized that I had started to sleep really well. I used to always worry about stuff with my company, with projects, timelines, deadlines, resource allocation, and after running this way for three weeks, I’ve got a clear overview of my entire company. At the same time, my employees were happier. They were more satisfied, and they did 25 to 33% more work, working the same hours or less. I started talking to people about what I did, and people started copying me. I was like, I’ve got to do something about this. It’s turned into the TimeBlock method. Of course, we are building a website to support it; an IT support system, but I’m not going to talk about that today. I’m just going to talk about all the learnings and how we actually run our company now, and a lot of other companies also run. That’s the introduction. That’s how we invented it.

Theory Behind the Method

First of all, let me start out by talking a bit about one presumption and a requirement. First of all, the presumption, which is kind of strange to talk about, but it’s really important to know, is that most people or all people hopefully, go to work to solve a problem and do a good job. By this, I mean, if you’re building software, you go to work to build the best software that you can, to really perform 110%, to be proud of what you’re doing, to be able to go to a conference or two, family dinner, and talk about what you’re doing with a proud wife. In reality, in many companies, people only get to deliver around 70% of that. They do a lot of other stuff which isn’t in their job description.

The other thing I’ve discovered are people don’t talk about as much is about being in flow. The thing about flow, which you know, is a fantastic feeling. The most important thing is that, if you get interrupted, it takes… Really recent research has proven that it takes up 25 minutes to get back into flow after being interrupted, such as a few minutes. That’s the basics of the method, is that we want people to be able to do their job really well, and we need people to be able to get in flow to perform.

We have two kinds of people in most companies. We have Makers; programmers, you and I, for example. Makers need to be in flow. And again, flow requires that you have a task that takes a couple of hours. You have a lead-in and lead-out of 10 to 30 minutes, so you can’t jump from one flow to another. You can go from programming one piece of software to another just like that. You need a break for that, and we also know flow enhances the performance a lot, 10 to 100 times. Some stuff you cannot get done if you are not in flow. It’s just impossible to do really complicated, cognitive stuff if you’re not in flow.

On the other hand, we have managers. They need overview and insight. A manager is basically hired to make sure that there’re no fires anywhere in the company. To do that, they need transparency from their Makers. They need honesty, and they need some valid estimates and a valid feedback.

What I realized is happening in most companies, is that we have managers who want this overview and insight, and we have these makers who want to have calmness and quietness to work. This difference in need creates a kind of a battle between those two. The best way to really talk about it is to see how we’re working now. This is my calendar from February. A classic manager’s calendar with multiple meetings, double-bookings, etc.. In the same week, this is one of my maker’s weekly schedule. What happens is that Tuesday morning when Marcus, my maker comes to work, he says hi to all the others, gets his coffee, drink the coffee, check his emails, answer important stuff, and around 9:30 he sits down with his task at hand, and really starts to dig into the software. At around 10:00 he hits peak flow. He knows he has around two hours until lunch, and he really is looking forward to being in flow and creating some magical software. If any of you know how it is to be in flow, you also know that it’s a really wonderful feeling to be in flow. The thing is when Marcus gets to around 10:00, and hits peak flow, my meeting is over. I go over to Marcus and say, “What about this … What about that … ?” This interrupts Marcus and he has to go out of flow to answer me.

How The Method Works

The way TimeBlock works is this: we divide a week into 10 blocks. One block from your morning until lunch, one from lunch until you go home. A block is not necessarily all the time. It’s not from 9 to 12, which is our normal morning time, around 9, but it’s one task that requires a flow. For me, a sales meeting could be one or two hours, and then the rest of the time I will not be able to go in flow twice in a block. It’s not possible for me to go into a good flow twice in three or four hours. I can only do it once. That’s why we divide the week into these 10 blocks.

When we get a project, we divide it into TimeBlocks. It’s very important that it’s the makers who divide the project into TimeBlocks. Me as a sales person, or the customer, or a manager, defines the project or the tasks. I often come with a bunch of screenshots for the makers that I’ve created with the customer and designer. Then the maker defines the need, the TimeBlock for each of the tasks in the project.

Another thing that’s really important is that the maker themselves plans the week. The manager sets the deadline, says this project is more important than this project, but the maker themselves plans the week. This is really important because this gives the makers autonomy. It gives the makers the option to divide a project into TimeBlocks where there’s room at the beginning and the end for mastery. If you have seen anything by Dan Pink, his talk about drive, or motivation, you know that makers really need three things to be happy: purpose, automation, and mastery. Letting the makers define how much they can do in a TimeBlock and not having it be a specific amount of hours, but just these blocks makes them more internally motivated. Also, a task can’t be longer than two TimeBlocks, so if you have a task that takes a week, you have to write 10 different, or five different time blocks for it. The reason for this is that when you have to get something done every day, it’s much easier to stay on track, and it’s also much easier to see if you are going over or under your allocated time. Every day you’ll know, did I get done today what I planned, or am I lagging behind. If you’re lagging behind, you should always inform others involved in the project.

Besides this, we take every task we get from our clients and divide them into TimeBlocks that we’re planning to do in the week, we also have a Monday meeting. In every Monday meeting, each person talks about last week, what did we get done and what not. If one of the makers or me didn’t get something done, we start by talking about why we didn’t reach our goals. Why did we not reach this TimeBlock? We talk about what we have learned, do we need to have the IP address of some server or something like that, before we actually should have planned the TimeBlock. Were multiple people working on the same project and we didn’t talk together Monday morning who did what, so we worked in a different direction?

Most importantly of all, we talk about what we will do differently this week. We frame it like if I had to do the same task this week, what would I do differently, because we have to learn from our mistakes. After that, we talk about what we are going to do this week, what TimeBlocks we have planned, what tasks we are planning to reach. Often, I will come with a client’s request for something to be done and we’ll shift TimeBlocks around. The makers themselves will help each other reach the goals. Again, getting the makers to plan the week and plan who will do what. It’s much more relevant than me trying to figure out who is best at doing different stuff.

After the Monday meeting, we inform everybody about what we’re doing. We email everybody internally on the team, and we email our clients, our customers about what we’re doing. Everybody is informed Monday morning about what will happen this week and every project where there is something that could go wrong, people are informed on what have been done or not. If somebody during the week is lagging behind and realizing they won’t be able to finish a TimeBlock, then they always have to email it to the team and the customer that they won’t be getting this stuff done. Everybody’s informed really early about deadline creep or scope creep.

That’s it. That’s basically the method, the short version of it. There are some minor details, but that’s how it’s done.