There’s an expression in Hebrew: “Baltam”. It’s a shorthand form for something unplanned, or more precisely, it strongly implies: [something that is] impossible to plan. I think it has its roots in the military. In the battle field, you always have to account for some surprises. You cannot possibly have everything planned. Israelis are also (in)famous for improvising. Not so famous for planning ahead.
As an (ex?) Israeli, I recently felt awkward, essentially being accused of being overly bureaucratic. And by a German colleague, of all people. Can you imagine it?? :)
Ok, and just to clarify one thing, this post isn’t about cultural stereotypes, but rather trying to figure out a practical approach to a real problem that my team is facing with new ideas and features:
How do you deal with new tasks or ideas, especially small ones?
“It will only take a couple of hours, maybe a day”
As I wrote before, we follow Basecamp’s 6-week project cycles, and take great inspiration from their books and blog posts.
So things are pretty well planned and organised. Generally…
Occasionally however, we’ll bump into a new — usually small — feature or idea. Something we haven’t noticed before, or that a customer brought to our attention.
And we’re all problem-solvers, tinkerers, we get shit done. Right? So let’s do something about it. Right now. It’s only going to take a couple of hours or so, maybe a day.
But here comes the bureaucrat, with his A-49/2 forms, and a bunch of stamps, and spoils our fun. We should create a pitch for it. And plan it for the next 6-week cycle, they say.
“But that’s like 3 weeks away… And it’s just a tiny feature. Seriously? It’s slowing us down”
Seriously
There’s no black & white answer here, that’s for sure. If something really is crystal clear, simple, and can be acted on immediately, and it’s going to give us some immediate benefit, then it makes sense to “Just Do It!”. Right?
But there are so many hidden aspects, that I think we normally tend to overlook. And it’s really worth considering those carefully.
Protecting time and attention
This is one of the strongest “mantras” of Basecamp in my opinion:
…make it a top responsibility to protect and preserve your people’s time and attention. Treat it as the most precious resource there is. Because it is.
And what happens when you come up with a new, unplanned, idea? It’s extremely unlikely that you can just execute it on your own. You’ll need someone to review your code, or check the spelling, or help you find the right Javascript library to use… So now you’re interrupting someone’s flow, breaking their time and attention.
The odd and interesting thing here however, is that most people are blinded to it. We all LOVE to help. It makes us happy to feel like our skills matter, our opinion counts. So the natural inclination is to stop and lend a hand.
I was particularly surprised by it, when another colleague of mine shared the frustration of this perceived bureaucracy. The funny thing is that the same guy was probably the busiest person on the team, juggling half-a-dozen of tasks. Project tasks, team tasks, bugs. And only a few days earlier complained that he feels like he’s constantly context-switching and at the end of the day, doesn’t even know what he achieved.
It felt a bit like Stockholm syndrome to me. If you don’t actively say No to things, they will keep piling up.
Here’s a short excerpt from Basecamp’s book. A chapter called “Know no”:
No is easier to do, yes is easier to say.
No is no to one thing.
Yes is no to a thousand things.
Who gets to decide?
So we truly believe that the task at hand is going to benefit the company, and would benefit it sooner if it were released sooner. But who gets to decide? Why is another feature — sitting in the backlog for a couple of months now, and could potentially benefit equally, or more — keeps sitting there??
This is where the “natural selection” in business usually works, but not for the best. If the guy with the idea is the CEO, then you can pretty much bet that the feature will get done.
And of course, the CEO can still choose whatever they want from the pitches. But bypassing the transparency and collaboration of the process is a little dangerous.
Which leads me to the next big reason
Is our process worth sticking to?
When we decided to follow the 6-week project cycle, writing pitches, discussing them and then creating project teams, we definitely had some good intuitive reasons: It made sense, and it came from a company that we trusted.
After following this process for over a year, I think we only have bigger reasons to stick to it. It really works great for us. We reduced so much of the stress of planning, we could focus and deliver some great features, and I believe that it pushed us forward a great deal.
But when you’re bypassing your own process, you’re not only undermining it implicitly — indicating that some things are too important for the process. You’re also losing lots of its benefits in my opinion.
Two big things here are transparency and collaboration.
Transparency
I don’t mean transparency in the sense of not hiding things. Those ad-hoc tasks are not really hidden. But in a sense, nobody knows about them. And maybe they are quite small and specific, but I think the company benefits from knowing about changes to our system. “Oh, I didn’t know we had this settings page for the widgywadgy thingy. That’s cool”.
Collaboration
This one is potentially much more important. If you just push something through, you usually come up with a solution immediately (and almost always describe the solution, rather than the problem). And since it’s just a small task, and usually the solution is simple enough, then, well, ok.
But what if there’s a slightly different way to do it? One that is even better? Maybe it would take slightly more time to implement, but it could bring an even bigger benefit? Or maybe it fits with another idea? Or what if we actually remove the whole thing, instead of improving it? Maybe we don’t need it as much as we thought…
Did you really give your idea the time and focus that it deserved?
Without getting those small ideas out for everyone to review and give feedback on, you’re losing some potential insights.
I also found that just by describing the problem, writing it down in detail, it leads me to come up with better solutions. Or other times, to realise that my great idea isn’t so great after all.
Emotion
Try to tell my 5 year old to keep the lollypop we bought at the shop, for when we get home. It’s impossible.
Ideas have a similar effect. Not to mention this sense of achievement when we tick-off this one item from our tasks list. Dopamine, Adrenaline? something is happening.
But then how come I don’t feel nearly as eager about the backlog task I created 3 months ago? The longer it’s there, the less I’m actually keen to do it, it seems. And it has nothing to do with its impact.
There’s a strong emotional aspect at play.
I think we can agree that giving in to this temptation isn’t the best strategy though. It’s not a rational choice.
Is it slowing us down?
So is this added layer of planning (bureaucracy) really slowing us down?
For the particular idea or specific task, sure. Instead of getting implemented right away, it needs to wait.
But as a company, I think it makes things go faster, actually.
We avoid interruptions, protect our time and attention and make sure we prioritise the right tasks for each cycle. Not only right in the sense that it’s the right task to do, but also that the task itself is right. We can improve and refine it.
Does this rule apply to everything?
Obviously not. There are bugs for example. Not all bugs need to be fixed, but some definitely need to be fixed quickly. I think there’s a great deal of intuition and common sense to apply though.
Regular team work is also not something that needs to be planned in the same way. Our regular (non-project) teams typically plan quarterly and report monthly, usually with some monthly projections.
Team leads should manage the work inside the team. I would still advise them to plan and avoid interruptions though.
Exceptions?
Every rule has its exceptions, but those should be made explicitly as well, in my opinion.
So perhaps some very small tasks can be pushed through immediately. Maybe others can still make use of parts of the process?
For example, put forward the idea for review and discussion, but then when it’s clear that the implementation is trivial, we can push it through, without waiting for the next cycle.
From the horse’s mouth
There’s a chapter called Stick with it in the latest Basecamp’s book, which talks about these new ideas. Not explicitly small ones, or rather those from the top, that interrupt the flow of everyone:
These half-baked, right-in-the-middle-of-something-else new ideas lead to half-finished, abandoned projects that litter the landscape and zap morale.
That’s why rather than jumping on every new idea right away, we make every idea wait a while. Generally a few weeks, at least. That’s just enough time either to forget about it completely or to realize you can’t stop thinking about it.
