Taking pride in my work is bad.

Yesterday I thought I saw a good example of the importance of taking care, approaching problems with a fresh eye, and doing things right the first time. I should have known better.

One final rule has been stuck in one stage of clearance for a while. One TMBB got back to us over a month later than the other two. It was objectively harder to address her comments separately from the rest, and it was annoying that we had to. So we did as little as possible about them.

A week ago, we called it done and sent it back to the TMBBs. The only comment so far has been the WMBD boss asking for more clarity on two points. When I looked at that section again, one of the comments by the late TMBB jumped out at me. I remember resenting that comment. She suggested moving a certain sentence higher in the document. I thought that was dumb, because there was only one earlier section that it could have gone in and that was already too long, so we just replied that it was addressed by other edits. But yesterday morning it occurred to me that I could move it within the same section, which would also address part of the WMBD's comment. So I moved that sentence and added one more on the other point and asked what the team thought.

I was proud of this. I think it was clever to use one problem to solve another. It took a little creative wordsmithing to address the WMBD boss's second point clearly. At the same time, the problem is a good demonstration of "haste makes waste." If we had thought harder about the late TMBB's comments when we first got them, or if she had got them back to us when the other TMBBs did, we might have realized that earlier. Several different people made the same mistake. If I were a teacher or a manager I'd point to this as an example of how careful deliberation can matter.

Except that to some people, it didn't matter. All of the team got back to me promptly to say that they approved, except the lawyer. She'd need another day. This morning, she deleted the sentence I added about the second point because she felt it was redundant with the sentence before it. There are several problems with this.

1. Even if it is redundant, the WMBD guy asked us to add it. We don't have to do everything people should ask for, but should at least address it.
2. When I reread the section, I agreed with the WMBD guy. The previous version of the section could, in fact, have been clearer! Going into a bit more detail about the topic looks genuinely good!
3. If she doesn't like it, what's her alternative? She didn't say. Both the WMBD guy and I said specifically that there were two points to be discussed. She wanted to remove the discussion of one of them without doing anything in its place.

 In the end, the economist made a few edits to my phrasing, which apparently placated the lawyer, and it went back into clearance. But it was dumb of me to think that trying to do a thorough job would actually help.

It could be worse

I said that I find editing kind of fun, but I imagine that is rare and maybe even weird. I certainly have that impression based on how little people do it on their own. I explained in that post what I like about it - lots of little, moderately creative challenges. Well, this post is about a part of my job that I don't like.

When I told this story on another blog, they said that the situation, "responsibility without authority", sounded like the very definition of stress. On another project (the one mentioned here, not that it matters), for a while my main responsibility was organizing public feedback. It was a complete mess.

First of all, there was a lot of redundancy in public comments. People often would submit comments by both e-mail and fax or mail and fax or e-mail and mail, presumably to make sure they got there, despite clear requests not to. In addition, a lot of comments had two ID numbers. This was partly because of multiple submissions, and partly because of a change in the project partway through, and I think it might also have been because of a change in how my agency handled comments around the same time. Or maybe the federal government in general, I don't know. (I suppose I'm lucky they didn't all get four ID numbers, then.) The thing is, we couldn't just throw them all in there, because we need to be able to say specifically how many people objected to the rulemaking, how many people claimed they personally would be impacted by it, whether four or just two people said they did a study and got different numbers than our own engineers, etc. In addition, the three(ish) subject matter experts (SMEs) had to sort through the comments. They needed to refer to comments on Topic 1 in the Topic 1 section of the preamble, comments on Topic 2 in the Topic 2 section of the preamble, and so on.

If we were talking about a dozen public submissions, this would be no problem, but we're talking about more than 60 comments (maybe more than 200, depending on what you're counting), and at one point there was about 50 topics. It was my job to winnow out duplicate comments and sort quotes by topic. After the SMEs had each read over printouts of the comments and marked excerpts on them, it was my job to enter all this into a database. So I was sorting printouts of 60-200 things marked up by three different people, who didn't always agree with each other.

Many errors were inevitable. Because of the "low on the totem pole" thing, and pressures on the group as a whole like deadlines, I had little to no say about how to do it. For just one example, it would have been much easier for me and I'm pretty sure it would have objectively made more sense if they had given me one set of comments marked up by everyone, but that's not how it worked out. I had a job, but had no say in how to do it other than begging. Responsibility without authority. Throw in a deadline, and all this happening when I was still relatively new to the job, and it was miserable.

I bring all this up partly to contrast with my current work, which for all my apparent complaining really is relatively fun and straightforward. I also bring it up because it's what some people on the team are dealing with in their own ways. It's not sorting public feedback, but again, H. is the person on the project team I feel most sorry for. She is the boss of the team, theoretically. But she can't get rid of anyone or get anyone new. She can call meetings, but her authority over peoples' time is limited to asking politely. Her immediate supervisor is the guy who cared the most about the deadline, but neither of them can just tell everyone else to do it their way.

Incompatibility

In a meeting today, I learned that not only is cross-platform compatibility" impossible to get while sticking to the deadline, it's almost impossible to get by itself.

Cross-platform compability is about allowing two groups, call them A and B, to create the same kind of thing. We can't allow cross-platform compatibility with each using their own existing standards. A's are different, generally higher in terms of safety and quality, and certainly more expensive to meet, so A would be completely unable to compete with B.

We can't change A's standards to make cross-platform compatibility cheaper, either. Actually, I gather that we might in the near-to-medium future, but that's definitely way beyond the scope of TDP. That's another at-least-three-years project by itself, and it's the kind that's likely to take longer than average, and our bosses need to make a decision on this now.

We can't allow cross-platform compatibility by requiring Group B to meet A's standards, either. It would edge up against policies forbidding that kind of thing, if not completely break them. And it would be a massive PR nightmare, to put it in terms so vague they are almost but not quite meaningless. It might be legal, and I guess it might even be enforceable, but would really piss people off... in ways that are, again, outside the scope of TDP.

And the thing is, we can't ignore cross-platform compability or put it off until the comprehensive rulemaking either. Because we're told that at least some entities in both A and B would need it. What those entities need doesn't set our agenda (sort of. Generally. This is another thing I'll elaborate on later), but if they state a preference now, then given why we're doing this, we'd need a very good reason to do the opposite thing.

When I was told that cross-platform compatibility would add between two and 18 months to this, I thought that was mostly because of the analysis - doing it by fiat would be relatively simple, I thought, but figuring out all its effects and indirect effects and their indirect effects would take months. Now, though, I wouldn't be surprised if simply agreeing on how to do it took 18 months.

More than the usual office politics

I've mentioned lots of things about work that really are general office issues. Conflicting bosses, fictional deadlines, people who don't know what they're doing, fixing mistakes that shouldn't have been made in the first place - annoying to deal with, but the kind of thing almost everyone in a cubicle has to deal with eventually.

Here's something that I'm pretty sure is unique to working in a government bureaucracy, though: my status as a contractor.

If someone made a TV show of my life and you watched the show with the sound off, you'd never guess that I wasn't a government employee. I've been a technical writer here for about two and a half years, and every day on the job has been in the same government office building. When my security badge is between renewals I have to go through a metal detector to get to work. My job involves editing regulatory documents, mostly related to new public safety requirements or industry standards. This is not a temporary thing or consultancy or on-site troubleshooting; this office is my office, I just get paid by a third party.

So the setting doesn't give any clues that I work for private industry, and neither does almost anything else. On those project teams I mentioned in a previous entry, I'm pretty sure us tech writers are the only people who aren't true government employees. The difference between what we do and what the rest of the team does is generally subtle. We're each focusing on our respective topics - the subject matter expert on what the rulemaking actually does, the economist on the costs of it, the tech writer on plain English and current Federal Register style, and so on - but we're all working in the same document and attending the same meetings and have to ask each other lots of questions to do our own jobs. Us tech writers frequently get reminders by our supervisor (also a contractor) that we can never, ever "jump over the line by... telling the gov't what to do", but every organization has to have someone that's at the bottom of the totem pole, so the fact that it's us doesn't really show anything.

For my first several months here, I thought this was stupid, not that I would look a gift horse in the mouth of course. I have always understood that the theoretical goal of contracting out services was to do things that it wouldn't make sense for the client to do for themselves. For example, expertise you need sometimes, but it's needed too rarely to be worth keeping someone on staff for. Or hiring contractors to take care of things that are necessary but not part of the core mission, like groundskeeping, so that the organization can focus on their real goal. Or a small organization contracting with a much larger one to take advantage of economies of scale they can provide. However, like I said, none of those fit here. Tech writers work on everything, we're an integral part of the process, and there are few organizations bigger than the federal government. So what's the point of being a contractor? I have one supervisor in the building and she has a supervisor who spends a lot of time in the building, although I honestly have no idea where a desk is that he calls his own. What do they do that a government employee couldn't? What do they add to the process but another layer of bureaucracy? What does our contracting company add to the process?

Eventually, I griped about this to a friend who's also a contractor, but with a different company doing a different job. He told me that the advantage of using contractors is that we're easier to fire.

Caught in the middle

Many of the problems at my job are government-related stuff, but some are just general office politics-related mess. Dilbert, Office Space - a lot of this is not peculiar to the government. (Some is, which I still plan to write about more specifically, but anyways.) For example, the deadline mandated by Congress for the doomed project. No matter what, such a short deadline for a project of this type would be a problem. But right now it's coming to a head, and I'm pretty sure this is the kind of problem that could happen anywhere. The team has something like eight different supervisors between us at the same level as each other, and one problem is, they disagree and don't handle it well.

There was a meeting on Wednesday to update them on our progress and ask them to make a decision on whether or not to include something that I'll call "cross-platform compatibility". That's not it, but (a) calling it that helps maintain anonymity, and (b) there have been so many additions that specifically what the latest one is doesn't matter. At least one of the bosses really wants to leave out cross-platform compatibility and stick to the deadline, while most of the rest are happy to ignore the deadline and keep on putting new requirements in this regulation and happily let the project take an additional year or more, even if that means that this agency gets sued.

Now, this is an impasse. These two positions are unreconcilable. There is no reasonable middle ground. Cross-platform compatibility would add, at a rough estimate by the team, between two and 18 months to the project. (This makes it bigger than most additions, maybe even the single biggest addition, but again, it's just the latest of many.) A partial version of it would satisfy neither side. And we are getting so close to the deadline, and so much of the time remaining is tied up by layers of review that are out of our hands, that we really can't add practically anything else and still plan on the deadline, no matter how small or straightforward it might look. So either the guy who's very interested in the deadline has to give or everyone else does.

There are many good ways to settle an impasse. Hypothetically, they could put it to a vote. Rationally, they could perform a cost-benefits analysis: exactly how likely is a lawsuit, how much would it cost, and is getting cross-platform compatibility implemented a couple years earlier than it would otherwise worth that risk? Or maybe they could appeal the decision up the ladder: they both have bosses of their own. I think the next level up from them is just one guy. If I'm wrong about that or if he can't decide, he could elevate it further.

However, what actually seems to be happening is that one boss who cares about the deadline is trying to enforce it and hope the others don't notice. Seriously, he seems to be just trying to sneak it in there, at a meeting they weren't invited to and putting it directly into the project plan which most people can't even see. To me, this does not look like a healthy decision-making process and I really wish our bosses would take it up with their mutual boss, but it's not my decision.

The shutdown

I went to work today like usual. This was a surprise because of the warnings about a shutdown or furlough or, as my bosses insisted on calling it, "appropriations lapse". I wasn't looking forward to it; besides the totally normal "get up on Monday" problem, I had seven hours of meetings scheduled for today. I wouldn't have minded an excuse to skip that. I didn't get that excuse, but it's over now, thankfully. (That is, I'm still at work, but not in a meeting.)

But last week was a mess because of the risk of appropriations lapse. Friday I had 10 department-wide or administrative e-mails by 3:45 p.m. but no one could even say for sure what to do if the government shut down. And that's not counting e-mails relating to winding down specific projects, or e-mails on previous days about the shutdown. For comparison, the Friday before that had eight department-wide or administrative e-mails, (seven of which were about a one-time cadet training event including several "reply all"s), the Friday before that had two and the Friday before that had five.

Part of that uncertainty is because no one knew exactly what Congress would do, of course. But also, part was because of our status as contractors. There's a requirement that we have to be supervised by government personnel; for example, flextime and telecommuting are much harder for us than for most people in this building, if not impossible. But on the other hand, as contractors we're bought and paid for in advance. So if the government employees aren't here but we are and are willing to work, do we go home but still get paid? Who knows? It's unrealistic to hope for such an obvious loophole, but still, the fact that we never got definite guidance made me wonder.