Lydia was a kick-butt personal secretary - one of the last of a dying breed. Dr.

. Sullivan, her boss, was a world-famous plastic

surgeon, who juggled a busy patient load, training residents and research with his three small children. One day, she posted a sign
on her desk: Procrastination on your part does not constitute an emergency on my part.
Why did Lydia post such a sign? Because this busy doctor was driving her crazy with last-minute requests that kept her from
running his ofce the way it needed to be run, and it was getting out of hand. He was a world-class Flow Interrupter.
What is a Flow Interrupter?
Flow Interrupters continuously interrupt the ow of work for the people around them. Everyone has truly urgent requests every
once in a while, but Flow Interrupters see everything as urgent, and the people around them have a difcult time getting anything
done. Managers have the authority to disrupt the ow of work for people whom they supervise, but you can also act this way
towards peers, and sometimes even towards your own boss, without realizing the impact that this can have.
Some people are occasional Flow Interrupters. They can leave their teams alone if things are going well, but the moment something
goes wrong, they go into micromanagement mode. They demand constant updates, emergency meetings, and extra reports - all
things that make it harder to solve the real problems.
Product development is rife with opportunities to interrupt the ow - especially if things are not going well. Ask yourself: are your
engineers and scientists more likely to solve technical issues if you are taking up all their time with status updates? Are they more
likely to think their way out of the box youre all stuck in if you give them time and space to think clearly?
This is one of those management behaviors that falls into the category of: We do this because we believe the constant pressure
will make us faster, but it actually slows us down even more. Take it from a twenty year veteran in product development: if your
developers product is in crisis mode, they are already putting themselves under a tremendous amount of pressure. They dont need
anyone to make it worse. Unfortunately, some management behaviors interrupt the ow just when the engineers need it the most.
Six Management Behaviors that Interrupt the Flow
How often do you nd yourself interrupting the ow by doing things like this?
Dropping by peoples desks for just a minute?
Giving people last-minute requests that didnt have to be so last minute?
Getting irritated when people let your calls go to voicemail or dont reply to email
within an hour?
Requesting impromptu status updates - or even worse - daily status meetings,
especially during a crisis?
Failing to complete your own work before the last responsible moment, sending your
downstream partners into overload and causing others to scramble to avoid being late?
Expecting your teams to keep you informed using formats - such as lengthy reports - that create no value for
your customers.
These are all things that may seem to have a small impact but add up to a lot of unproductive time for your colleagues.
Are You a Flow Interrupter?
Six Management Behaviors that Slow Down Product Development
2013 Whittier Consulting Group, Inc. All Rights Reserved.
Key Takeaways
Flow interruptions cost time and money in product development
Six common management behaviors interrupt the ow of work.
Learn how to work with the ow instead of interrupt it - especially if you have a product
development program in crisis mode.
rself: are your
engineers and scientists more likely to solve technical issues if you are taking up all their time with status updates? Are t e with status updates? Are they more
likely to think their way out of the box youre all stuck in if you give them time and space to think clearly?
Flow Interruptions Cost Time and Money
When engineers or software developers get interrupted, it can take as long as fteen minutes
for them to get back to where they were before the interruption. If you are interrupting people
eight times a day, youve just lost two whole hours of team productivity! Over a week, thats
more than a day - more than 20% of one highly-paid professionals time during the week.
Some types of lab work require even bigger blocks of uninterrupted time for the engineers
or scientists to make any headway. If your engineers and scientists spend so much time in
meetings or writing status updates that they never get that time, you are not allowing them to
do the work that you hired them to do, and your product development performance will suffer.
What if you redirected all that time and energy to improving the ow rather than interrupting
it? How much further ahead would you be?
What can you do instead to improve the ow of work?
Heres what you can do instead:
Make sure that your staff meetings are productive and scheduled to avoid most team members most productive times. When
I was a software developer, I disliked Monday morning meetings because that was my most productive time all week!
Ask each of your team members to tell you when its best for you to drop by, and when they should be left alone. Some
people will prefer that you bring them requests rst thing in the morning, and others will ask you to protect this time because its
their most productive. Some will want you to hold things until the end of the day. Every person has different energy cycles, and
if you can work with those, then you will minimize the impact of your disruptions.
Give effective support to people who are working in crisis mode. That does not mean a daily meeting with you, unless you have
some constructive way to help! If they just give status updates to you, then you are wasting their precious time!
Schedule status updates on a regular basis, and make them as easy as possible for the team to prepare. You should not be the
customer they have to impress with PowerPoint pyrotechnics! That just takes time away from the project itself.
Understand the Last Responsible Moment for your own work, especially decisions. If time-to-market is important to you, then
you must do whatever you can to make sure that you never get on the Critical Path for your team. When the Last Responsible
Moment arrives for a decision that you own, you must be prepared to make the call. When the Last Responsible Moment passes
for others decisions, youve lost your chance to second-guess them without creating turmoil.
Ask yourself, Do I do these things because I dont trust my people to do the right thing or work hard enough? If not, what
does that say about me as a manager? If you are constantly interrupting, others may interpret that as a lack of trust in their ability
to properly prioritize.
But its not about trust - its about keeping in touch with my team members!
Every manager needs to feel like hes an important part of the team, and especially when theres a problem, we want to be seen as
someone whos taking action.
Thats not a bad impulse. Its a good one - it means that you care.
But there are healthier ways to express it that will lead to better results down the road, and you will get better performance from
your people if you show them that you respect their time and the natural ow of their work. If you learn about the natural ow of
work with your teams and learn how to work with it, you will sustain the ow rather than interrupt it.
Learn how to work with the ow instead of interrupt it
The way to stop interrupting the ow is to understand and work with your teams natural rhythms, keep status reports as quick and
easy as possible, and ensure that you do whatever you need to do to stay out of the way.
After Lydia posted her sign, Dr. Sullivan took her out for coffee to learn more about why she felt the need for the sign. Dr. Sullivan
realized that he was frittering away Lydias most productive time with all of these last minute requests, and that was costing him real
money since the ofce wasnt running efciently. They began meeting once a day right after her lunch to coordinate their work.
Dr. Sullivan is still a world-class plastic surgeon, and now he is a world-class Flow Sustainer.
www.whittierconsulting.com
e!erences. Poppehdieck, Mary. Leah So!Iware DevelopmehI: ah Agile 1oolkiI.
Addisoh-Wessley, 2003, pp.1-13
In our list of activities, a few items are always waste status meetinqs, siqnoffs, supplier neqotiations, sales materials The act of
preparinq the business case has some elements that create value (customer research, and others that dont (preparinq a snazzy pre
sentation for the board of directors, The activities that contribute directly to product delivery reouirements dennition, innova
tion, desiqn, toolinq add value to the extent that they either qenerate or utilize our best available lnowledqe about the customer,
the marlet, technoloqy and process capabilities
No one claims that all waste can or should be eliminated lven Chno recoqnized that some waste is necessary waste Im not suq
qestinq that a team eliminate the step of preparinq the business case entirely As a shareholder, that due diliqence has value to me
lowever, a lean orqanization aclnowledqes that the customer doesnt care about the sales forecast or how many siqnatures it tool
to qet the fundinq for a pilot release A lean orqanization streamlines those processes as much as possible
5ome WasIe is Necessary
Common IndicaIors o! WasIe in ProducI DeveIopmenI
I! you're goihg ouI Io look !or wasIe ih producI developmehI, here are some Ihihgs Io look !or:
The vasIe o! reinvenIion. Leah producI developmehI Ieams appreciaIe Ihe value o! khowledge, ahd ehsures IhaI iIs
khowledge is easy Io capIure, easy Io !hd ahd always used Io make decisiohs.
The vasIe o! excess requiremenIs. Leah producI developmehI Ieams recoghize IhaI every exIra !eaIure musI be desighed,
produced, maihIaihed ahd supporIed - ahd cusIomers pay Ihe price ih greaIer complexiIy ahd greaIer risk o! !ailure.
The vasIe o! overIoaded resources. Leah producI developmehI Ieams khow IhaI overloadihg resources makes Ihem slower
ahd less !exible, ahd IhaI Iask-swiIchihg cosIs ehgiheers valuable Iime.
The vasIe o! Ihrov-avay design. Leah producI developmehI Ieams sIrive Io uhdersIahd ahd Iheh mahage Iheir desighs
as ah ihIegraIed sysIem, so IhaI Ihey cah !ocus ihhovaIioh oh areas IhaI improve Ihe markeI per!ormahce o! Iheir ehIire
porI!olio o! producIs.
The vasIe o! ine!!ecIive risk managemenI. Leah producI developmehI Ieams ackhowledge Ihe uhcer-
IaihIy ih producI developmehI, ahd develop plahs Io mahage iI.
The vasIe o! vaIer!aII deveIopmenI. Leah producI developmehI Ieams do work wheh iI makes
Ihe mosI sehse Io do iI, raIher Ihah allowihg rigid processes or orgahizaIiohal bouhdaries Io
dicIaIe work!ow.
The vasIe o! unproducIive meeIings. Leah producI developmehI Ieams value Iheir Iime, ahd use good
meeIihg mahagemehI Io spehd Ihe Iime Ihey have IogeIher !or solvihg problems or makihg decisiohs.
WasIe mahi!esIs iIsel! ih oIher ways ih producI developmehI, buI Ihese Iehd Io be Ihe heavy-hiIIers,
ahd Ihey are a good place Io sIarI lookihg. Lveh small chahges here cah have a big impacI.
A NoIe o! CauIion
Its not always easy to lnow whether or not a qiven activity is value creatinq, necessary waste or unnecessary waste We cannot rely
upon descriptions of waste that we nnd in lean Manufacturinq quidebools
keworl is a qood example In manufacturinq, reworl is almost always an indicator of unnecessary waste lut the principle of continu
ous improvement assumes that a lean Manufacturinq qroup will constantly reworl their processes and toolinq to eliminate waste and
improve now The product desiqn has much more in common with the manufacturinq process than it does with the product itself
A few hours of reworl to incorporate new lnowledqe into a desiqn can create value Some reworl, such as correctinq calculation er
rors, is wasteful Sometimes reworl can have ripple effects that cancel out the potential value lean product development teams can see
the difference between reworl that creates value, and reworl that does not They lnow how to avoid the wasteful lind of reworl, and
how to use the valuable lind as a tool to deliver more value than a sinqle pass desiqn process can deliver
When engineers or software developers get interrupted, it can take as long as fteen minutes
for them to get back to where they were before the interruption. If you are interrupting people
or scientists to make any headway. If your engineers and scientists spend so much time in
meetings or writing status updates that they never get that time, you are not allowing them to
do the work that you hired them to do, and your product development performance will suffer