A lot of engineers struggle to take breaks. This is especially true, in my experience, when engineers are pairing and practicing TDD. Many teams I was on at Pivotal recognized that not taking breaks was making us less productive. We often used tools to encourage or enforce breaks. Time Out was popular, as was Tomato Timer.

Why is this so? Some of it, certainly, is pressure from above; many leaders I've worked for (usually briefly) worried about whether their teams were working enough, and pressured them into putting in more hours. This can't be a complete explanation, however, because I've seen many engineering teams, and many engineers, fail to take enough time to rest even in the absence of leadership pressure.

Several of the engineering leaders I talk to regularly now tell me that getting their engineers to stop working – to take breaks, to take vacation, to explore, to play – is one of their top problems. They want their teams to maximize throughput, even when that means waiting for another team or another system to finish their piece of a particular work item. Their engineers tend to optimize for utilization, by picking up additional work while waiting.

Is this just habit, informed by years of working for relatively less effective engineering leaders? Or is there something deeper at work?

Once, I was on a team that had our Time Out break-enforcing software configured to stop us for ten minutes, every hour. An engineer on the team sitting across from us heard us talking about this setup, and remarked, "Ten minutes every hour? That's more than an hour a day that you're not working."

This wasn't an executive who didn't know any better, or even a manager who had a stake in our work. This was another engineer, commenting unprompted, that it sounded like we weren't working enough.

I hear stories like this every so often. Some engineer (usually one with a lot of XP consulting experience) will join a product team that pairs a lot (and has been pairing for a long time) and will be surprised and not a little dismayed by how much time they seem to spend "not working." Taking breaks. Having meetings. Often that engineer will nudge the team to spend more time time "working" – which means, in this case, writing code. Building stuff.

There's a good instinct here. Another story I hear a lot is the one I usually hear when someone with Pivotal experience joins a new company. "I've been there for three months," that former Pivot will say, "and I just delivered my second story. The first one took two weeks. And everyone says I'm ramping up really fast."

Most companies waste shocking amounts of their engineers time. One of the reasons that Pivots can get kind of cult-y is that we've seen it, man. We've seen what it looks like when a team ruthlessly eliminates anything that doesn't directly lead to working code in production. We've seen what it looks like when a company values engineer time at its actual cost, buys them good equipment quickly, and minimizes their paperwork and meeting load. We've seen what it looks like when an engineering team takes its own productivity really seriously, keeps its tests fast, learns its editor, eliminates anything repetitive or time-consuming.

People will tell us that what we're describing is impossible, that "no one works like that." That everyone burns engineering time on calendar management, fighting with poorly-configured internal systems, and keyboard purchases. And we think back to all the new hires we've seen ship real, working code on their first day, and start wondering what else this person believes that's obviously, trivially wrong.

But there's a dark side to that instinct for productivity, because some of the "unproductive" things that you can squeeze out of a team for six months in service of going fast will turn out to have been important later.

Our whole culture teaches us to measure our self-worth by what we produce.

Another reason that Pivots can get kind of cult-y is that a well-run Pivotal team was really good at making engineers feel productive. I have a friend who talks about how he misses pairing all day, because he misses the feeling of having done "an honest day's work." Back when he was pairing, he would leave work tired, yes, but also satisfied that he accomplished something.

On a Pivotal team, there was always another story waiting in the backlog. There was always something to do, and you could trust that someone else had decided it was valuable. You could show up, sit down, and get some "real work" done. If you're the kind of person who worries about whether you're doing enough, who will work to exhaustion because it never feels like enough, it could be really relaxing.

But it also created an entire organization that never had any time to think. Never had time for anyone to wander around and experiment with something that might not pay off – unless they were able to work after hours, and willing to take the social pressure against that. Never made space for people to sit with the discomfort of not having anything to do, or to figure out how to deal with that discomfort on their own.

An organization that, honestly, wasted a lot of engineering time in a different way: It built a lot of stuff that no one really wanted, or that wasn't worth the cost, and missed out on opportunities to build other things that could have been more valuable.

Doing work that really matters – identifying the most important problems, and then solving them in the best way – takes some idle time. It takes time, and a hard-to-schedule kind of mental work, to even work out a framework for identifying the "important" problems. It takes a relaxed mind – the shower mind – to sort through all the accumulated material of day-to-day, task-oriented life and identify the patterns lurking beneath the surface.

It wasn't that taking breaks or wandering around was explicitly discouraged. Maybe occasionally, but moments like that engineering commenting on my team's break schedule were pretty rare.

It was more that it was so easy not to stop. There was always another story, ready to go, right there at the top of the backlog. All you had to do was pick it up.

I've been talking a lot about Pivotal, because I have a lot of experience with the Pivotal version of this problem, but you just have to look around a bit to see that this isn't a Pivotal-specific problem. A lot of people have trained themselves to stay busy, to not interrogate why it is that they feel so uncomfortable sitting still.

Work, itself, is an opiate. And you can't do your best work when you're stoned.

The absolute best, most transformative work, the work that really matters, isn't done by people working 12 hour days on whatever's in front of them right now. The best work is done by people who find a balance between shoulder-to-the-wheel execution, and wandering-through-the-woods reflection.

As a small example: I started this newsletter with one rule, that I was going to publish something once a week. That committed me to a certain amount of grinding. If it's Thursday afternoon and I still don't have a post I'm happy with, I'm going to spend the evening writing, dang it.

That's been a good habit. It's helped me generate ideas, and to get feedback by shipping regularly.

But after a few weeks of sticking to that schedule, I had a bit of a panic attack because I was so "behind" on my to-do list. There were so many things I intended to do that I wasn't getting to – things to write, things to research, work to do on the site itself, errands to run.

I needed to build up a buffer. I needed to identify a niche. I needed to do all this work around the house, now that I theoretically had all this time.

None of this was work that I had to do for a boss. I wasn't failing anyone else's expectations. But I was still deeply stressed that I wasn't working enough.

I managed to stop myself, reset my expectations, and stop scheduling so many darn to-do items on my daily lists. For a few weeks, I stopped tracking tasks related to the newsletter at all. And I noticed something funny: I was still writing. I was still writing really interesting things. I was still writing things that people wanted to read, and that helped me move towards my goals.

I was, in fact, more effective, more productive, than when I'd been hassling myself about working more all the time. I spent more time wandering around and taking more breaks, but I spent more time really working, too, rather than engaging in work-like procrastination, like reading Twitter and obsessively refreshing my Google Analytics stats.

So if you find yourself worrying that you, or your team, aren't working enough, I want you to ask stop for a moment and instead ask yourself: Are you getting things done that matter? Do you know what matters?

And if you don't know the answer to that, maybe ease up for a minute, on yourself and the people around you. Maybe spend a little less time working, and a little more time listening – to your team, to your customers, and to yourself. It'll be uncomfortable – there's a reason you've been working so hard not to think about it – but you might find that you like doing things that really matter to you more than you like being busy.

Jobs

Flexe is hiring engineers across a range of roles, experience levels, and locations. They run a logistics network that provides flexible, on-demand delivery, warehousing, and fulfillment at massive scale, so the domain is fascinating if you're at all interested in large-scale distributed systems of real physical objects. Of particular interest is their SRE listing, for the team that maintains their developer platform. 100% remote but with an optional Seattle office, competitive pay, and solid management.

Photos

I'm not much of a landscape photographer, but I've gotten a few shots on this trip that I like.

If you liked these you may also like my photo zines.

Self-promotion zone

I've added another weirdly-George-Bush-themed-postcard to the store.

My partner, Jesse Alford, has technical sensibilities pretty similar to mine but is actually running a software team, and he tweets.

His "OH" tweets aren't always quoting me, but...

Having become a "technical leader" he's currently exploring what that means at his current position, but also what that looks like elsewhere, and what the next phase of his career might look like. If you're looking for an engineering leader or advisor who can enable high trust, high safety, diverse technical teams in challenging, high-change environments, send me an e-mail and I can put you in touch.

Oh, and last week he was on a panel by the Agile Alliance. If you're a member there you want to hear more about his experience running a post-XP team at VMware you'll want to check it out.