Power and Influence
Never stand begging for that which you have the power to earn.
– Miguel de Cervantes
“You won’t catch me delaying a product release because of the documentation,” he said, in response to what I thought was a reasonable assertion that user documentation is part of the product and that the project schedule should reflect this reality. We were in a project meeting looking, as always, for some way to avoid yet another delay. And, as always, the question was whether we could shave some time off the back-end of the documentation schedule to compensate for adding time to the development schedule.
While you may not get quite as direct a rebuke from your project manager as I did, you’ll have to look hard to find one who would choose to delay a release just to improve the documentation. And, while I’m sure it must have happened somewhere, to some now unemployed manager, I’ve never seen a product release delayed because of the documentation.
This doesn’t mean you don’t have the power to delay a product, but using that power is as close as you or I are likely to get to using the “nuclear option.” You’re going to need to throw yourself in front of the release train and convince the product manager that it’s risking his or her career, not to mention yours, to put the product out without the right documentation. Even if you win that argument, your career will probably end up in worse shape than if you were running around with the boss’s wife.
Every documentation team I’ve managed or observed is constantly under pressure to shorten schedules and reduce effort. A documentation manager’s ability to resist unreasonable pressure is a direct result of that manager’s influence with the project management team and his or her peer managers.
As any student of power and influence knows, authority derives from formal and informal sources.  Formal authority derives from your position in a management chain, or your assigned role on a project. It is delegated to you, and can be taken away from you, by a higher formal authority; i.e., the company you work for and your management chain. The good news is that formal authority is well understood and accepted in the corporate world, and if you have the full weight of your management chain behind you, it can be a powerful force. The bad news comes in three parts: first, formal authority doesn’t help very much with those above you in the management chain, second, it can be taken away just as easily as it is given, and third, documentation managers don’t have any real formal authority anyway. One of the tougher facts of the documentation life is that documentation managers live at the bottom of the management food chain with formal authority over little more than their direct reports.
So, while you still need it, formal authority is only one small part of the picture. To succeed, you need to develop informal authority, which is any authority that is independent of formal authority. This section uses a true story (to protect innocent and guilty alike, no names are used, but this happened as described) of a situation where one of my teams was able to increase its informal authority creatively.
This was a large system software project that issued an update release every year or so. The project integrated modules from dozens of projects, each of which was responsible for contributing to a “Delta Document.” The Delta Document described in detail what each group would be changing in the next release. In practice, this document was important to the support organization, which used it for planning, but it was a pain to develop, and because it was of little interest to the development team, it was poorly written from the start and never updated. Further, because each section was written in a word processing format with a loosely defined structure, it was difficult to combine into a single document, and once combined, the document was nearly impossible to use.
At the same time, our documentation team was developing “Release Notes,” which described the product to the end user. Since one of our prime sources of input was that same badly written, out-of-date, poorly formatted Delta Document, we were often forced to go back to the development team to gather the information we should have had already.
If you were in a position of power, you could simply mandate processes that would ensure a well written, up-to-date Delta Document. But, as a documentation manager, you’re not in a position of power. So, how do you deal with the problem? You can try to convince someone with more formal authority to mandate a change, and that will sometimes work, but that falls into the category of begging, which to paraphrase Cervantes, is something you don’t want to do if you have any other option.
While on more than a few occasions I’ve been reduced to begging, in this case, we found a way to solve our problem and increase our influence with the development organization without getting on our knees.
The first thing we recognized was that there wasn’t just one problem. The documentation team had a problem, which I described above, but the development teams didn’t care about that problem. Their problem was that they were required to develop a Delta Document whose value they didn’t really understand, then they were required to give the same information to the documentation team for the Release Notes, which again was of little value to them. They appreciated the need to document their changes, but not the need to do it twice, in different formats, for different teams. Since their problem and our problem were not the same, they had little incentive to solve our problem, especially if the solution left their problem unsolved.
Once we understood the development teams’ concerns, we were able to find a solution that addressed both problems. We took responsibility for both the Delta Document and the Release Notes, and turned them into one document. We developed a web site that let developers bring up their section of the Delta Document for the previous release, edit it to be appropriate for the new release, and save the new version. The documentation team took that input and first prepared the Delta Document for the support team. Then, as the project progressed, we edited the content for updates, consistency, and style, then brought it back to the developers for review at regular intervals. For those reviews, the development teams just needed to look at the current state of their sections and flag changes.
We made the combined document available on the web throughout the project in a consistent and easily searchable form. The project management team got an up-to-date view of the contents of the release, the development teams got a streamlined input process, and the documentation team got well-formatted, up-to-date information from a development team that was much happier.
We didn’t get this for free. We needed to develop the web input page and deal with a couple of extra review cycles. Plus, we took responsibility for a document we hadn’t previously owned, the Delta Document. But, the cost was mostly short-term, and paid for itself by reducing the effort it took us to extract information from the development teams; both the mechanical effort of converting information from badly formatted sources, and the human effort of dealing with unhappy developers who couldn’t understand why we wanted the same information they’d just given another team.
However, the most important gain was in status. By giving the project managers a more usable, up-to-date Delta Document, and at the same time improving productivity for both ourselves and the software developers, we showed that we could add value to the overall development process. Normally, I hate the term “add value,” but sometimes, like here, it applies.
The Japanese use the term “giri” to refer to a moral obligation or debt. While “giri” is a subtle and complex term, an explanation of which is well beyond the scope of this book, the idea of favors given and received is basic to any culture. Giri takes this a step further because favors are not given in anticipation of a specific return favor. In fact, while it’s understood that reciprocation is required, that is never spoken. Instead, a favor is offered as a gift signifying loyalty and respect for the other person’s status or position.
By solving this problem, we showed our respect for the development teams in a way that didn’t demand a favor in return, but still incurred a moral obligation that must be honored at some point. We also raised our status as engineers by showing that we could design a useful web tool.
Power, both the lack of it in most documentation teams and strategies for increasing it, is a central focus of this book. Without power within your organization, you will not be able to deliver quality documentation. I’ll return to this topic, but for now, start looking for ways in which you can gain influence in your organization. Take Cervante’s advice and always use the power you’ve got, before you beg a “higher authority” to give you power.
 Check out John Kotter’s Power and Influence [Kotter85] for the definitive text on this subject.
Copyright © 2007 Richard L. Hamilton