Practicing what you preach

For this blog post I’d like to make a change from my usual style and share a personal experience.

For the last few months I have taken on the role of Product Owner for a new product our company is developing. It is a bit of a change for the company as they have limited experience in developing their own products, most of the work is typically implementing work on behalf of clients where much of the product development is obfuscated from us.

It is also a big change for me. I have been coaching Product Ownership for a fairly long time now. I previously lead the company’s Product Ownership Chapter and I run a local Product Ownership Meet-Up event each month and I frequently teach Product Ownership and Story Writing workshops.
You might say I am becoming an expert in the theory of Product Ownership. So I could be forgiven for thinking I would find it easy. It is also not my first rodeo, I have been a Product Owner of sorts previously for both hardware and software products .

Before you criticize someone, walk a mile in their shoes. That way, you’ll be a mile from them, and you’ll have their shoes.

Jack Handey

It’ll be easy he said…

Maybe it is because I have been coaching for quite a while now, but the transition back has been far harder than I expected. I am (too) impatient to see progress, I am finding it irritating to write stories for things that I find obvious or repetitive. I found myself tempted to make unilateral decisions rather than involve the team; I wanted to get involved in technical decisions; initially I hadn’t made time to create personas; I was using expediency as a very poor excuse for not doing activities that I believe add value. (all things I used to coach against). In short I am a bad bad man, and a hypocrite too.

We did however create a pretty good Story Map and Road Map, the team got together with some subject matter experts and over a few good discussion and we developed a pretty good understanding of our road-map and high level priorities, still at a high level but with enough understanding to make prioritization decisions. We have got in the habit of writing enough stories for the next week or two and there are a good set of wireframes to enable us to start getting feedback on our designs before we commit to the code. We have found a great balance between getting knowledge value, and then delivering working value.

As the product has progressed we have maintained the Road Map turned it into a living user story map and used it for forecasting and release projections and planning, such a simple tool but so effective for enhancing communication. It’s simplicity served us well, communication became very easy internally and externally, and when when we needed to the forecast was very straight forward – and informative.

Delivery Pipeline

The aspect I am most pleased with is that one of our first priorities was setting up a delivery pipeline alongside the first stories so now every commit we are able to deploy directly to an environment reflective of our customer (no mocks) and a releasable package is created after every check-in. I cannot understate the significance of this and how this one decision has made almost every other aspect of the delivery process easier.

There are certainly things we could be doing better, but overall I am very pleased with what we have done and I am really impressed with the team, they are an exceptional team that makes my job easy. But most of all I feel I have a much better appreciation for some of the issues that Product Owners are facing and I am reminded what a challenging and important role it is in shaping a product, conversely my hope is that I have made the team’s job easier, being on hand to clarify my understanding of customer needs, making design decisions promptly and making clear the priorities. The joy of being part of a team is that we each contribute something vital to the success and we only succeed together.

I have worked to get and interpret valuable feedback from customers and stakeholders, and as ever this is a challenging task. It would be easy to pass on every request and turn it in to a story, but this is OUR product and our role is to interpret requests in the context of our vision, and the reality is that we reject more suggestions than we adopt, every person you ask has a different and often conflicting opinion of what is needed and that filtering process is challenging and daunting, I hope I have shielded the team from the frustrations that entails. But for product owners out there this filtering is one of the hardest but most important parts of the role.

Challenges

The role itself is paradoxical at times, some days it feels like there is little to do, but everyone else is busy, other days you are making decisions that will determine whether the product will be a success or not.

Early on in the process it was hard to convey credibility, I am no SME in the domain and our teams are not used to decisions being made in-house, my vision was questioned, it took a lot of will to maintain my course and build trust, I had a rocky couple of months. I controversially chose to go against some of the key stakeholders and not implement some features they wanted, I was vindicated later, but I knew this was a risk and could easily have gone the other way.

This is the hardest aspect of the job especially when you want this to be a team activity and for the team to share responsibility and credit, but the reality is that the role of the PO is to get feedback from the stakeholders and the team, and then make a decision, that decision can be lonely as there is a lot of subjectivity and rarely a consensus.

Product development is very different to project delivery it is much more fluid and we have evolved a lot over the last 6 months the product has grown and improved and now we have two releases under our belt and a happy customer it is an exciting time for us.

DevOps

I cannot overstate how happy I am with the team or how successful I feel this has gone, I feel like a minor player in such a great team – which I hope is reflective of how well we have worked together and that it means I played my role effectively – although I am pretty sure I was the bottleneck more often than I would have liked.

I will say that we got lucky with the first customer and the support of stakeholders and the team have made it very easy for me. But the one thing that has made this most successful in my mind was the decision to deploy the very first story to a production like environment – that one decision set the stage for a smooth progression and confidence with every subsequent story. I’d encourage that to be the first decision any new team makes.

I was doing a demo the other day and as I was presenting I am thinking (with a disappointing amount of surprise) “Wow – what an amazing product this is” it looks as good as any product out there. Somehow being involved in the process meant I didn’t take the time to sit back and see what we had achieved until that moment.

This is only the first major release and we have many more to come as the product evolves and customer numbers grow. Naturally there are still a few quirks to iron out.

It is my hope that I have learned a lot from this project and be able to use the experience to be a better coach, I’ll be more able to empathize and advise with Product Owners and perhaps be more confident that when challenged I can still apply some of that theory and speak with confidence when I am coaching others.

I hope you will forgive the obvious pride at being part of this team, but aside from that it has served as a reminder to me how difficult being a Product Owner is and how much software is a team sport and the whole team should take pride in the outcome, without any one of us it would not have been successful.

Feedback is not a passive activity

In Lean manufacturing setting up feedback loops is considered a critical part of the operation, so much so there is a term for this – Andon – a system to notify management, maintenance, and other workers of a quality or process problem.

The principle is that it gives the worker the ability, and moreover the empowerment, to stop production when a defect is found, and immediately call for assistance. Workers are encouraged to use this feedback mechanism freely. Common reasons for manual activation of the Andon are part shortage (dependency), defect created or found, stoppage, or the existence of a safety problem. Work is generally stopped until a solution has been found.

Loosely translated an Andon is a Paper Lantern – To shine a light on a problem.

Sounds great in principle, any worker is empowered to give feedback to management if they have concerns over safety quality or even a weakness in a process, but for it to become culture it needs to be adopted in a no-blame manner and used frequently, lack of utilization of an Andon is a serious problem and is addressed in Lean.

If a feedback mechanism is not triggered regularly then the settings are considered too loose. The threshold for triggering an Andon would continually be made tighter and tighter, quality is expected to be higher, time for a task is squeezed and so on until there is an increase in frequency of Andon being used.

The aim is to get a regular feedback of actionable information, too little and the feedback loop has failed, too much and you cannot see the problem so it needs tuning and adjusting slowly.

What does that mean to us in a non-manufacturing environment?

We have got pretty good at retrospectives and giving feedback locally, but feedback to management is largely absent.

The difficulty in many organizations is that senior management hide behind an open door policy. “Employees can talk to me any time, my door is always open”. It is very easy to pretend you are open to feedback but much harder to actually be open.

“Employees can talk to me at any time, my door is always open”

– the unapproachable manager

In many cases the open door is actually an invisible barricade: fear of retribution, fear of not being supported, fear of being ignored, fear of the messenger being shot. In many cases the fear is justified, but even when it isn’t, it doesn’t make the fear any less real to those with genuine feedback to share.

Creating Feedback Loops

Just like with Andon, this is feedback that should be sought and encouraged and your measure should be how frequently you are given constructive feedback from your employees, if you are challenged regularly and respond to it regularly then it is working, but if you are not getting regular feedback (from those outside your inner circle) then it is likely your “open door” is not that open.

Has someone in the last week given you critical feedback without being asked?

If on the occasions you do explicitly ask for feedback are you bombarded with hostile questions? Do the questions catch you by surprise? Do people seem dis-satisfied with your responses? Do you only ask for feedback when people quit? If yes then perhaps you are not asking for feedback often enough, or are not responding to the feedback you are getting.

Feedback is not passive

Feedback is generally not passive, you need to invite it, create forums where feedback is invited and expected, be open to the feedback and when you are not willing to change be prepared to explain yourself, and be prepared to repeat yourself.

It really comes down to whether you truly are a feedback culture, if you are you have to work for it.

Are you working too much?

Would it surprise you to learn that the person in your team or company that regularly works 60 hours a week (and makes sure everyone knows it) is very likely the least productive person on the team?

The person working 60 hours is likely the least productive person on the team.

And I don’t simply mean that productivity diminishes after 40 hours, I mean absolute total productive output is less from someone working 60 hours compared to someone working less than 40. The reality is that you would actually get more done by NOT working that time than you will working those extra hours.

This is a hard pill to swallow in a culture where ‘working hard’ is seen as a virtue, and the more hours I work the more virtuous I am. Long hours are often assumed to show commitment, dedication, loyalty. Maybe they do, but they don’t show productivity. If your company values those things above actual productivity then so be it, but understanding that it is about those attributes rather than productivity is a rather brutal fact to face. However, if you want to produce more and maintain high quality then you need to work less hours.

Parkinson’s Law

I am likely to offend a few hardworking people with this but my assessment of the findings of these studies is that is is a subconscious manifestation of Parkinson’s law. “Work expands so as to fill the time available for its completion” If I expect to work 60 hours then I’ll make my work last 60 hours.

Not just a European thing.

Europeans have a reputation for favoring reduced working hours and I’m sure it is an ongoing frustration to those in America that despite typically working more hours, American companies are consistently similarly or less productive than their European or Japanese counterparts despite the longer working hours and less vacation.
Interestingly, the study I’m quoting was actually a 12 year study by the Ford Motor Company of production in the USA.

Henry Ford… again.

Before I go into the study in more detail I’d like to go back in time and talk about the history of working hours and in particular Henry Ford.

If we go back 150 years there were campaigns all over the world to reduce the working week from 16 hour days, 6 days a week – 96 hours was considered a normal working week for many. Forward thinkers pushed for limiting the working day to 10 hours with breaks for food – a radical concept at the time.

Over time much of this became law despite fierce objection from industry, and by 1914 a normal working week was 9 hour days, 6 days a week. The pressure until then mostly came from humanitarian motives and agendas, and perhaps because of that, businesses took steps to prevent it taking hold, reducing pay in line with reduced hours so a reduction of 20% of hours came with a reduction of 20% in wages, this undermined the whole movement.

But then came Henry Ford. Ford created the 5 day working week, and a limit of 40 hours, but best of all he did it for profit and not for social good. At the time his factories worked 6 days and 9 hours a day (54 hours per week) just like everyone else, but he reduced working hours by 25% and instead of cutting wages he doubled them.

The productivity increases resulting from reducing hours were so significant that Henry Ford was attacked by the Wall Street Journal “To double the minimum wage, without regard to length of service, is to apply Biblical or spiritual principles where they do not belong.” going on to say “in his social endeavor he has committed blunders, if not crimes. They may return to plague him and the industry he represents, as well as organized society.”

51098603-f186b080bc53f64bbbd46208f7dec61a538631e4-s1200 — Henry Ford may have paid his workers a good wage, but it wasn’t out of charity — it was a good business decision that some say helped the middle class take off.

As you can imagine his competition was not happy either, paying more for “less hours” was maddening, but what really made them mad was that productivity jumped up massively. People simply couldn’t get their heads around the idea that less hours increased overall productivity. Slowly the competition copied Ford and got the same results, productivity went up for less hours, and eventually this carried across to office workers too. But even with those startling results and seemingly unquestionable evidence we stubbornly cling to the notion that more work is more productive.

I have written more about Henry Ford here.

Back to the present.

Last time the proposed reduction in hours was met with hostility but eventually it was seen as beneficial to everyone, especially the business owners that fought so hard against it. Once again studies show that reducing hours will increase overall productivity, and once again industry is pushing back on it in the face of the evidence. Challenging established culture with only facts is apparently not an easy battle.

Studies repeatedly show that long hours (40+ hour) results in reduced productivity, reduced quality and a less healthy lifestyle, and yet society still perceives the number of hours worked as a measure of hard work.
It is as if we see more value in the hours worked than the output of their labour. Someone that works 30 hours and produces 30 widgets is seen as less valuable than someone that works 60 hours and produces 25 widgets, because he works so much harder.

In our culture we see more value in the hours worked than we do in the output of our labour.

*In our culture we see more value in the hours worked than we do in the output of our labour.*

How did we get into such a mindset and how do we challenge that way of thinking. Surely we should reward the more productive and effective person? But we don’t, we reward the inefficient, we lift up Jane for being here at 7:30 PM finishing up her work and we criticize Anne who got all her work done and left at 4.

Part of the problem, especially in knowledge work, is that productivity is not easy to measure, just like quality and mistakes are hard to quantify. So rather than focusing on what is important we focus on what is easiest to measure – number of hours in the office, it is ironic that in our laziness in finding effective measures we end up working longer hours.

So what about overtime?

There is more bad news in the 12 year study by Ford they found that overtime (over 40 hours) results in reduced productivity in the long term. 40 hours is the very limit of maximum total productivity for a manual worker, this applies in both the short and long term.

Short term (less than 3 weeks) there are productivity gains for working beyond 40 hours, but after 3 weeks those gains disappear and actually reduce productivity afterwards. Even just 2 weeks of overtime and then stopping results in more loss in recovery than the gain made in the short term boost.

In other words, yes you can make a short-term gain using overtime to meet a deadline, but it will cost you more than you gain over the following weeks. So use it wisely and expect a recovery period.

Bad news for knowledge workers

For knowledge workers the news is worse still, the point of peak productivity is under 35 hours, and any hours above that are actually damaging, quality is markedly worse, mistakes and resulting corrections mean that productivity reduces dramatically when knowledge workers work beyond 35 hours, primarily because fatigue, stress and concentration have a profound impact on the quality rather than the quantity of work. We simply cannot be creative when tired, we struggle to solve problems come up with ideas or compose constructive discourse and debate, we are actually very likely making things worse not better and the clean up cost for knowledge work – bad decisions, introduced bugs, stifled creativity is far more damaging than not being there.

Worse news for Lawyers

Lawyers are typically in an unfortunately situation where they bill by the hour rather than by quality or even quantity of work. They are essentially encouraged by their business model to be unproductive (not consciously, it is just a product of the business model). Essentially a 60 hours week for them is the result of rewarding bad behavior, if you pay for time then they will take more time, pay for productivity and we become more productive. We also reward with status the hard working person that is willing to sacrifice his weekend for the appearance of working harder. More encouragement of bad behavior.

In ‘bill by the hour‘ work environments it is a challenge to change the model, productivity is very hard to measure – even if we see stress, mistakes and problems taking longer to solve. So it is hard to convince clients that working less is more productive, especially when it means charging more, and it becomes even harder when we can’t even convince ourselves because this notion is so culturally ingrained in us.

What now?

It is pretty simple really if you want to maximize the productivity of your teams, then reduce their maximum working hours to less than 32 hours (without reducing pay). They will work harder and more effectively for five 6-hours days than they will for 8 or 10-hour days. Your overall productivity will be higher.

Or work 8-hours, 4-days a week and you will find your teams will be more focused, more energized and and noticeably more creative. They will be happier, harder working and make less mistakes. They WILL get more done and it will be higher quality and more creative. They will also be refreshed have a happier home life.

Or we can ignore the brutal facts and continue to pretend that working long hours is a good thing, and praising the guy that works 60 hours a week and yet produces less than a part-time worker.

Note: my wife finds this particularly amusing as I work long hours and when I’m not working I’m blogging and when I’m not blogging I’m working on my game or running meet ups – there is a significant degree of hypocrisy and self-denial at play here.

Summary

Let’s not underestimate the difficulty here, this is a complex topic, and it is unlikely to be accepted any time soon, there is a lot of resistance – and that resistance is not based on facts or data. There are numerous studies on this topic, all with the same findings. Oddly enough despite the strong resistance to this idea, I couldn’t find a single study that didn’t find that overall productivity went down when hours went above 35-40 hours. There were even some studies that showed that regularly working 60 hours resulted in the same number of mistakes and level of performance as being drunk.

(If you see a study that contradicts this please share it, I spent quite a few hours on this but couldn’t fine one – and no, the contradiction has not escaped me.)

Decision Makers

Decision makers typically work longer hours and it is effectively their money, asking them to pay more for the perception of ‘less‘ work is never going to be an easy decision. We come from a puritan culture where we make a cultural assessment of someone based on effort not outcome. Deep-down we know this is not objective, I think we know this is wrong, but culture is not based in logic and changing culture will take more than facts and figures. It needs someone like Henry Ford to lead the way again.

References:

https://cs.stanford.edu/people/eroberts/cs201/projects/crunchmode/econ-crunch-mode.html

https://www.igda.org/page/crunchsixlessons