InfoQ

News

Death of Hybrid Camry Chief Engineer is Ruled Overwork

Posted by Mark Levison on Jul 17, 2008 01:00 AM

Community
Agile
Topics
Leadership,
Careers
Tags
Toyota Production System,
Lean

Last month the Japanese labor board ruled that the death of the Chief Engineer on the Camry Hybrid project was ‘karoshi’ (death by over work). In his last few months he worked more than 80 hrs of overtime a month. He died of a heart attack only day before he was due to fly to the Detroit Auto Show.

This story raised a number of interesting issues about what we can learn from Toyota, sustainable effort and why we develop software.

Joe Little points out that “Lean has a principle of not over taxing the system”. He goes on to ask is excessive overtime a fundamental part of Lean at Toyota or is this isolated to a specific group? Finally he reminds us that even though Lean comes from Toyota they are not perfect. Even so we can still learn from them and other lean practitioners.

Robin Dymond says:

I thought this was sad but interesting. The lean product development model that Toyota uses rolls the product owner, scrum master, and technical lead into one role, the chief engineer. Mary Poppendeick and I have been talking about how this leadership model might apply in software development too. The issue I have is that the Product Owner is already an overloaded role and an achilles heel for a scrum team. Adding the additional technical and process responsibilities has always struck me as being much too heroic, and not sustainable. It looks like that this may be the case.

Mary, author of Lean Software Development, replies, recalling her time as a Product Champion at 3M:

on good teams, overload/overtime was something that the team members did to themselves due to their passion for the product they were developing.  I also do not see the product champion as an all-knowing all-powerful person - just a person with a vision that can excite passion in a team.  When I was product champion, I certainly never could do all of the things expected of even a product owner all by myself, but I did know how to get the right people on the team and get them engaged in the goal – so all of the necessary technical and marketing things happened.

She goes on to say that any role can become overwhelming as they become a laundry list of things to do instead of a checklist of responsibilities shared with the team. 

Finally in response to the problems of hard deadlines and fixed features sets imposed by management Mary comments:

Perhaps the biggest problem that drives the symptoms mentioned is that software seems for some reason to get divorced from the overall system and the overall business purpose of that system.  Then of course, no one can get passionate about it.  We have to stop developing software and start making systems that serve important purposes, so that team members can make valid judgments about how important the schedule really is – how important that difficult feature really is – what test strategy is best for the long run – where the true cost of the system lies. 

Related Sponsor

VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.

9 comments

Reply

Passion is great, but don't burn out by Jim Leonardo Posted Jul 17, 2008 12:16 PM
Re: Passion is great, but don't burn out by Mark Levison Posted Jul 17, 2008 1:48 PM
Re: Passion is great, but don't burn out by Dave Rooney Posted Jul 18, 2008 9:01 AM
Re: Passion is great, but don't burn out by Mark Levison Posted Jul 18, 2008 10:25 AM
Re: Passion is great, but don't burn out by Dave Rooney Posted Jul 18, 2008 10:42 AM
Re: Passion is great, but don't burn out by asy ronen Posted Jul 19, 2008 2:53 AM
Re: Passion is great, but don't burn out by Deborah Hartmann Posted Jul 19, 2008 8:50 AM
Re: Passion is great, but don't burn out by asy ronen Posted Jul 19, 2008 6:43 PM
Hmm. by Zubin Wadia Posted Jul 19, 2008 1:12 PM
  1. Back to top

    Passion is great, but don't burn out

    Jul 17, 2008 12:16 PM by Jim Leonardo

    So this is the classic case of the lynchpin guy getting hit by the proverbial bus. Noone ever wants to talk about it, but over-specialization/over-concentration can be a disaster for a project when someone leaves, or in this case, worse.

    One person doing too much is also just warning sign that team work on your project is poor. Why is (s)he doing so much more than the others? Is it because they are territorial, or is it because they're terrified?

    While its great to see passion, it's like marriage. Passion can only carry you for so long if you try to go full throttle all the time. Sooner or later, your energy level can't be sustained anymore, and if you try, you burn out. You end up hating the work you used to love. Moderation is far better... that's the key to sustainability.

    This is just one of the reasons you need to monitor the hours people are truly putting in to ensure it's because they want to be working those hours rather than it's because they feel pressured to work those hours. Overtime is inevitable, but that doesn't mean it needs to be destructive. Quality suffers, your people suffer, and inevitably, you suffer as a consequence.

  2. Back to top

    Re: Passion is great, but don't burn out

    Jul 17, 2008 1:48 PM by Mark Levison

    Jim - I agree. I think the hard part is spotting someone who is pushing too much and too hard.

  3. Back to top

    Re: Passion is great, but don't burn out

    Jul 18, 2008 9:01 AM by Dave Rooney

    His timesheet might have been a clue!

  4. Back to top

    Re: Passion is great, but don't burn out

    Jul 18, 2008 10:25 AM by Mark Levison

    True Dave - but that assumes two things the organization keeps time sheets and that he was honest when writing in it.

    In some organizations that don't pay for overtime employees don't see the point in filling out the time sheet with their real hours.

  5. Back to top

    Re: Passion is great, but don't burn out

    Jul 18, 2008 10:42 AM by Dave Rooney

    In his last few months he worked more than 80 hrs of overtime a month.
    Someone was watching his hours. I'm just sayin'...

  6. Back to top

    Re: Passion is great, but don't burn out

    Jul 19, 2008 2:53 AM by asy ronen

    Jim

    I understand where you're coming from but I think that it's not easy spotting the point in which "positive" enthusiasm turns into compulsive behavior.

    speaking as a "passionate" guy, I can tell you that trying to restrain my self from over working always feels like trying to artificially convince myself that i care less, furthermore we all want to succeed and it's very easy to say to your self - work harder and you will have more success!

    another angel is that because software development is part art form it's easy to relate to your work on an emotional level which blurs the boundaries that should exist between work and personal life, making it really hard to find the right balance.

    I think that at the end of the day finding the right balance is something that everyone should do for him/her self, it's not something that your employer can impose on you and the most important thing to remember is that "karoshi" is not an option.

    Asy.

  7. Back to top

    Re: Passion is great, but don't burn out

    Jul 19, 2008 8:50 AM by Deborah Hartmann

    Asy, your comment made me laugh: "remember is that "karoshi" is not an option," because on our first agile team, we had a mascot sock monkey called Karoshi - and he got messed up in all the worst ways. He literally "hit the wall" many times, got hung up in the rafters and one morning was discovered in the paper shredder. I had never thought of these destructive activities in the context of his name, before. :-)

  8. Back to top

    Hmm.

    Jul 19, 2008 1:12 PM by Zubin Wadia

    Isn't the chief engineer's role outlined in the "Toyota Way" similar to a surgical team? One quarterback, the others are instruments in the offensive choreography?

    Cheers,

    Zubin Wadia

    CTO

    www.imagework.com

    "Business Acceleration through Process Automation."

  9. Back to top

    Re: Passion is great, but don't burn out

    Jul 19, 2008 6:43 PM by asy ronen

    I always knew that agile can bring the worst out of people ;-)
    seriously though, I'm happy to hear that I made you lough ...

Exclusive Content

Using Ruby Fibers for Async I/O: NeverBlock and Revactor

Ruby 1.9's Fibers and non-blocking I/O are getting more attention - we talked to Mohammad A. Ali of the NeverBlock project and Tony Arcieri of the Revactor project.

Agile and Beyond - The Power of Aspirational Teams

Tim Mackinnon talks about the aspirations behind the Agile principles and practices, the desire to become efficient, to write quality code which does not end up being thrown away.

Concurrency: Past and Present

Brian Goetz discusses the difficulties of creating multithreaded programs correctly, incorrect synchronization, race conditions, deadlock, STM, concurrency, alternatives to threads, Erlang, Scala.

ActionScript 3 for Java Programmers

Often the hardest part of changing technologies is language syntax differences. This new article provides Java developers with a transition guide to Actionscript which forms the foundation of Flex.

Neal Ford On Programming Languages and Platforms

Neal Ford talks about having multiple languages running on one of the two major platforms: Java and .NET. He also presents the advantages offered by Ruby compared to static languages like Java or C#.

Future Directions for Agile

David Anderson talks about the history of Agile, the current status of it and his vision for the future. The role of Agile consists in finding ways to implement its principles.

Nick Sieger on JRuby

Nick Sieger talks about the future of JRuby, Java Integration, and his work on JEE deployment tools for Ruby on Rails like Warbler.

Rustan Leino and Mike Barnett on Spec#

Rustan Leino and Mike Barnett of Microsoft Research discuss the technology in Spec# and its futures.