A second tech writer got assigned to TDP. I had been expecting this eventually, because when the SMEs are finally done there will be a lot of work to do ASAP. They aren't, though, so I was a little surprised to have H. request this now. She bent over backwards to tell me that it was not intended as a criticism of or complaint about my work. She said she just wants one writer taking note of decisions made while the other works on the document(s). I just hope she made it equally clear when talking to my supervisor.
I guess I'm just a tiny bit worried about that - not in a performance-review sense, I think I've done a good job of managing expectations and everyone knows how screwed-up this project is - but in a genuine, doing-a-good-job, letting-people-down sense. Weird of me, I know.
Thursday, April 28, 2011
Wednesday, April 27, 2011
About me
I'm in my late 20s at the moment. I've spent most of my life in the northeastern U.S. I moved to the DC area in the summer of 2008 and shortly wound up at my current job. If I had come down to DC with a more firm plan or looked for work harder or just happened to get a job offer from someone else first, I might have been working for a politician or advocacy organization all this time, but this is what I found and like I've said, I like it well enough.
I've been blogging for about eight years now. Rarely anything seriously, mostly personal stuff to keep friends and family in the loop or vent my frustrations or pontificate about whatever topic interests me. I tried some posts about politics and current events here and there, but didn't stick with it. I wasn't thick-skinned enough for it, and I also wasn't able to keep up a serious posting schedule. I like to write, but not enough to stick to it regularly without someone cracking a deadline whip. About three posts a week is more or less what I'm aiming for these days, and even that is a lot more than I've managed in years, but it's a really slow posting rate for anyone who blogs professionally.
But still, blogging for eight years, I said, and I like to write, so where is it? Answer: not here. Recently I feel like I've had quite a bit to say about work, but that seems risky. Even if I don't feel the need to vent about something specific, you never know when I might, or what someone else might interpret as more controversial than I do. And my other blog has always had quite a bit about my personal life on it. So I created this to reduce risk.
Also, this seems like as good a place as any for a quick note: I am likely to not follow up on things here, especially things just mentioned as off-the-cuff examples. Sometimes I will, like this update to a previous post for example, but I won't always. This blog is not a novel, posts are not intended to tell a coherent narrative, I'll try to keep things coherent but I won't always bother, and sometimes the best way to maintain confidentiality might be to not mention something at all. One point of all this is, don't assume that something continues to be a problem until I come right out and say it has been fixed.
I've been blogging for about eight years now. Rarely anything seriously, mostly personal stuff to keep friends and family in the loop or vent my frustrations or pontificate about whatever topic interests me. I tried some posts about politics and current events here and there, but didn't stick with it. I wasn't thick-skinned enough for it, and I also wasn't able to keep up a serious posting schedule. I like to write, but not enough to stick to it regularly without someone cracking a deadline whip. About three posts a week is more or less what I'm aiming for these days, and even that is a lot more than I've managed in years, but it's a really slow posting rate for anyone who blogs professionally.
But still, blogging for eight years, I said, and I like to write, so where is it? Answer: not here. Recently I feel like I've had quite a bit to say about work, but that seems risky. Even if I don't feel the need to vent about something specific, you never know when I might, or what someone else might interpret as more controversial than I do. And my other blog has always had quite a bit about my personal life on it. So I created this to reduce risk.
Also, this seems like as good a place as any for a quick note: I am likely to not follow up on things here, especially things just mentioned as off-the-cuff examples. Sometimes I will, like this update to a previous post for example, but I won't always. This blog is not a novel, posts are not intended to tell a coherent narrative, I'll try to keep things coherent but I won't always bother, and sometimes the best way to maintain confidentiality might be to not mention something at all. One point of all this is, don't assume that something continues to be a problem until I come right out and say it has been fixed.
Tuesday, April 26, 2011
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.
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.
Monday, April 25, 2011
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.
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.
Thursday, April 21, 2011
Somebody else's problem
I'm OK with being on a doomed project, really. I'm pretty sure I'm so far down the totem pole that responsibility would stop before me, so I'm not too worried about personal repercussions for the nearly inevitable failure. As for pride in a job well-done or shame at failure, they don't seem relevant here. As for doing this job well, the specifics of this project make me unsure whether it's even a good idea at all, and as for failure, as I've said, there are so many problems with it that its success is out of my hands.
And at least it's keeping me busy, which some projects don't. And as my types of work go, I personally prefer editing documents, which is what I happening to be doing here at the moment. Editing can sometimes be a fun, moderately creative challenge as I search for the mot juste or figure out another trick to Microsoft Word. It's certainly fun compared to writing new documents (it's not "writing", it's copy-pasting from documents written by other people and hoping like hell I didn't get things completely out of context) or organizing public comments.
It's other people on the team I feel sorry for. That guy on the team who doesn't know how to do his job isn't actually a bad guy, just clueless, and this is exactly the wrong kind of project to cut one's teeth on. And mainly, there's H., another team member and friend of mine. She's theoretically in charge of the whole project (theoretically. More on that later) and also happens to be the one person whose supervisor cares about the deadline. It's painful just watching her try to herd a team through an uncomfortable decision in a meeting. I might be too low for responsibility for failure to land on, but she isn't.
And at least it's keeping me busy, which some projects don't. And as my types of work go, I personally prefer editing documents, which is what I happening to be doing here at the moment. Editing can sometimes be a fun, moderately creative challenge as I search for the mot juste or figure out another trick to Microsoft Word. It's certainly fun compared to writing new documents (it's not "writing", it's copy-pasting from documents written by other people and hoping like hell I didn't get things completely out of context) or organizing public comments.
It's other people on the team I feel sorry for. That guy on the team who doesn't know how to do his job isn't actually a bad guy, just clueless, and this is exactly the wrong kind of project to cut one's teeth on. And mainly, there's H., another team member and friend of mine. She's theoretically in charge of the whole project (theoretically. More on that later) and also happens to be the one person whose supervisor cares about the deadline. It's painful just watching her try to herd a team through an uncomfortable decision in a meeting. I might be too low for responsibility for failure to land on, but she isn't.
Wednesday, April 20, 2011
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.
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.
Friday, April 15, 2011
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.
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.
Tuesday, April 12, 2011
It gets worse
My earlier post about the doomed project needs two updates. First of all, where I said that there had been a problem with people putting things in the regulation that we have neither room nor time for, but "that is under control by now"? Not even close. We had a meeting today about the status, and how to avoid getting further behind schedule, and getting everyones' bosses to stop putting more things in here was identified as a great way to keep things under control. No one could think of anything we could get away with removing that would save time going forward, though.
And second, there's probably yet another problem: me. I blamed the subject matter expert (or rather, the lead subject matter expert, or rather a subject matter expert) for not knowing his own job's responsibilities "at least, as far as they relate to mine". Over the past week, though, I've started to get the impression that I'm in the same situation. I'm pretty sure I've never written regulatory instructions before. Since I haven't, I've assumed that SMEs and/or lawyers do them. But I've mentioned this to my supervisors, and they sounded surprised. And you know, I was trained on it way back when I first started here, and why would the training include stuff that wasn't my responsibility? And you know, even if it is part of my job, it might never have come up until now. Off the top of my head, I can't think of a project I've done here that wasn't inherited from another tech writer who left for whatever reason, wasn't a continuation or offshoot of an earlier project, or wasn't a technical amendment that the lawyer basically had to write themselves. In every such case, most of the technical work was done before I got it.
So not only do some team members not know what they're doing, not only are we weeks behind schedule, not only have people still been putting new content in this up to now... I don't know what I'm doing either.
DOOMED.
And second, there's probably yet another problem: me. I blamed the subject matter expert (or rather, the lead subject matter expert, or rather a subject matter expert) for not knowing his own job's responsibilities "at least, as far as they relate to mine". Over the past week, though, I've started to get the impression that I'm in the same situation. I'm pretty sure I've never written regulatory instructions before. Since I haven't, I've assumed that SMEs and/or lawyers do them. But I've mentioned this to my supervisors, and they sounded surprised. And you know, I was trained on it way back when I first started here, and why would the training include stuff that wasn't my responsibility? And you know, even if it is part of my job, it might never have come up until now. Off the top of my head, I can't think of a project I've done here that wasn't inherited from another tech writer who left for whatever reason, wasn't a continuation or offshoot of an earlier project, or wasn't a technical amendment that the lawyer basically had to write themselves. In every such case, most of the technical work was done before I got it.
So not only do some team members not know what they're doing, not only are we weeks behind schedule, not only have people still been putting new content in this up to now... I don't know what I'm doing either.
DOOMED.
Monday, April 11, 2011
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.
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.
Thursday, April 7, 2011
Getting back into writing
I should post more often. Previous gaps in my writing were generally because I didn't have much to say. Over the past month or so, though, I have had quite a bit of things to say, and I have drafts of posts or brief notes to myself on my phone to show for it, I just didn't get around to writing up a blog post. So here's one of those drafts of a post, completed. Better late than never, right?
Recently I posted about a project I'm on at work, and how three years is probably the reasonable minimum time to complete a regulatory project like this - instituting new or changing existing safety regulations. Three years from when someone notices a problem that's the responsibility of this agency to when that problem gets fixed. And that's a minimum, assuming no serious research is required, assuming no major changes are made partway through to how the agency wants to handle it, etc. One of my first major projects here related to a certain kind of safety standard. This particular issue has got worse slowly but steadily since the 1960s. It was brought to peoples' attention by two accidents, in 2003 if I remember correctly. The project began soon after those, was well underway when I got here in 2008, and the last piece of it was supposed to be published today but it doesn't go into effect all at once.
Eight-plus years from accidents in which a dozen people died to enacting regulations intended to make that kind of accident less likely. That sounds like a long time, right? That's what I thought when I first started working here; everyone "knows" bureaucracy is slow, but it was striking and worrisome to see it up close. But you know, there's a good reason for the intermediate steps, and most of them are inevitable given American history in this area.
Where does a regulation come from? I don't know much about Congress beyond the "Schoolhouse Rock" version, but in this executive branch agency, it's a long process. Once someone in a position to set the agenda for the agency decides that a certain project would be a good idea, a regulatory team has to get the language of amending the Code of Federal Regulations just the way they want. That team includes at least five people and usually more: a tech writer, an economist, a lawyer, a regulatory development manager, and a subject matter expert, and there's usually more than one of the last. This is not their only responsibility during that time; most are assigned to multiple projects at once. They may often have to refer to their respective bosses, who may not see eye to eye with each other. Then there's the preamble, explaining and justifying what we're doing, which is usually more pages than the actual amendatory language. All this takes a couple months at least.
Once the team is happy with it, it goes to everyones' superiors, and then to other federal agencies for further review and approval, including legal review and economic review. That takes another few months. That is just to publish a notice of proposed rulemaking. The public and industry groups usually get several months to comment on that, as well as other government agencies that aren't officially in the review process. After the comment period, it goes back to the team and the process starts over for a final rule, which has to take into account the comments. Minor and/or easy regulations might take less time than that or be able to skip steps, but more high-priority ones will usually have extra steps or take longer on any of those. And if a project is minor enough to be easy, it's generally minor enough to get pushed aside in favor of higher priorities.
And the thing is, that's all inevitable, or damn near. The economic review during the reg-writing process makes it take a few weeks longer, but if it wasn't included, there's a good chance that other federal agencies later on would shoot the whole project down and send it back to square one entirely. Same for the lawyer. The subject matter expert isn't working at their discretion, they're conferring with other people and have to consider thousands of pages of current regulatory text, independent industry standards, and other factors. Most of the review and approval steps are required by law or executive order (for our purposes, the same thing), which were implemented in response to pressure over regulations that probably really did have too many unintended consequences or were bad ideas from the start.
Everyone wants safety regulations to be effective, harmless and quick. Unfortunately, you have to pick two at most, and you can't even be guaranteed of achieving both of the ones you aim for. (Why is that? In addition to all the obvious general reasons like human error and known unknowns, there are specific reasons as well. More on that later.)
Recently I posted about a project I'm on at work, and how three years is probably the reasonable minimum time to complete a regulatory project like this - instituting new or changing existing safety regulations. Three years from when someone notices a problem that's the responsibility of this agency to when that problem gets fixed. And that's a minimum, assuming no serious research is required, assuming no major changes are made partway through to how the agency wants to handle it, etc. One of my first major projects here related to a certain kind of safety standard. This particular issue has got worse slowly but steadily since the 1960s. It was brought to peoples' attention by two accidents, in 2003 if I remember correctly. The project began soon after those, was well underway when I got here in 2008, and the last piece of it was supposed to be published today but it doesn't go into effect all at once.
Eight-plus years from accidents in which a dozen people died to enacting regulations intended to make that kind of accident less likely. That sounds like a long time, right? That's what I thought when I first started working here; everyone "knows" bureaucracy is slow, but it was striking and worrisome to see it up close. But you know, there's a good reason for the intermediate steps, and most of them are inevitable given American history in this area.
Where does a regulation come from? I don't know much about Congress beyond the "Schoolhouse Rock" version, but in this executive branch agency, it's a long process. Once someone in a position to set the agenda for the agency decides that a certain project would be a good idea, a regulatory team has to get the language of amending the Code of Federal Regulations just the way they want. That team includes at least five people and usually more: a tech writer, an economist, a lawyer, a regulatory development manager, and a subject matter expert, and there's usually more than one of the last. This is not their only responsibility during that time; most are assigned to multiple projects at once. They may often have to refer to their respective bosses, who may not see eye to eye with each other. Then there's the preamble, explaining and justifying what we're doing, which is usually more pages than the actual amendatory language. All this takes a couple months at least.
Once the team is happy with it, it goes to everyones' superiors, and then to other federal agencies for further review and approval, including legal review and economic review. That takes another few months. That is just to publish a notice of proposed rulemaking. The public and industry groups usually get several months to comment on that, as well as other government agencies that aren't officially in the review process. After the comment period, it goes back to the team and the process starts over for a final rule, which has to take into account the comments. Minor and/or easy regulations might take less time than that or be able to skip steps, but more high-priority ones will usually have extra steps or take longer on any of those. And if a project is minor enough to be easy, it's generally minor enough to get pushed aside in favor of higher priorities.
And the thing is, that's all inevitable, or damn near. The economic review during the reg-writing process makes it take a few weeks longer, but if it wasn't included, there's a good chance that other federal agencies later on would shoot the whole project down and send it back to square one entirely. Same for the lawyer. The subject matter expert isn't working at their discretion, they're conferring with other people and have to consider thousands of pages of current regulatory text, independent industry standards, and other factors. Most of the review and approval steps are required by law or executive order (for our purposes, the same thing), which were implemented in response to pressure over regulations that probably really did have too many unintended consequences or were bad ideas from the start.
Everyone wants safety regulations to be effective, harmless and quick. Unfortunately, you have to pick two at most, and you can't even be guaranteed of achieving both of the ones you aim for. (Why is that? In addition to all the obvious general reasons like human error and known unknowns, there are specific reasons as well. More on that later.)
Friday, April 1, 2011
Stupid people
One annoying thing about my job as a technical writer (editor, really) deep in the weeds of a regulatory agency is that so much of what I do should be unnecessary. I mean, I spend a good fraction of my time on style and formatting things that absolutely need to be done, and/or save more time in the long run, but would save a great deal more time if people had done it this way in the first place. Really simple things, like "do not let Word autoformat numbered lists" and "make tables by using the 'Insert Table' tool, not by hitting tab repeatedly". If the engineers and lawyers who work here got a handout about house style when they started working here and an hour's refresher course every six months or so, this place could fire half the people in my position. (I mean, not that I WANT that of course, I like having a job and having an easy one is a bonus, but it would be nice to not spend so much time on stuff that would just plain make more sense for other people to do.)
Subscribe to:
Posts (Atom)