Below you will find an internal letter I’ve sent to to
[email protected] a day before this blog post was published.
Over the years I’ve seen more then once companies that share in a transparent way some story. It’s always about something really good (or the illusion of it as “good”), such as unlimited vacation days. Or something really bad, mostly known as “Post Mortem” for after a major screw up. Like leaking all the passwords of a site.
I don’t remember reading one that is about a mediocre state. That is, a state of something that is mostly working, but it’s not optimal – in fact it’s a good few levels below it.
It’s pretty clear why it’s not done, although the more I’ve been thinking about it, I came to realize that it’s those mediocre state that most companies share. And that actually, sharing the below email could help others more than tooting our own horn.
Now, don’t get me wrong. If you ever heard me talk about Gizra, you know I think highly of us, and we have a long resume to prove it. But that only made writing this post even more exciting.
It’s not even about putting myself out of my comfort zone (because I’m not). It’s because a life long experience of doing things slightly different showed me it (usually) leads to good and surprising things. Sometimes it just blows up in your face.
So here it is the letter in full. I’ve changed the clients name for obvious reasons (but tried to give them a more descriptive context), otherwise the email is un-touched.
As we have a new Productivity system in place, Brice and I are able to much more easily analyze the numbers on the project level which directly affects the entire company.
We’d like to share some high level numbers with you, along with some commentary. The data is for March 2017, and the important parts are the following three lines:
- Total reported hours: 2,300
- Billable hours: 1,465 (64%) - the work hours within the timebox (our commitment to our clients)
- Non-billable hours: 835 (36%) - the work hours beyond the timeboxing including unexpected and out of scope tasks
At the end of this mail you can find the breakdown (so each person can find their own impact), but here are some comments and explanations of what’s wrong, and what needs to be improved. You will notice that each comment is targeted at you (and us). That is, “we” as individuals. Each and every single person in the company directly impacts the success (or failure) of Gizra.
Total reported hours
We’ll start with the easy one. The reported total is below our optimal capacity. We are calculating 150 hours per month for each person, taking into account an average of 13 holidays, 15 vacation days, 5 sick days, 4 convention days, and the fact we are humans and not every day can be super productive.
Given that not everybody’s work is reportable (e.g. sales, HR, etc), in our current size (23 people), our optimal reported hours should be 2800 hours per month (approximately 18.5 people in full time).
For some, clocking those ~7 - 8 hours a day is easier than others. If you find you are struggling with this for various reasons (e.g. clocking only the hours according to the timebox, and not the actual time you worked), reach out to your team lead/ account manager/ Rachel/ Brice or me. We want to make sure that you - like Gizra - get paid for every hour you work.
We found that a large portion of our account managers’ time was non-billable. To remedy this, we are transitioning, in our price offers, into time & material for account managers instead of 20% of the project scope. That is, we will now be able to bill for every account management related task.
Billable vs Non-Billable
We now have the numbers that indicate that development billable hours are below expected, meaning that we are immensely exceeding our estimates.
Here’s where timeboxing becomes so important. It’s our way of making sure we don’t go over scope. If we’ve estimated a feature in 40 hours and we end up doing it in over 400 hours (sadly, a true story out of too many) it means we’re failing in many frontiers – and the estimation isn’t necessarily one of them! Often time it’s the communication with each other and the client regarding what is expected from the task.
When we buy a $10 meal in a restaurant, our expectations are set accordingly. We can more or less imagine the size and quality. With websites it’s harder because our clients don’t know the equivalent of, for example, 4 hours (we know - it’s not much).
So it’s up to the account managers to constantly communicate those expectations with the client and with the devs. And for the devs to not go over them and to constantly communicate with the account managers if things don’t fit in those hours and give the heads-up when necessary.
Timeboxing doesn’t give too much room for interpretations. It’s quite binary. Either you are on it, or not. Every task should be timeboxed, and every task should be done in the timebox per the process described here. Completing a task is obviously important, but only secondary to making sure you don’t go over the time. If the process is still not clear, please reach out to Rachel.
Our goal is obviously to reduce considerably the non-billable. Every issue, every timebox, every person has an impact on that goal, which we now can easily monitor in real time.
As I’ve mentioned previously - time boxing, along with driving the sales, is the most critical factor - and everybody should pay careful attention to it. We can assure you, from looking at the numbers, doing so will have an immediate and considerable positive impact.
Breakdown per project
|Mind is still blown from what we’re doing for them
|Lovely. Simply lovely.
|Not exciting, but pays the bills
|They have chance with that product. Fine people
|Boring and annoying
|Thank god for having them
|It’s actually more fun than I thought it would
|Come on, how much do you expect to get for 25 hours?!
|I have mostly bad things to say about them
|Project X, unfortunately you’ll see it also in the Non-billable
|Seriously, what were we thinking?!
|Please kill me
|Actually, no, please kill me here!
|Drupal Elm Starter
|Misc (mostly things not registered correctly)