Back in the heady days of dotcom boom (1999 – 2000) I was hired by an e-commerce startup company as their Chief Technology Officer. It was a sudden and large leap in my career, being mostly focused on creating software and only marginally involved in managing the process of software creation.
To cut the long story short, dotcom boom quickly turned into dotcom bust, and by April 2001 the company went belly up. Ran out of funding. Sad story, but it was a great learning experience for us who got involved in that venture.
My duties as CTO were to build the engineering department from ground up. My department got funded to open the office in downtown Vancouver (the US to Canadian dollar exchange rate at that time made the venture look much less expensive to the US investors). We procured office space, office furniture, workstations, servers, licensed all required software, and then the race was on to hire talented engineers.
One of the reasons the company hired me as a CTO was due to the fact that at that time, I was teaching software development courses at the local BCIT college, and they rightly assumed I’ll be in the position to hire talented developers from the cohorts of my students.
Their bet was sound, and it didn’t take me more than a few days to hire a team of five bright, talented engineers who had just graduated the course I was teaching.
Where things started going in the wrong direction
Being young and still inexperienced, I made a serious mistake in managing my department – I took a very wrong approach to planning. When abruptly growing from a hands-on engineer into a CTO role, I missed a few important stops along the way. I had no idea what does prudent planning entail. Back then I certainly wasn’t aware of that, but in hindsight…
So, what did I do wrong? I took a long hard look into the limited budget that was given to my department, looked at the expenses (office lease, licensing costs, employee salaries and benefits), and decided to maximize the time that the budget was buying us. Obviously, we had a limited runway (a stretch of time needed before the operation becomes profitable, or at least starts pulling its own weight). My bosses were very strict about money (who could blame them) and that created the air of anxiety in my mind.
Basically, I decided to tailor my plans in such way to make sure every team member is super busy every minute on the job!
That was a terrible mistake. I deeply regret it to this day. But I didn’t know back then the value of slack time, the value of establishing the flow.
But by foolishly insisting that every task and subtask my team members were performing be done in quickest possible time (i.e., I was pushing to minimize the touch-time), I only managed to frustrate the team and it started dying of attrition.
How would I do it today?
If I had a time machine and could travel back 22 years in the past, I’d do everything differently. To begin with, I would forget about making plans to maximize the utilization of team members’ time. Experience has taught me that maximizing the utilization of resources that are at our disposal has a strong counter-productive effect. A fully utilized highway defeats its purpose, as it quickly turns into a parking lot.
The secret to productivity in knowledge-based economy is ample slack time. We need to be careful when defining ‘slack time’. The danger is that some may interpret ‘slack time’ as ‘wait time’. And that’s not what is meant by ‘slack time’.
When we plan for maximal utilization of workers’ time, our goal is to create some semblance of an assembly line. I may start my day by taking on a list of to-do tasks. As I’m going down the to-do list, I am handling, one-by-one, each task defined for me. Where does the maximum utilization come in?
The maximum utilization mindset comes in at the task level. Under the ‘maximum utilization/everyone busy all the time’ regime, I am expected to spend the least possible amount of time on my task and promptly hand it off to the next worker in line. That worker in turn is also expected to spend the least possible amount of time handing the task passed on to them (the touch-time). If any of the workers end up spending more time than projected on handling their task, that worker gets reprimanded for not pulling their weight.
On the surface, that arrangement may seem very reasonable. We have hired the team, and the crew is doing their job as prescribed. If anyone takes longer than prescribed, it only means they are not fully qualified/fully skilled to perform the duties related to the task. They’re not pulling their weight.
Working under such pressure results in what has been called ‘plate emptying’. As I work, I have a lot on my plate and my job is to empty my plate as quickly as possible. Doing that, I demonstrate to my employer how valuable, how eager I am to continue working and dealing with the next full plate.
Why is plate-emptying bad? It creates a mindset and a culture where workers are rewarded when giving their work short shrift by declaring early completion for work that was only partly done. In the end, the crew trades quality for apparent velocity.
And that’s exactly the culture I had created back in the year 2000 with my team. Wanting to maximize the utilization of expensive staff, I set up the system that openly rewarded skillful plate-emptying. Everything looked great at first, until we started getting hit by those terrible bugs and defects. Suddenly, the blindingly fast delivery (our great velocity) got destroyed by the catastrophic defects that were almost impossible to reproduce and fix. The crew was cutting corners left and right, striving to meet my approval and pat on the back (and a hefty year-end bonuses). Little did I know how much those bonuses would end up costing us.
Of course, once the ugliness of severity-one incidents started hitting the team on an almost daily basis, people started looking for a new job. The team began dying of attrition. By that time, it was too late to try to find the intervention point that would turn the ship around. We started tanking.
So, how would I have done it back then if I knew what I know today? To begin, I’d abandon trying to make plans so that everyone has their plates full during the project. I’d treat the project like a race with passing the baton. Rather than keeping an eye on individual runners, I’d make plans to only keep an eye on the baton.
That way, I’d be able to better manage the progress of the delivery. If the team is delivering frequently (at least once per day, ideally many times per day), I don’t need to worry whether everyone on the team is pulling their weight. The only thing that matters is continuous delivery and continuous release, and if that activity turns into an uninterrupted flow, I need not concern myself with the resource utilization/slack time. That approach would relieve team members from the futile plate-emptying race and would realign their efforts with the business priorities. Meaning, we’d improve our chances of avoiding the fiasco that was caused by the team attrition.
When team members realize that completing their task or subtask does not mean they’ve reached the “done” stage, they start paying closer attention to the quality of their work. A task/feature is done only when it is deployed and released to production and is causing zero bugs or defects.