Microspeak: Tell Mode / Ask Mode

As a product nears release, the rate of change slows down, and along the way, the ship room goes through stages known as Tell Mode and Ask Mode.

In Tell Mode, any changes to the product do not require prior approval, but you are required to present your changes to the next ship room meeting and be prepared to explain and defend them. The purpose of this exercise is to get teams accustomed to the idea of having to present their changes to the ship room as a warm-up for Ask Mode. There is also the psychological aspect: If you have to present and defend your changes, you are going to be more careful about deciding which changes to make, how you will go about making them, and how thoroughly you're going to validate those changes. For example, if a bug could be fixed by applying a targeted fix or by rewriting the entire class, you are probably not going to choose to rewrite. (In theory, the ship room may reject your changes after the fact, and then you have to go back them out. But this is rare in practice. The ship room usually lets you off with a warning unless your transgression was particularly severe.)

The next stage of scrutiny is known as Ask Mode. In this stage, any proposed changes to the product must be presented to the ship room before they can be submitted. Rejection is more frequent here. Time has passed and the bug bar has gone up, and because it is easier to get forgiveness than permission.

Here is a more detailed explanation of how one team implements the two modes.

Note that there can be multiple levels of ship room. There may be a local feature team ship room, then a group-wide ship room, then a product-wide ship room, and it is not uncommon for each ship room to be in a different mode. For example, the local feature team ship room may be in Ask Mode, the group-wide ship room is in Tell Mode, and the product-wide ship room isn't looking at individual bugs yet. This means that when you want to make a change, you need to get permission from your local feature team, and then after you commit the change, you need to get forgiveness from the group ship room.

Comments (12)
  1. steven says:

    And before that, it is "Don't Ask, Don't Tell"?

  2. Matthew Smith says:

    In my 30-year career I've worked at three different places.  One was a three-person shop, where every project I worked on I was analyst/designer/architect/programmer/QA/documentation/trainer/support, one had 40 employees, and my current company employs about 100 people.  

    I always find it fascinating to read how large organizations organize themselves.  Thank you, Raymond.

  3. Jim says:

    There are many project methodologies plus all the clone ones. But in the end is the personality contest among the Business Owner, Development or engineers and QA. Whoever dominates the corporation dominates the process.

  4. Michael says:

    One other important aspect of Tell Mode is it gives the central shiproom an idea of what sort of things teams are fixing.  I.e., if most teams are still fixing very basic bugs in core scenarios, it probably means lock down needs to go on for a bit longer.

  5. benjamin says:

    @A: They talk about the build process in "Show Stopper!" Are you thinking of that, maybe?

  6. John Muller says:

    I have one issue with 'Bug Bar's

    Find a bug early, file it, response is "We'll fix it later."

    Later: "It doesn't met the bar."

    So all the little bugs live forever.

  7. A says:

    This is off-topic, but I once read a very interesting (and somewhat technical) description of the early Windows NT build process. I have been looking on and off for this site for several years. Does anyone have any ideas? These are *not* the one I'm talking about:



  8. cheong00 says:

    @John Muller: Technically the bugs won't live forever. Before they enter Ask mode, they'll perform tracklog cleanup.

    All "feature wish list" that won't make it will be marked for consideration in future version. All bugs that won't make it will be marked as "won't fix" or "by design", waiting to be filed again when next version is released.

  9. Chris Reynolds says:

    I've never worked in a place that had such a formal process so, like Matthew said, it is interesting to hear how it is done.  This post reminded me of the fourstones piece:


  10. Boris says:

    @John Muller: in my environment there is no "later". It is fixed as soon as any higher-priority bugs are fixed, and if it isn't important enough to go into a particular release, it is merged into the branch for the next one.

  11. smf says:


    You say there is no "later" and then describe a process that makes you fix them "later".

    "@John Muller: in my environment there is no "later". It is fixed as soon as any higher-priority bugs are fixed, and if it isn't important enough to go into a particular release, it is merged into the branch for the next one."

    It's pretty rare to have time to fix all bugs. I was in a similar position until the boss retired and the new guy was a sociopath, who decided to "turn the company around". He did in a way, the cost of everything went up and software quality went down.

  12. Boris says:

    @smf: you didn't compare my "later" with John Muller's. He argued that "all the little bugs live forever", as a result of being filed for later fixing. My point was that they need not stick around indefinitely, if they are fixed as soon as possible in the branch for the next release.

Comments are closed.

Skip to main content