Everything is Minimalism

Don’t Hate the Webinar

I am training coordinator for our team, which means I look for trainings we can attend or develop and help keep them documented. I have always been partial to webinars—get a little info, stir the mental pot, all while sitting on your butt when you could be parsing release notes–but these days I don’t book so many of them for the team. Our group has a way of reducing every webinar to something they already know.

Is it because many of the presentations cover the topics at a high level and we’re becoming advanced? Is it because webinars are a passive learning experience? My team lead handed me back an Intercom article I’d loaned him recently, saying, “So, basically, be more visible in the company.”

Each time this happens, I have the sensation of tilting a prism, or looking through someone else’s prescription glasses. “Oh, crap. Everyone in tech comm really is repeating themselves. And repeating everyone else’s stuff, too.”

I don’t really think that, though. I think that it’s just that the principles of good writing don’t change, nor do the principles of project management, nor of team building, nor of promoting your team within the organization.

As we advance in our field, we can’t expect to read books and attend trainings and have them be packed from start to finish with brand new, actionable information that we’ve never heard before. Articles and webinars can give us a new idea, reinforce a nuance, or energize us. We have to make it an active learning experience.

Eight Webinars on Minimalism (with Homework)

This week and next week I am attending an STC certificate course on minimalism, taught by Bernard Aschwanden of Publishing Smarter. Bernard started off with a discussion about the definition and characteristics of minimalism. He’s also emphasizing audience analysis and improving the actual products.

These are all webinar topics in themselves, and webinars I’ve attended, at that. But talking about them all together, in the context of minimalism, set things clicking in my head.

And Now I Will Perform a Magic Trick

Partly based on Bernard’s information, I’m putting together a training for our team on what minimalism means to us. We’ll talk about definitions, but then we’ll talk about how our current initiatives support minimalism and what minimalism can do for us.

1.Knowing our audience.

We’re gaining momentum on this, and we should be more deliberate about it. We can’t successfully reduce the volume of our content—which is currently overwhelming—without a good idea of where we can focus. We should identify our critical users and write to them. If we’re fuzzy on this we’ll be veering all over the place with our documentation.

2.Improving the product by improving our communication with the developers.

The idea is that if the product is intuitive, we’ll need less documentation. No one on our team, that I know of, has formal UI design experience. What we have is a honed sense for identifying and clarifying inconsistencies and processes.

For a software application, we could apply that to terminology, labels, organization, and even workflow. Our team has tried several approaches for giving input on our products, but none of them are likely to work until we are on better working terms with the development teams. We should talk about how to do that.

3.Articulating our value as a business asset.

Everything is easier when your work is valued. Our manager works on this all the time, and it gets better for us all the time. How can we be deliberate about supporting this effort?

Result: Everything is Minimalism. Discuss.

So minimalism is pretty much related to everything we’re doing right now. It’s the goal we’re aiming for. The three areas of focus above have been areas of focus for a while, but now I have a more clear vision of what the desired outcome is—minimalism. Documentation that gives the clients the information they need, when they need it. “And no more,” as Bernard says.

I’m excited to have a training topic that will be a snap to put together. As much as possible, trainings should meet the team where they’re at. Maybe discussions are where we’re at. There’s plenty to talk about, at least.

How Being an Admin Prepared Me for Technical Communication

I applied to become an administrative assistant because I wanted to get out of the restaurant and into a “professional” environment. That was the reason I gave in interviews. I think I included it in the objective section of the resumes that I broadcasted via Monster and Careerbuilder. Of course, it is possible to practice professionalism in the hospitality industry. What I meant was that I wanted “knowledge work” and I wanted to get paid. Entry level admins don’t really get “paid” in the way I meant, but I saw it as a foot in the door.

I was an admin at my company for six months, on assignment helping in Human Resources. It was a perfect assignment for learning the company. I got to be very aware of which departments were hiring, and I set my sights on the technical communications department. I learned who reports to who. I got some idea of which departments paid how much. Some of the other things I learned turned out to apply to technical communication quite well.

I learned that sometimes it’s useful to do the work that is beneath other people.

When I became a tech writer, the department was still smarting from a long-standing stigma that they were just glorified secretaries—asked to take notes in meetings, “prettying up documents.” These days, we’ve established an ever-increasing cache of credibility, and we can take such misconceptions in stride. You want me to take notes or format a document? Okay, but do you also need a template so you can do it yourself next time? ( Past STC President Suzanna Laurent gave me that idea when she presented to our chapter.) You want to make a doubtful remark about my ability to learn the product? Let me volunteer to log some defects for you.

Someone who knows their stuff doesn’t have to be threatened by doing a little of the work that is “secretarial.” When I was an admin, that was how I learned about the company, and it’s the same now.

Every time I set out to schedule a meeting, untangle a mind-numbing pile of data or log training hours for the group; I learn something about how our systems interact, or about new processes that are coming down the pike. I learn who really signs off on things.

These are tasks that an intern or admin could complete, and maybe that would be something to discuss with my manager long term, but in the meantime I can just take care of it and enjoy a break from the hard stuff.

Leaders serve—they take the project notes, they go the extra distance to help someone who should probably know better. Because people need that sometimes. Why complain about what people should be doing when you can be figuring out what it is they are actually doing, and why they do things that way?

Of course, common sense and your own personality still apply. A writer in our department has been dealing with an obstinate development manager for months, and at the end of their last meeting he asked her to carry a document to a director for him. That’s exasperating, and there are about a hundred different ways to deal with it, depending on your style. But in general, having a chip on your shoulder is just distracting.

I learned how to use Outlook, and how to write an email.

Okay, I’m still learning all the time how to write better emails. I took a pretty good class about email recently, in which I learned many Outlook tips. I say, learn all the Outlook tips you can, if your company uses it from email and scheduling. I get 30 to 50 emails a day, and sometimes more. Anything I can do to efficiently process those and to communicate well via email makes me a more effective tech writer.

Tech writers have to schedule meetings with SMEs. We have to get ourselves invited to meetings that no one thought to invite us to before. The more you can avoid flubbing in Outlook, the more stealthy you can be about getting others to include you.

We’re better now, but our department used to write the longest, most expressive (and therefor most potentially misconstrued) emails in the company, as far as I could tell. I was just as guilty as anyone, although when I was an admin I started learning right away how to get people to read my emails. I had to email large groups of people, or ask a director to review a document. I learned to use my bulleted lists and bold headings.

But this is all elementary to you, so I’ll just share a couple of the most important things I’ve learned, plus a pet peeve:

• I write the shortest emails I possibly can to developers. Most people will prefer shorter emails, but with developers I almost never get more than one question answered at a time. Two questions means no reply, often. Seriously—one or two sentences.
• Learn how to use the meeting features, and double and triple check before you hit Send. There isn’t much that’s more annoying than a screwed up meeting request.
• If a meeting time doesn’t work, always suggest a new time. For the love of Pete, don’t use the Decline feature. Who knows what to do with a declined meeting request? Call me or email me to figure out if we can reschedule. Try using the feature that lets you propose a new time. Declining gums up the works.

I learned how to talk to executives.

Okay, still learning this one, too. By this I mean, being confident enough when I speak to efficiently get my point across. Because those folks are in a hurry and not shy about interrupting. What I did learn right away, because I had to in order to get HR paperwork processed, was not to see them as unapproachable.

This applies to tech comm because we are often viewed as a cost center, so we have to justify our requests. We have to articulate our value using language that decision-makers understand.

Professionalism can be present or lacking in any field, at any level.

Remember I said I was getting out of the restaurant business in pursuit of professionalism? There was a ton of ass-grabbing, boasting, and territoriality in the restaurant, most of it harmless. What bothered me was what I perceived as favoritism and dead ends. I felt like if I didn’t want to be a manager, I was never going to be treated as an adult.

It is different for me working in an office, but it’s just by a matter of degrees. Sexism, favoritism, gossip, racist jokes—they happen in the office, it’s just in whispers rather than in bawdy shouts. For the most part, I prefer it that way. It can be difficult to know where you stand, but should a jerk reveal his or herself, it is more likely to be within earshot of someone who can do something about it. Plus I found myself distracted less often by wanting to respond (I’m fairly confrontational).

There are more career paths, too; more avenues for promotion. So I’ve learned to take the rest more in stride.

After some recent readings (Intercom) I think this applies to Tech Comm in a couple of ways, both having to do with reputation. Complaining about a lack or respect and complaining about work. Both are going to make you look bad. Unless you’re in an extreme situation, there is probably a constructive measure you can be taking.

Building Fringe Benefits into a Project Plan

The Benefits of a Winding Path

In a previous post, I wrote about momentum problems with our team’s help system design project (a.k.a. HD). I am happy with the unexpected benefits and the unexpected learning opportunities that the project yielded, but the amount of time it took still seems inordinate. After posting, I got curious about ways to plan a project while leaving room for those types of fringe benefits.

Here are some of the benefits we got out of spending so much time with the project (and with each other):

• Team building skills
• Consensus building skills
• Client service skills
• Survey-writing skills
• Presentation skills
• Training skills
• Research skills
• Whatever other technical skills necessary to produce the deliverable (our deliverables were XHTML topic templates for each information type, plus methods to guide our team in converting tens of thousands of topics to a new format)

Stopping for Directions

It seems like it would be easier to plan ahead for gaining bonus skills and relationships by being honest about not having them in the first place.

Um, doesn’t that mean you won’t get to participate in the project?

It depends. Is the culture of your team that people are encouraged to take projects in order to grow skills? There’s more to it than cranking out documents to get deliveries out the door—it takes an investment of time to advance the team’s skills. Is it a critical deliverable for a critical client? Is there someone on the team who is already an expert who can take you under their wing? If there is an expert, but they don’t have mentoring skills, what then?

I can’t imagine my manager refusing to let someone participate in a project they were interested in without helping that person find another way to develop the interest. In addition, one criteria for getting promoted is to act as a leader and a mentor. There is incentive to grow these skills. There is opportunity to work on new things. I think these two things work together to make the team sustainable. I know this combination is one of the biggest factors in my having stayed on the team for four years.

Planning Ahead for Detours

After HD, I’ve established for myself that fringe benefits are usually worth the time they add to a project. This week I’ve been thinking of ways to draft a project plan at the outset that I can use to justify the skill development.

List the Expected Deliverables
This and the next item were inspired by GTD, which I read over six months into the HD project. List anything you will be expected to produce for the project, such as training, templates, presentations for each stakeholder group, status updates for the larger team. List them for your manager to make sure your expectations match hers.

This is a good time to candidly discuss with her if any of the deliverables make you nervous. “I’m not good on the phone,” or, “It usually takes Dave and I a while to come to agreement.” You can brainstorm with her how you will address the concern. Do you need to build extra discussion time into the project plan? Do you need to attend your company’s meeting training and agree on a meeting format for the project?

Add the concerns and the necessary time to the project plan. If you’ll have to research something in order make a decision, add time for that, too. If your manager balks at the extra resources, she can recommend another way to address the need.

You can always ask again in the midst of the project if it becomes apparent that you really do need the research or the discussion. I can think of so many meeting discussions that ran over the allotted agenda time when it would have been useful to be able to say, “Our project plan says we will have this decided by today. Do we need to add a week to the time line so that we can have this decided by next meeting?”

List the Criteria for Success
This is also GTD-inspired. We were almost finished after a long, rough ride on the HD project. We were ready to present to the team and start using the new format. Our manager asked us to present to her first. Then she proceeded to rip holes in our design. We spent another month getting the new templates up to snuff because they didn’t meet her criteria.

We should have clearly discussed criteria for each project deliverable ahead of time, and we did at that time. It was frustrating to be having a discussion we clearly should have had at the outset to make sure our criteria met the department needs.

I almost think you can’t be too detailed about doing this. Probably each deliverable should have criteria that you can refer to when you are deciding if the deliverable is good enough.

This Advice Fits in the Glove Compartment

Groan, I know. Sorry. I think what it boils down to is to be explicit at the beginning of a project about what the project parts are and where you will need to develop team knowledge in order to be successful. Then make that development part of the project. Add skill development as tasks and allocate time for it. You might not get everything you ask for, but at the very least you’ll be clear about which team skills you’re developing in this project and which ones you are postponing for another time.

Taking the Bus to Work in a Non-Commuting City

Justifying this Post

Are you ready for my chain of logic as to why a post about taking the bus belongs on this blog about tech writing?

1. If you’re reading this you might be a tech writer or some other kind of technical communicator, or you might care about the field for some other reason.
2. If you’re in tech comm, unless you are specialized, self-employed, or very experienced, you probably make less than many other professionals at your company. According to the STC 2008 Salary Database, the median tech comm salary in my area is about $63K. That’s roughly median experience level, too. So if you are only a couple of years in at a company that doesn’t particularly value tech writers, you are making less than that. Compared to the average salaries that product specialists are reporting on Glassdoor.com or Salary.com, it’s less. I’ll take a guess and say that disparity grows if we’re comparing ourselves to engineers or system architects.
3. Again, since you’re reading my blog about working as a tech writer, I’m assuming that if you are a tech writer, you probably like what you do and want to hang in there until you can make some more money. In the meantime, it would be nice to pay bills and get ahead in your financial life.

A couple of weeks ago I sold my Montero Sport and bought a bus pass. What it boils down to is that it’s such a big change for me that I have to talk about it here.

Taking the PSTA, Leaving the Laptop at Home

The bus system where I live in Pinellas County, Florida is called Pinellas Suncoast Transit Authority (PSTA). I’ve taken the bus a bit in Tampa, Florida, too, and neither system seems to be heavily used by professionals for commuting to work. From what I’ve seen, the bus system is used mostly by people who can’t drive. Either they can’t afford cars or they aren’t allowed to drive. That’s not any different than other cities, except it’s relatively cheap to get a car here. You usually won’t have to pay for parking. Traffic isn’t terrible in most places. It’s doable for many people to have their own cars.

I’ll take some leaps here: that means the income level of those riding the bus is lower than in Chicago or New York, which means the riders are generally going to service jobs and other low wage jobs. Which means if I’ve got my laptop open on my lap while I’m riding I stick out. I really haven’t seen a single other person doing it. And I have to wait at bus stops in the dark by myself—sticking out is uncomfortable at this stage in my commuting experience. So I bring a book or a magazine, instead, for now.

It’s a Little Dirty

The header image on the PSTA site has a woman in a white suit sitting on a bus stop bench, which is ridiculous. Bus benches get rained on, spit on, peed on, spilled on. Kids eat ice cream cones and drip them on the seat. Ants make ant hills on the bench legs and crawl all over the bench eating what people have dripped there. I won’t be wearing white pants or skirts and sitting on bus benches. The only reason I sit on bus benches at all is because I carry a lot of stuff and I want to read my book, and germs are good practice for the immune system, as George Carlin says.

On the bus is not much better. People are smelly. Every round the driver makes on his or her route is a new round of smelly people with their food and drinks. I remember the night I realized that the bus seats were almost as dirty as the bus benches. I wasn’t sitting anywhere near anyone—it was late and the bus was almost empty—but it smelled like pee. Eventually I was the only person on the bus and it still smelled like pee. So I am going to get a little dirty sometimes.

It’s a Little Dangerous

Some of my stops are on road shoulders that poorly lit and don’t have sidewalks. I bought a little flashlight I can clip to my clothes so that the drivers will see me. These are stops that are on roads that are busy enough to be dangerous for pedestrians but too small to get sidewalks on both sides of the road. One could argue that the “dangerous for pedestrians” part warrants the “sidewalks on both sides of the road” part, but apparently there are other criteria.

Sometimes the people on the bus are the scary thing. One of my first mornings riding, an elderly woman asked a big, tall, loud young woman to turn down her music, which was not supposed to be playing without head phones on the bus, anyway. The driver backed her up, asking the woman to turn it off. The woman spent the rest of the ride cussing the little old lady loudly. The lady moved up to the front of the bus, the young woman kept cussing her, and the driver did nothing.

The driver was a short, slight woman in her fifties. Was it her physical disadvantage that kept her from being queen of her domain? I don’t know, but I can imagine it was the type of experience that would make a rider who didn’t absolutely have to be on the bus from using the bus to commute to work.

It’s a Little Unreliable: Also, I’ll Take any Chance I Get to Remind you that Greyhound is Evil

I once used Greyhound to get to L.A. and back from New Port Richey, Florida, and I was appalled. The ticket seller misinformed me, I saw a driver misinform a fellow rider about his bus, and when he misplaced two valuable guitars as a result and became upset, they put him out of the terminal in a strange city. They put me out of a terminal in the middle of the night in a strange city when I had a layover due to their misinformation. An employee let another girl stay overnight in the same terminal because she was flirting with him.

People will keep taking Greyhound even though it sucks because they are the only cross country bus company. As long as people can’t afford plane trips and keep having to travel long distances, Greyhound can do what it wants.

Most of the PSTA drivers have been helpful, but the atmosphere still reminds me of Greyhound, to a lesser degree. If you want to ride Greyhound, you better not ever let your stuff out of your sight, and you have to double check everything you are told. If you can’t afford a car and it’s too far to bike, you better learn the unwritten rules of the bus routes you take.

Some buses run 10 or 15 minutes late, some run 10 minutes early. If the stop is used by multiple routes, and a bus stops that is not your bus, be ready and visible to flag down your bus if it comes while the other bus is stopped—some drivers don’t pull up and wait behind the other bus. They’re supposed to, but it’s the wild west out there.

Another reason I don’t write on the bus is because I have to pay attention. I’m learning the stops and the intersections because I need to know how soon my stop is coming and what street I’m on. The drivers don’t generally call the stops, which is unfortunate. It would be helpful for those of us who are not completely familiar with the route, or who have been reading or talking. On the other hand, I am starting to get more familiar with the terrain between my home and work, which is useful. And by the time I get to work I’m alert and energized.

Chalk Me Up as Eccentric?

I am getting a consistent mixed reaction of admiration and polite incredulity at work, and even one offer of help. I’d bet money that some of those polite people assumed I was one step out of the poor house, or else not allowed to drive.

Credit card debt was part of my incentive, but I don’t have a shocking amount, I don’t think. I sold the car, which was financed, to start making a dent in that debt. I sold it so I could have things that I care more about than the ability to jump in the car any time I want without planning responsibly. Things like a nice wedding present for my sister, and the STC Summit in May. The day I sold my car, I filled out a 401K form so I could start maxing out the employer match again, like I used to before my ex and I split up and I got my own place. I sold my car to get breathing room and peace of mind and other stuff that I enjoy more than traffic and hating on the slow drivers in front of me.

I’ve only been a tech writer for a few years, but really, I make enough as a single person without kids to get by and have some nice things. I just can’t have everything. So I have ditched my car for the time being.

Okay, Now for the Tips

I’ve had a little bit of experience on buses in various cities, but nothing this hardcore. Some of these I stole from my Chicago friends. If you have more, let me know in the comments.

It’s all about gear:

• In Florida it’s rain gear: umbrella, hat, pants, coat, boots. A trash bag and towel at your desk for the rain gear.
• Comfy shoes to walk to and from stops, and to walk to lunch.
• A place at work to lock up your laptop somewhere instead of taking it home.
• A small flashlight or a flashing light like bicyclists use. That way the bus driver can see you well ahead of time at night and you can see in your bag to find your bus pass.
• A cell phone. A smart phone is nice, since you are saving so much on gas and insurance. Then you can tweet and look up bus routes.
• Good coffee that you can make at work, since you won’t be stopping at Starbucks on the way in.
• Change to buy a newspaper.
• Individually-wrapped hand wipes.

Bonus tips:

• Talk to the bus driver if you’re not a hundred percent sure about your stop or your transfer. If he or she is not super nice, other riders might be able to help. But I think bus drivers are mainly pretty helpful.
• Do not sit anywhere near the sleeping drunk people. They have gas.

How do You Make a Team Project Move Faster without Formal Authority?

No really, how do you?

Our team has had a committee working on help design (a.k.a. HD) for a year and a half.

Yesterday we unveiled the department desk reference topics for the new format. I fired up the projector, showed that the new book had been added to the TOC of the desk reference WebHelp file, and then outlined each part of the new content: concept and task topics about using the new topic templates, converting legacy topics, and structuring a TOC.

It took nine minutes.

We’ve already presented several times on the new format. Only two people have used it yet, one of whom helped design it. We don’t have trainings developed yet. I considered yesterday’s introduction a formality; a heads up that the desk reference has the info and a chance for the team to ask questions.

Our manager explained that she won’t really be pushing for people to implement the new format until we’ve had formal trainings, which the HD committee is charged with developing. Someone asked, “When will we have the trainings?”

“Um, well, we just started working on them, but the goal is to have them as soon as possible.” I am well aware that this is not actually an ETA, and I look to the other committee members for help. But by now I think they are pretty used to letting me talk in meetings, and they are apparently comfortable with letting this statement stand without amendment.

My manager tries a different angle. “Do you have a ballpark idea? Will it be a couple of months? A couple of weeks?” I know she is hoping I’ll say a couple of weeks, because it’s time for us to implement this format, already.

But until last week, the committee was completely focused on developing a great demo to sell clients and internal stakeholders on the new format, and before that milestone we were completely focused on finishing the design.

In order to get momentum on the trainings in last week’s meeting, I launched right into the “how” discussion and skipped over the “when” questions, which tend to stall us. And by now, I know better than to estimate an ETA for our group without discussing it with them first. They are apparently not up for discussing it right then in front of everyone. So I hem and haw a bit and then the meeting is over.

I’ve come to two conclusions as a result.

One, I’d like to pick dates for the trainings—aggressive ones—and work towards them. I think we’re at the point in the project where we should be able to do that.

The question is, how do I help the rest of the committee be confident in an aggressive date and willing to adopt that sense of urgency? So far, the only idea I have is to ask my manager to impose the dates. I can look at our training calendar and look at how soon we’re wanting to implement and see which dates we should choose. I can accept “good enough” over “perfect” in order to meet those dates. But, historically in HD, I can’t make the rest of the team see what I see on the calendar.

I think that, ideally, we would have had a project plan with a set amount of time for each milestone. We definitely took the meandering path, which let us reap some benefits that we wouldn’t have thought to include on a project plan. My guess is that this long finish is part of the price tag on that.

Two, I want someone else to take a turn at representing us to the team.

I’ve had plenty of practice and it’s time for someone else to work on that skill. I guess I’ve been hoarding it, in fact. The result was yesterday–crickets from both sides of the room. I just wish I would have thought of that before the end of the project. Any suggestions on passing the torch?

P.S. I am pretty excited about developing the trainings, actually.

It’s new for me, and I want to try out some ideas that my Twitter friend, Julio, recommends in this post.

Julio has instructional design background, and we’ve been chatting about tiered training. Tiered training! Twitter helped me find a way to squeeze that skill into my current job description. If you need more reasons to finally get on Twitter, read this post by Penelope Trunk.