It was my 3rd week as Head of Development. “Ermm,… what happened ?… Nothing much got done this week.” The Team Lead gave me a puzzled look. “We finished quite a bit this week”.
“But looking at the board,..” I replied.
He smiled, “Oh I see,.. we’ve been working on a project for the Founder,”.
“Ah OK, which board is that on ?”
“It’s not any board,.. it’s the Founder’s project”.
Now the Founder is a smart guy and a decent one too so I wasted no time in pulling him on this. “Oh, I didn’t mean for them to put so much time into it.”
Hidden Work is very human & all too real
It’s not that the Founder or the Team Lead deliberately went off script, it’s just that there were more options than priorities. Hidden Work is a very human phenomena. It’s almost always detrimental to the company but generally does work for the individuals involved. Managers don’t need to make difficult calls about what’s important now and, perhaps more painfully, what must be put off for the future. Engineers work on hidden things because there’s much less pressure if not many others are involved. That’s expecially true if the hidden work is more appealing.
For the Founder & the Team Lead this was an exciting idea. Because it was hidden it had never had to pass the test of “do we need it now ?” It was too convenient for everyone involved to assume that somehow this work would ‘just happen’ without impacting on the rest of the business. I’d be more angry if I wasn’t just as guilty as them for embarking on hidden work in my time.
If you’re working somewhere where management moan about engineers not delivering, engineers complain that management doesn’t understand how difficult their job and the most important things are all the things NOT being worked upon then the chances are there’s a lot of hidden work going on.
Personally I was peeved because I like to use metrics to understand how efficient the software delivery process is. By that I don’t mean tracking individual developer output but understanding where the bottlenecks lie, in Product, in Engineering or in QA. Suddenly losing a week’s worth of data makes it really hard to have much confidence in any metrics.
I’ve also found Hidden Work is a massive red flag that there’s no control over the WIP but that’s a different story.
OKRs
It felt to me that I needed some sort of list that I could take to the engineering teams with the unequivocal message “If someone asks you to do something that isn’t on this list then tell them to contact me.” I’d tried it before, with some success, but that was based on a list of Objectives I’d created for myself. My experience of Objectives in a previous startup wasn’t great. Three months is a long bet when working somewhere that’s lost control of the WIP and struggling to find its direction. My CTO told me at bonus time: “The bad news is that you only scored 30% on your objectives this quarter. The good news, that’s the highest score in the company.”
Since then I’d read Measure what Matters by John Doerr, the father of OKRs, and realised that OKRS were more than just objectives under a different name:
- Objectives were stretch goals for teams to aspire-to not benchmarks for individuals and were designed to join-up across the company so that it moved in a single and intentional direction.
- Objectives were backed by Key Results - the measurable and easily understood by everybody measure of success for that Objective.
- I particulary likes that Objectives don’t have to cascade. If the CEO has an Objective that one specilaised engineering team can fulfil then his OKRs can be applied directly to that team. That felt like the welcome removal of a very artificial constraint.
Agreeing 7 sets of OKRs for 7 teams that pointed us all in one direction is so much easier than dreaming up 55 sets of objectives for individuals that do the same.
Of course what also helped was working for a company that generally understood where it wanted to go. OKRs wouldn’t have helped the startup I mentioned above since they were drifting in so many directions that seemed to change frequently.
Making Work Hard to Hide.
The problem was we were using JIRA and it’s really hard to get a holistic view of everything going on across a collection of JIRA boards making it all too easy for hidden work to fall into cracks between boards. Now whenever I criticise JIRA someone always tells me that JIRA can do all these things if its configured properly (& we purchase enough expensive plugins) but I wanted a tool where easily navigating and visualising an entire workstream was baked-in rather than just possible.
Luckily I was introduced to just such a tool in a previous company - Kanbanize. I have to be honest and say that I didn’t quite appreciate its value at the time. The penny only dropped while I was struggling with what to do with all the hidden work in this company.
Kanbanize is built to join initiatives (or epics in old money) to tasks across boards. In three clicks we could navigate from the CEO’s objectives to the Product initiatives and the engineering tasks that support those initiatives. Better still the whole thing is highly automated. When the first engineering task moves to “In Progress” the Productv Manager’s initiative and the CEOs objective also move to In Progress. When all engineering tasks are completed then the initiative and objective automagically move to done.
The ability to easily navigate around the entire company’s workflow makes it really hard for Hidden Work to happen accidentally.