Whenever there is a coordination problem, somebody says, "Hey, let’s create a process!"

Date:September 5, 2007 / year-entry #330
Orig Link:https://blogs.msdn.microsoft.com/oldnewthing/20070905-00/?p=25263
Comments:    36
Summary:Whenever there is a coordination problem, somebody says, "Hey, let's create a process." Now you have two coordination problems. I see this over and over, and paradoxically the people who create a process for managing a coordinating problem come off looking like proactive problem-solvers who get ahead of the problem. They're the go-getters, the people...

Whenever there is a coordination problem, somebody says, "Hey, let's create a process." Now you have two coordination problems.

I see this over and over, and paradoxically the people who create a process for managing a coordinating problem come off looking like proactive problem-solvers who get ahead of the problem. They're the go-getters, the people who look at each problem as an opportunity for continuous improvement. All that great management buzzword stuff.

It doesn't matter whether or not the process actually works, because failure is an orphan, and besides, nobody follows up a year later to see whether your process actually improved things or whether it was abandoned six weeks after roll-out. You get the credit for proposing the process in the first place.

Consider this problem at a hypothetical toy company: Some rumors have started that one of their toy cars is dangerous because of a wiring flaw that can result in excessive heat and possible fire. (It doesn't matter what the crisis is. I just made up something vaguely plausible.) Employees all over the company are getting email from their relatives asking about the toys, but the employees don't know what the story is either. Presumably, the safety department is investigating the problem and providing guidance to the PR and marketing departments so they can prepare a public response, and if there really is a problem, they're working with the product recall team to organize how the recall will be carried out, and they're working with the product engineering team to figure out what changes need to be made to the product to avoid the problem. In other words, the safety department is up to their ears in crisis.

A employee from the dolls department, whose brother asked him about this toy car problem, can't find any information on the status of this issue and sends email to the "Employee Issues" alias, and a dozen people chime in with "Yes, please, we would like this information, I want to know what I can tell my brother and everybody else who is asking me about it. I might even post it on my blog so I can try to counteract some of the out-of-control rumors that are out there."

A half hour later, somebody from the safety department responds, "Yes, we know about this, we're working on it. Please don't say anything publicly since we're still investigating."

Somebody watching the saga unfold proposes a process by which employees can be kept up to date on the status of these types of emergent crises.

  • Create an internal web site that contains a list of all current emergencies at the company, their status, what information is speculation and what information is solid, which pieces of that information can be revealed to the public, and recommended phrasing for the information when it is revealed.
  • Whenever there is an emergency, the people responsible for responding to the emergency update the web site with the status of the investigation and the other information listed above.

This is the wrong solution to the problem.

The reason why this is the wrong solution is that it suffers from the classic "Create work for somebody else" problem. The people who benefit from this site are not the same people who would make the site useful. This doesn't give the people who make the site useful much incentive to do so. They're busy dealing with the emergency. They don't want to waste the time of one of their valuable investigators to do "internal PR".

This scenario repeats itself on a less dramatic scale with various types of inter-group coordination problems. One group wants to be kept advised of the progress of another group for whatever reason. But if the second group doesn't need the first group for anything, they have no incentive to keep the first group informed.

For example, suppose the first team provides an interface that the second team uses, and the first team decides that they need to redesign the interface for whatever reason. During the transition, the first team provides both interfaces so that the second team can transition from the old to the new, with the request that the second team let them know when they have finished transitioning to the new interface so they can remove support for the old one.

Unless the first team keeps on top of things, the second team will probably forget to tell the first team when they have completed the transition, or they may even forget to transition to the new interface at all! After all, the old interface still works.

In this case, the traditional way of making the second team care is to file a bug against them saying, "Stop using the old interface." That way, it shows up in their bug statistics as a reminder, and when they actually do the work, they can resolve the bug back to the first team. But you can imagine a scenario where the information the first team wants is more of a continuous nature rather than a single event. (Since bugs track single events.)

Comments (36)
  1. BA says:

    Wow. This one really nails our whole organization.

  2. Karellen says:

    OK, that was confusing. I just got the following error –

    brain:3: Parse error at paragraph 3 – "it was abandoned six weeks after roll-out". Ambiguous phrasing "process". Try "process (business)" instead of "process (computing)" and redo from start.

  3. Yuhong Bao says:

    That is just funny.

  4. John says:

    Yeah.  Even half-way through I was still thinking about using a (computing) process to coordinate access to multiple resources or tasks.

  5. e.thermal says:

    I agree these "information" systems are only as good as the information people are willing to put into them.  More often then not they really aren’t all that interested or have the time to maintain these systems.

  6. Heh… I thought this was going to be a riff on Larry regarding craplets.


  7. Tom says:

    Everywhere I’ve worked, the normal response to the recall issue is "Do not talk to the press; refer the person to PR".  In such a case, the employee gets to hear the response at the same time as the rest of the public.

    Not to get too far off topic, though, the "let’s create a process" can be a problem.  Usually it results from someone not understanding or not knowing about the current process.  In your second example, submitting a bug report is a modification of an existing process that I can agree with.  But that only works if the first team knows all of their users.  It may still be necessary for the first team to "advertise" — that is, have a public location (or mailing list) so that people can be notified of changes to the interface.  Yes, this is more work, but it could just be a simple distribution list in Outlook or a page in SharePoint or a blog entry that people can check on to be notified of updates to the interface.

  8. poochner says:

    Don’t forget to create the new process by committee.  A new steering committee, created just for the purpose of solving this one specific issue, which will be disbanded once they’ve put that process in place.  Of course, that’s part of why the process dies in six weeks–the people who came up with it aren’t around as a body any more.  Yes, they’ve all been volunteered for some other panel that will be working on some other issue.

  9. Ken says:

    heh – been there, done that, sat on the panel. This entry really made me smile, thank you.

    One method I like (yes, it doesn’t work in all situations) for the last scenario described is where team1 says something like:

    Interface 2.0 is now available

    Interface 1.0 will be removed on today + N weeks/days

    Some variations of that are to have messages inserted into the various methods of Interface 1.0 that print things like "Using obsolete interface method. You should be using Interface 2.0::foo. This interface will expire and be removed on $date"

    A bit of work upfront, that done the proper way can provide some incentive to team2 to update to the new interface.

  10. NoName says:

    So, what is the solution then?  Not to do anything to keep those people informed?

  11. Andrew says:

    Well said.  In my experience, Continuous Improvement tends to transfer the burden to where it’s least visible.  This apparently is a "big win" for management who now don’t have to be aware of the failing process, since it’s failing out of sight.

  12. Mikkin says:

    Sing it Raymond.

  13. buzz says:

    The reason why this is the wrong solution is that it suffers from the classic "Create work for somebody else" problem. Η παθογένεια της οργάνωσης α λα γκρεκ, νομίζω.

  14. Cooney says:

    Where I work, we handle some of this stuff through annoucne mail lists. Of course, finding all the people who use our stuff can be an adventure, as is stupid tricks we play to make them talk to us before using the interface.

  15. David Walker says:

    Poochner: Dilbert reminds us that the steering committe members need to have a pre-meeting to coordinate what will happen at the first committee meeting.

  16. When I first saw the title, I thought you were talking about concurrent programming, and I was about to tear you a new one.  Thankfully that will not be necessary.  :)

  17. Nusi says:

    … and I was thinking of splwow64

  18. Jack Mathews says:

    This is an extraordinarily insightful post.

  19. fschwiet says:

    This is not an insightful process, its the ramblings of a very frustrated worker.  One problem is that Microsoft is it is full of workers grumbling about process.  Few of those grumblers will progress beyond victimhood, and thats really holding the company back.

    I agree with some of the points (ie, people shouldn’t be rewarded just for creating process– thats not "Results Oriented").  But there’s no real conclusion on how to fix the problem- you can’t just blame process and call it done.

  20. Mr Cranky says:

    This is nothing compared to national politics.  All the Democrat* candidates are announcing solutions to the "subprime mortgage crisis".  None of which would do anything except cause more problems.

    *The Republicans are probably just slower on the uptake because the big bankers haven’t told them what they can propose yet.

  21. Igor says:

    Sorry for OT but I have to…

    Shame on your company Raymond:


    This tool was of great help to admins of SOHO networks with slow Internet connections and now it is gone.

    Do me a favor and please don’t blog about security issues anymore. Your company obviously doesn’t care if we update our Windows’ or not.

    [Thanks for letting me know that I can’t blog about security issues any more. Are there other topics? Perhaps we should create a process so you can mark a topic as “non-bloggable”. -Raymond]
  22. sandman says:

    Looks like you’ve just described public office.

    In the uk at least, the job ads for public sector staff look like jobs ads for people to handle such processes.

    The number co-ordinators jobs which seem to be advertised for is immense. What is worse my reading of is it make matter worse not better.

    Instead of n parties arguing over the problem-space you now have n+1.

    Like a previous poster I thought you were going to ranting about bad program design – have you seen the analogous problem at Microsoft or anywhere you may have worked?

  23. Name required says:

    (It doesn’t matter what the crisis is. I just made up something vaguely plausible.)

    Lead in the paint might be more topical. Probably get you into legal trouble as well ;)

  24. Dean Harding says:

    Do me a favor and please don’t blog about security issues anymore.

    Yeah because Raymond has any influence at all on Microsoft Legal… why don’t you THINK before posting?

  25. AndyB says:

    Yeah because Raymond has any influence at all on Microsoft Legal…

    Well, what MS needs is a process for facilitiating communication between MS bloggers and the Legal department.. :-)

  26. victim says:

    I used to work at a company that was going through a long term bad spot of missed deadlines due to some poor decisions.  Every week a new process was introduced to fix a problem that was identified last week.  Of course, no process could fix the over-arching problem, only time and hard work.

    The constant introduction of processes was a big distraction and frankly an insult to the people who were working hard to get out of the situation.  Half those people eventually left.

    None of the processes sounded like a bad idea that could be argued against, but taken in whole it was a mess that wasted precious time.

  27. programmer says:

    I appreciate your blogging about process management, would like to read more from you on this topic.

    I hope I am not alone on this.

  28. dbt says:

    victim, that sounds familiar.  "Your project is behind schedule.  Let’s hold daily status meetings until we’re back on schedule."

    Today’s meeting topic: how all these meetings are preventing us from catching up to the schedule.

  29. Ethan says:

    So, what is the right thing to do in these cases?

    [Let the safety team do their job. When they have something to release to the public, they will send it to the PR department. -Raymond]
  30. Hieronymous coward says:

    “Let the safety team do their job.”

    How do I know they are doing their job? I have no information from them, and I have customers screaming for information.

    Possibly the other team is up to its eyeballs in alligators. Possibly they are all playing Tetris. I’m not sure which.

    I don’t know of a good universal solution to this problem, apart from hire good people, hire good managers, etc.

    [If you truly have such little faith in your safety team (which is another problem in itself), you can send them email saying, “Hey, have you heard of this?” They’ll probably reply, “Yes, we’ve been working on it nonstop since yesterday.” -Raymond]
  31. mikey says:

    it does make sense to have this the ‘safety’ team update internal staff though.

    at our company it would be done in the weekly meeting. at larger companies it makes sense to use technology to express the status. it of course doesn’t make a great deal of sense to stop progress on the fix just to get it done, but the concept in general is appropriate. perhaps many companies get the implementation wrong; but that is bad management for you.

  32. Roz says:

    <i>"I agree with some of the points (ie, people shouldn’t be rewarded just for creating process– thats not "Results Oriented").  But there’s no real conclusion on how to fix the problem- you can’t just blame process and call it done."</i>

    Yep, bad processes are bad. But that doesn’t mean coordination problems don’t need to be fixed.

    The problem is that, as an organization, we don’t construct ways to meet the ongoing coordination and communication needs of a business where interface between departments and with the public is crucial to getting the work done well. So the coordination snafu seems to take everyone by surprise. Dumb, yes. But building the organizational infrastructure never seems like a top priority, especially when the leaders’ talents are primarily technical rather than strategic.

    So set up the wiki and start using it. Run the liability issues through legal before there’s a legal issue putting pressure on the situation. Think ahead about what to do in a crisis. Is it important for the people who might get the calls to have good information? If not, then don’t spend time on it, but if it is, then recognize it and put something in place that’s self-maintaining and does the job.

  33. Matt says:

    I thought the implication here was that a wiki-like structure would fail, since the relevant departments will be far more interested in dealing with the problem than actually telling other people about how they are dealing with the problem.

  34. Neel. says:

    I worked in a company and they were implementing some standard and there was HUGE discussion on processes and processes and processes.. So standard instructor asked.. what’s the advantage of processes? I said "Processes are indpendent of people" And then standard instructor asked "what’s the disadvantage of processes?" I shouted as much possible "Processes are indpendent of people"…

    Jeez, let me do my job!! Provide me an assistant who will process all processses..


Comments are closed.

*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

<-- Back to Old New Thing Archive Index