Q&A on the Book Timing Is Almost Everything

Executives can and should get involved with the way that software is being developed. In his book Timing is Almost Everything, Roland Racko shows how  you can increase software success by using a "management by query" executive style in the early stages of software development initiatives to influence how teams think and behave.

InfoQ readers can download a sample of Timing is Almost Everything. 

InfoQ interviewed Roland Racko about why and how executives can get involved with and influence the way that software is being developed, what made him decide to choose Essence and use jargon free questions, how to deal with situations where people in organizations feel overloaded, what developers and tech leads can do to gain support from managers for doing improvements, and how executives can work with middle management to get buy in for improvement.

InfoQ: What made you decide to write this book?

Roland Racko: During those periods when I have consulted for companies, my observation was that managers and teams solved software project problems by shoveling darkness around in rooms where the lights were off. Another way of saying this is that they attempted to solve the problem at the level of the problem. Yes, they apparently resolved the symptoms. But they did so without examining what made the problem occur in the first place. So I became determined to write a book which gave obviously useful tools but also hidden side effects of heading off problems before they manifested. I decided to write a book that, if followed, made stealth improvements in a company's software development process by adding light to the room.

InfoQ: For whom is this book intended?

Racko: On the surface the book's description says it's written for startup entrepreneurs: people who have a lot of money to hire programmers to make their software whizbang, but are less likely to have both the vocabulary and experience to corral the excitement of a new startup software team. However, in practice, the material of the book is useful for any manager of a software team, startup or otherwise, as many of the purchasers of the book have themselves noted in their online reviews.

InfoQ: Why should executives get involved with the way that software is being developed? Can't they leave it to the technical staff?

Racko: An executive cannot "not get involved." As an example, suppose the executive asks a question like "how complete is the system?" And suppose he gets the answer "95% done, boss." If he accepts the answer as stated and walks away, he has just gotten involved in a super high risk situation that will soon need his direct intervention. Why? Because 95% will be stated over and over again for the next four months as the project goes into overrun. That overrun will require his direct intervention to apply appropriate new resources. Note that an executive typically would not entirely "leave to staff" other corporate arenas like sales, distribution, manufacturing, or other more traditional areas of corporate expertise because he has a vision about those and a sense of what quality really is in those areas. What makes software exempt from that kind of visionary oversight?

Of course, in very large companies the "executive" might not be the CEO. It could be the CIO, CTO, lead architect or some other lower down person. In any case, the book does not propose total micromanagement of the software development process from uppermost levels. It proposes a very selective, targeted and time sensitive intervention at specific points in the software development total process.

InfoQ: In the book you stated that often executives react late to problems. Why is that?

Racko: They aren't actually reacting late to the problem as much as they are reacting in a quite timely fashion to the late trail of chaos that the problem leaves in its wake. They are largely previously unaware of the problem's initial inception during that reaction. Thus, to the outside world's view, they appear to be reacting "late." When an executive can learn from the book how to intervene at the right points in the project in such a way as to prevent problem inception, to the outside view they appear to be reacting as total geniuses.

InfoQ: What can happen if they use their influence to correct problems?

Racko: An executive directive designed to influence the team has two components – timing and magnitude: when the influence is delivered, and the strength of that delivery. Part 1 of the book describes jargon-free questions, along with expected team answers, that let the executive ascertain if the team is on board with executive goals. Part 1 shows how to time the questions to preempt certain commonly occurring software development failure modes. Part 2 of the book shows the executive how to modulate the strength behind those questions to get the desired answers. Depending on how an executive uses these two components, there are three possibilities that can happen – nothing, something bad, or something good.

Generally "nothing" happens because previous interventions by the executive lacked the kind of strength outlined in Part 2. When there is perfunctory follow through, the software team will react to a new executive intervention with the attitude of "we don't have to do what they say" because they experience the executive behavior as being low strength, wishy-washy or uninvolved. The executive influence is perceived as one that exhibits lack of consequences or rewards for noncompliant team response.

When the team exhibits that unresponsiveness the executive doubles down on resources, shouting louder, issuing more edicts, holding remedial meetings. "Something bad" like this happens because the timing of the doubling down is late, as  mentioned in the earlier question. The entire point of Part 2 of the book is to give the reader detailed and possibly subtle ways to ensure that the ideas he likes from Part 1 get propagated with the right kind of strength so that they are actually implemented by the team. This is in contrast to many books that  just give excellent management ideas, but leave you on your own to try to get them to happen in the company.

"Something good" happens when the executive exhibits preemptive influence, timing that influence to be in certain early phases of the project as outlined in Part 1. A conversation at the initial stages of a project, using the book questions, pre-seeds the directions in which the project evolves. The preemptive influence can be of relatively low strength by comparison to "doubling down" when that initial conversation is coupled to the tactics of Part 2.

InfoQ: What do you suggest executives do when they commission a software development initiative?

Racko: Every consultant who's experienced helping out hundreds of software projects develops his own favorite pet list of things executives should do when they start a project. It's tempting to look at the book and decide that the item on my pet list is merely an exhortation to get involved in a conversation with the team at the beginning of the project – sort of a touchy-feely new age approach. And while that might not be bad, it completely misses the really useful idea. That idea is this: the person who asks the questions is in complete control of the direction of what happens next.

That means that it is a total mistake to take the questions of the book and presume that they are mere data retrieval attempts to elicit facts from the software team. Yes, they will do that, they will elicit facts. And the nature of those facts may cause the executive to alter course or not. However, it is important to realize that to answer any of those specific book questions, the team has to begin to think in certain ways to even formulate useful answers to the questions. Questions implicitly focus and constrain as well as elicit. That is why I call this technique "management by query."

In a sense, I am asking the executive to think in some detail about his definition of success on the technical level for this project and to formulate questions whose answers implicitly define the details of that success. If a manager keeps asking certain kinds of questions over and over, the message the team will draw is clear – the topics of the questions are important measures of success to the executive. The need for formal rules, quality attributes, position papers, edicts, guidelines and memos is thereby drastically reduced. Resistance to  executive ideas is reduced because the answers to the questions come up out of the minds of the people who are performing the task rather than being imposed from above. The team owns the answers because they made them up and will naturally follow that direction because it feels like their own. And it is.

As an example, consider these four team questions about the user interface of a project: "How is the user interface going?" "Do the users like the new interface?" "What is the latest thing you've learned during the project so far about user interface quality?" "What stops us from having the most magical, friendly user interface in the industry?"

Superficially, all the questions appear to be about the state of the user interface, and one might see them as interchangeable. But on closer examination, each of thesequestions implicitly conveys what's important to the executive, and each question example specifically conveys something entirely different from the other question examples. Some of these questions will merely get binary answers requiring no thought on the part of the team and providing the executive with scant insight into reality. Others of these questions have entirely different effects.

So my suggestion about what executives should do when they commission a project is to first ask themselves how they would know the project was a success: what would be evidence that the project was magnificently excellent beyond compare? Then start thinking about what questions to ask in the beginning, middle and towards the release date that would continually reinforce (which is not the same as "demand") the production of that evidence. And then ask those questions often. Chapter 2 of the book calls this "exercising your power with a velvet glove."

InfoQ: Your book provides jargon-free questions which are based on Essence. What made you decide to choose Essence?

Racko: There have been many attempts historically to capture names and vocabulary of the pieces and parts of a software development process. At this moment in software engineering I perceive Essence as being the most inclusive. Also, at the level used in the book, the vocabulary is understandable to non-technical people such as users or funding agencies as well. That is a real plus.

InfoQ: How can executives use these questions?

Racko: The book primarily uses the Essence questions to determine, among other things, the state of progress that the development process is in – where the project in the start to finish timeline is. However, a careful reader will also discover that some of the questions can help determine how well-formed are things like the "team" or the "software requirements."

InfoQ: Are these questions only for executives?

Racko: Although the book presumes that the Essence questions, as well as any of the other questions, will be used by an executive having approval control or management control of a software project, the questions can be used by anybody at any level who desires to head off some of the typical problems that have plagued software development. The questions are not only designed to head off problems, they are designed to indirectly cause the team to think differently about software development in order to come up with the answers. That difference can have a positive effect on the way software development happens over the long term irrespective of the impact those questions might have in the project at hand.  From that perspective, many of these questions can be used by anybody to generically reshape the company's mindset.

InfoQ: You mentioned in the book that to get any changes done in an organization there must be room for them and energy available to do them. What if people in the organization feel overloaded; how do you deal with that?

Racko: It is easy to get cynical about overload and presume that all people will say they are overloaded irrespective of their actual state. But even if that is a realistic appraisal of people in the company, the first step is to probe for the details of that perception to reveal the sources of the overload. Overload is not some big amorphous cloud. Assuming that staffing and funding resources were adequately conceived, typically there are four sources of overload:

1. overload generated by the inefficiencies inherent in the current state of chaos within the company;
2. overload caused by too many concurrent technology changes being attempted simultaneously;
3. underestimated overload generated by interfacing activities required to coordinate the software project with other departments or geographical locations; and
4. overload caused by ongoing system rework that springs up as the result of an informal system specification or informal architectural design process.

The first step in reducing overload is to identify which of the above are active and to then take remedial action appropriate to the source. You can't correct what you cannot measure so the book also provides a survey style questionnaire in an appendix which can help ferret out sources of overload other than the general ideas above.

InfoQ: What can developers and tech leads do to gain support from managers for doing improvements?

Racko: This is really a brilliant question because implementing the answer to it would change companies around the world in unimaginably positive ways. I say this because invariably every time I have consulted on a troublesome project, somebody, somewhere, in the company already has the answer.

However, changing a company from the ground up for some arbitrary specific improvement is a daunting task. In fact, bottom-up change needs a specialized book unto itself different from the top down theme of this book. However, if the desired change is something that is specifically discussed in this book, the easiest way, although not guaranteed , is to let the book do the convincing work. Here is an outline of steps.

The first thing to do is to recognize that companies, i.e. top-level executives, do not want to be saved without their permission. Every day somebody walks into a top-level executive office and says, "Boss, I have something that will save the company 10%." All the boss would have to do is take 10 of those suggestions and the company could operate at 100% profit level. It can also happen that management mentality is such that suggestions from lower levels are treated disparagingly regardless of their value.

To get around these blocks, the developer has to conduct himself in such a way that:

1. the improvement becomes the target manager’s idea, and
2. success accrues to the target manager’s credit.

The developer or tech lead starts this by asking questions of the target manager and his or her peers. These questions should be asked casually – at the water cooler, coffee break, in the parking lot after work hours. The questions are along the lines of trying to determine what keeps the target manager up at night. What are the things that are worrisome? What is the top manager’s vision, if any? What stops this vision from happening? The tech lead should also try to find out what would have to happen to make the target manager a hero to the target manager's boss. Take some time to do this – perhaps a few weeks.

With that information, develop some summary statement that encapsulates all this reconnaissance. The statement should carefully avoid whining or complaining about a problem, but instead simply focus on a result which would almost incidentally solve whatever is the problem the tech lead is trying to correct.

At yet another water cooler conversation, the tech lead should introduce the idea to the manager in a phrase like, “Hey boss, about that morale problem (or whatever the issue was) you mentioned the other day, here is a book that has some unusual ideas that might apply. I’d be curious if you agree.” And hand him the book.

Do not ever tell him directly to read it. Your follow up is always something like, “I wonder if anything in the book has grabbed you yet?”

See what happens over time.

The tech lead should be aware that conditions of overload I mentioned earlier may apply to the target manager. Additionally, the target manager may be under constraints that he is not at liberty to reveal and those constraints may make acceptance of the improvement perfunctory or nonexistent. The maximum number of times to re-inquire about the book is two, because after that the tech lead will simply appear to be a "whiner." If there is no response after that and the problem is personally very vexing, consider transferring to another company.

InfoQ: How can executives work with middle management to get buy in for improvement?

Racko: Often, middle level managers are "status quo" oriented. Another way of saying that is they often go with the crowd. The tactic, then, is to make sure that the middle level manager perceives that there is a "crowd" around him or her that is in favor of the idea that is being proposed. The "crowd" for these purposes is managers and executives above the middle level as well as the staff below the middle level. For resistant middle level groups, if the people both above and below are in favor of the proposed change, middle level managers will almost invariably tend to go along. Considerations of overload also apply to middle level managers. As a tweak, middle level managers can be made part of whatever the reward scheme is for implementation of the proposed change. A particularly effective reward is one that rewards the middle level manager for convincing other people such as peer level middle level managers or lower level staff to go along with the improvement.

About the Book Author

Roland Racko has been an information technology consultant, lecturer, and instructor for more than 40 years. He has helped software teams manage software success in Sweden, Germany, East Africa, Taiwan, Canada, and Fortune 100 companies in the United States.  He has written columns for several computer trade magazines and his writings have been anthologized in two books. One of his primary skills is ferreting out the issue behind a given apparent problem, and helping teams and executives understand in novel and useful ways what stops them from having the success they desire, and then leading them to take the necessary positive action steps.
Racko may be reached ON LinkedIn. For additional book download resources, please see.