The Slack Experiment

I am moving to a new client, which I am both excited and a bit sad about…

I think many people will think I am leaving my current assignment because I am unhappy, or demotivated. This could not be farther from the truth, I have actually never been so optimistic about the future of this organisation as I am right now. And I am very sad to be leaving the people I have been working with. The real reason I am moving is because I want to run a rather large life/work experiment. This article is about that experiment.

Background

It all started a few months ago when I watched the keynote speaker, Henrik Kniberg, at a conference I organise.

Here is the full talk: http://www.youtube.com/watch?v=k8DTUYfUOa0

By the way, the other guy in the video is me 😉

My main takeaway from the talk was quite simple. Slack time, time blocked out to provide flexibility, results in a sort of positive feedback loop which creates a snowball effect for both you and your clients. This image below visualises the concept very well.

slackloop

I found myself deeply inspired by this talk, and wasn’t able to stop thinking about it. I started my own company precisely for the reason that I want to spend more time on my own development and ”side projects” like speaking at conferences, teaching, and writing.

But I have found the reality of owning your own company differs substantially from the dream. Most clients want you to work with them full time, and this means that you are tired when you get home and your free time is just a precious as it was before. What’s more, you actually have less free time because having your own company also requires administration.

I strongly considered talking to my current client about doing this, but in the end, I felt they actually need someone 100% for the job they need done. And while they might very well have agreed, I think at least in the short term I would have been doing them a disservice. So, when a new client appeared, without me actively searching for one, I saw this as an opportunity to set these expectations from day one.

I have long been a proponent of investing in the future, and a believe it pays back more quickly than most people anticipate. I believe slack time will work the same. I already have several side projects in my free time www.ScrumBeers.com and www.BrewingAgile.org and there is no question in my mind that these investments have paid back. But I don’t know that for sure, I don’t have any numbers, so I have decided I will run this as an experiment and try to assess the result.

The Experiment

Issue:

Not enough time to explore, grow and learn.

Elaboration

  • I need to earn enough to survive.
  • I am fully engaged with a 40 hour work week, and this means no working hours to spend on improvement either.
  • I don’t think it’s reasonable as a consultant to have my client pay for improvement time that may not directly benefit them.
  • I actually do a fair few side projects in my free time currently.
  • I don’t feel have any capacity left in free time for side projects, all time is either used or needed for rest or family.
  • I worry I will become obsolete if I only focus on today.

Experiment

  • Have one day a week which is for working on projects that further my development or make me happier.
  • Check every 3 months that this time is in fact being used for the intended purpose, and I am happy with the results.
  • After one year, determine if this investment has paid back.

Target condition

  • Having a balance between the need to earn and have security, and investment in the future.
  • Be able to demonstrate that this has a benefit for both me and my customers.

How to measure

One of the following criteria must be met:

  • Earning greater or equal too what I would have earned having worked that year full time.
  • At least 25% happier than I was before the experiment began. (This is something I will measure using my happiness index.)
  • Find at least one way that I feel I have served my clients better, that would not have happened without slack time.

I am very excited to see the result! I will keep you updated.

 

Annonser

The palace

From a friend ”not particularly into IT” (my friend’s own denomination) I sometimes get the question why it is so hard to estimate the cost of a software project. After all, this is my profession, this is what I do, right? If you contract a construction company to build a house, you expect that they have done something similar before, and therefore also know how much it will cost.

I patiently reply that the analogy might not be entirely correct. Software is not a house. If what you need already exists, you just purchase a copy. And if what you need almost exists, you could buy that and then adapt it to your needs, and you would probably not talk to me, a project manager at a consultancy firm. The reason you talk to me is that what you really want is an architect, who not only designs your house – to some more or less vague specification – but also takes care of buying the plot, contracts the builders, electricians, plummers, and then makes sure that everything in the house works before handing over the keys. Preferrably, all of this is in time and on budget.

But this is what you do for a living, my friend insists. Surely your experience should count for something? And after all, it is just a house. And it should still have all the typical features of a house: a foundation, walls, doors, windows, a roof.

Yes, I reply, experience is the key. A house can only look in so many different ways. With more experience, the cost estimate will get better and better. But it is not until I have built every possible combination of features that I will know exactly what your house is going to cost.

But how come that so many IT projects overshoot their budgets with 200% or more? If you have built a number of houses, you should be able to estimate unforeseen additional costs.

Yes, I reply again, slightly annoyed with my friends persistence, I could. But after you have approved the initial drawings, and made your choice of everything from carpets to wallpaper to knobs in the kitchen, you cannot make a single change.

That’s fine with me, my friends say. I do not like too many choices, anyway.

There will be a pink toilet seat, I say, trying to make a point. With red tiling on the floor. And a green sink. Those were the cheapest I could find, and it offset the cost for the large rock in the ground that we had to remove. I hope that is fine then. No changes allowed.

You cannot do that, my friend says. That was not in the contract!

No, I reply and smile, it was not. Slowly I see my point hitting home. I continue, seeing my chance to give great wisdom to my friend.
The only way you are going to get the house that you want – not the one that is in the contract, because by default that is not the house you really want – is if you are with me every step of the way. You have choices to make along the way, no matter what you are trying to build. You are the owner of the end result, not me. And in doing so, you also control the final cost. I will help you and support you in making the decisions if you want, but in the end they are yours to make.

Ah, my friend says, I see that you are trying to make an argument for this agile (and he says the words while doing a quotation gesture with his hands) thing that you always go on about. But even so, I would expect that you, who are the professional, should be better equipped to understand that I do not want a pink toilet seat. And, I would expect you to know what the house is going to cost, at least give me a ballpark figure!

I feel slightly uncomfortable at this point, because I recognize this train of thought. Maybe I am not that professional, being unable to estimate the cost of something I do every day? I, if anyone, should have the tools to do the job right. Doubt creeps in.

And then it hits me. The analogy is false, a mirage.

Because, really, my friend is right and wrong at the same time. He is right, because if we are talking about a simple web site, I could do exactly what he wanted. But a large software project is not a house. Instead, a software project with dozens or hundreds of people involved is more akin to a huge palace with a huge glass ceiling, a large garden and a built-in combined acquarium and swimming pool.

With the mirage shattered, the analogy slightly modified, both me and my imaginary friend are happy again.