Where is the best place for the users’ advocate to sit?
“Best” meaning the spot where a tech writer can create, curate, and deliver the most helpful documentation with the least effort.
“Sit” meaning… well, actually sitting (or standing) at a workstation on-site. Remote work is a viable option, of course, one that more and more successful, segment-leading companies embrace, but I’ve already written about the advantages and challenges of working remotely as a users’ advocate.
I judge locations loosely according to the following criteria:
- Access: How easy is it to interact with people, not just to get information but to nurture relationships with key colleagues?
- Facility: How easy is it to attend gatherings and meetings (scheduled and ad hoc), and participate in process ceremonies?
- Visibility: Do your coworkers see you? Your coworkers need to know that you’re a part of the team.
- Intangibles: What other advantages or disadvantages does the location bring?
Here are my spots ranked from worst to best.
Another floor or another building
This is the absolute worst: a location with all the challenges of working remotely and none of the advantages.
When you’re offsite, your company usually supports you with the communication and collaboration tools you need. Your coworkers know your circumstances and are more likely to interact with you through those tools.
When you’re onsite but distant, you are effectively working offsite, but without that valuable support and understanding. You have no chance to catch folks in the halls or in the breakroom. Your interaction with coworkers can easily attenuate down to emails and voicemail. Plus you still have to commute, with all the costs in time, cash, and sanity.
When I was relegated to a distant floor, I quickly learned that emails and voicemail weren’t enough to do my job efficiently. So I planned expeditions into my sources’ territory. I didn’t rate a company-issued laptop (and these were the days before tablets and smartphones), so I carried spiral-bound paper notepads everywhere. I assigned each product its own notepad, filling them with scribbles that I’d transcribe later in my writing cave downstairs. I still produced decent doc, but it wasn’t efficient. I felt like I was building LEGO while wearing oven mitts. It sucked.
Non-product group (Accounting, HR, Facilities, etc.)
At least you’re on the same floor or in the same building, but through some quirk or oversight, you’re sitting with administrative staff far away from the people who work on the stuff you need to document.
On the plus side, you get to know folks who can make your life at work a bit easier. HR is your source for benefits, hiring, and visa issues. Accounting handles payroll, tax withholding, and expense reimbursement. Facilities personnel control your workplace environment. Don’t discount their powers. Try working a day under flickering lights or under a vent blasting super-chilled air. A comfortable tech writer is a productive tech writer.
All these perks are great, but they have little material effect on your documentation, unless you work on projects related to deploying accounting or HR systems
One potential negative to look out for: Your coworkers can be very status conscious. To these folks, where you sit indicates your place in the corporate hierarchy. Sitting with “low class” employees confirms your insignificance and governs how they interact with you and how they prioritize your requests. It’s not fair or right, and I hope you can change your circumstances in the long term, but sometimes you have to play the hand you’re dealt.
IT
You’re still not sitting in Product Land, but now you’re among techies.
If you work for an XaaS software company (SaaS, PaaS, IaaS), sitting with IT folks, listening to their conversations, can give you a “behind the curtains” view on the technology that drives your company. This backstage pass can help doc for deployment, configuration, or integration. For end-user doc, not so much.
IT folks hold the keys to the server rooms, literally. If you have a good relationship with IT, you can maybe negotiate some leeway with computing resources for a tech writer in need. For example, when I wanted to build a static site generator for internal doc distribution, I asked one of my IT pals for advice. In short order, he set up a virtual machine in an appropriate flavor of Linux as a sandbox for my development and testing.
Sales
Sitting with salespeople can be a lot of fun. In my experience, they tend to be outgoing, gregarious, and engaging.
Salespeople can also be instructive. Their conversations and phone calls provide insight on your product and its strategic direction, demonstrate how it’s pitched to prospects, and can give you a rough outline of customer personas. I’ve used all this sales intelligence to inform my doc planning and priorities.
Most successful salespeople learn that good doc is also a good sales tool. My salespeople are always hungry for customer-facing doc, and I regularly field questions like “Do we have a user guide/install guide/any doc at all for Product X?” I deflect about 90% of these queries into my doc distribution system. The other 10% fall into these categories:
- No because [reason].
- No, but that’s a good idea.
- What the heck is Product X?
Categories B and C have resulted in some of my most rewarding doc projects.
Regarding category A, I’ve politely declined urgent requests for doc from salespeople because the doc would be too narrowly focused on a single prospect. Salespeople need to make their numbers, I understand that and I want to help, but I have limited resources and all my other users to consider.
Near a busy meeting room
You may not be where the product is being built, but next to a meeting room you’ve got a court-side seat to gatherings, from regular stand-ups and group meetings to impromptu, ad hoc get-togethers. And you never have to worry if someone forgets to invite you because you’re already there.
I’ve found that catching folks in meeting transitions, especial post-meeting, is the most productive. A quick, dynamic walk-and-talk can answer a lot of questions and break down a lot of barriers. Even when I don’t get a solution on the run, I feel I’ve raised the issue face-to-face more effectively than a Slack DM, email, or dreaded voicemail.
At one of my first jobs, sitting near the meeting room meant also first dibs on leftover food and drink. The morning bagels and afternoon sandwiches didn’t contribute directly to the quality of my content, but a happy tech writer is a productive tech writer.
Open plan office with line-of-sight to key personnel
I hear a lot of complaints about open-plan, but it works for me.
I can keep tabs on key people much like sitting next to a meeting room, but with line-of-sight, I’m more proactive, prairie-dogging up from my workstation and scanning for high-value targets. I spend more time getting answers and writing doc and less on waiting for responses via email or Slack.
In open-plan, my greatest enemy is the Bluetooth headset. I’ve lost count of the times I’ve walked briskly across the building, excited to get answers, only to find my target on a call. At least it’s good exercise.
Project Management
Project managers and scrum masters keep the cadence of the team with scheduling, communication, and coordination. They keep development chaos at bay. They herd the cats.
Sitting with project managers elevates my doc because I can focus on the content instead of coordinating and reconciling schedules between individuals and teams. After checking our project tracking tool, I can clear up any ambiguity about the status of a project or a feature with a quick question.
Critically, project managers can be your greatest allies when you need to integrate doc into the development process and make sure that the definition of “done” includes doc. For example, when I needed a custom field added to our issue tracking system to record doc requirements, it was an easy ask. The project manager immediately recognized its value, added the field herself as I was standing at her desk, and then introduced the new field and related process at the next team stand-up.
Engineering
Sitting with the engineers looks like the obvious choice for best spot. You can keep tabs on who’s in the office with a glance. Your subject matter experts are only a short walk away.
Because you sit around with them, the engineers see you and grow familiar with your presence. I leverage this familiarity to drop-in on development meetings for reconnaissance. Folks rarely object and if they do, they’re worried I might waste my time. I prefer to be the judge of how to best use my time so I stick around. Sometimes I learn essential product details, sometimes I gain valuable insights into the dynamics of the personalities in the team, and sometimes it’s a bust and I move on.
Sitting in engineering territory gains you another benefit: status by association. Those status-conscience coworkers, the ones who thought less of you for being seated with HR and accounting? They’ll be less of an issue if you’re sitting with the engineers.
So why isn’t Engineering the best place to sit?
First, consider that not all engineering is created equal for the needs of the users’ advocate. If you sit with folks working on deep infrastructure or a performance project or materials testing, your users aren’t going to benefit from your exposure. You want to sit near the folks working on the stuff that you need to document.
Also, developers and their managers focus almost exclusively on product and schedule. I’ve found that most engineers can talk about the “what” and “how” of their work, but I have to look elsewhere for the “why”. The pressure to deliver can skew their priorities, causing even the most enlightened engineers to demote doc because they forget that the stuff they build is used by people who don’t know as much as they do.
Support
When I sit with Support, I feel like I have a window onto our users’ experience. Of course, the view is a little distorted because Support only hears from users in trouble, but these are the folks who need my help most. The conversation embedded in every support ticket represents an opportunity to learn and to apply that learning by improving the doc.
Working with Support, I transform user frustration into user success. For example, our users foundered repeatedly on a complex bit of functionality. A small configuration change one way or the other could mean a big profit or big loss for our customers. So what did we give our users to navigate this critical business decision? Over 50 pages of tables.
My Support team called me out on the mess and suggested that we collaborate on a solution. Our work resulted in a tight, 13-page tutorial and one of my most rewarding doc projects. The doc didn’t magically solve the problem. The functionality was still as complex and users still called Support, but now we had a step-by-step guide that our team could walk users through and that users could refer to in their time of need.
Product Management
Product managers straddle customer needs and engineering, unifying them as they deliver a successful product. By nature, they’re cross-functional, invested in what your engineers are doing, what marketing is touting, what sales is selling, and how successfully your support team is supporting.
This is my favorite place to sit. Product management is where I get the “why” that’s so often lost in the rush to “what” and “how” from engineering.
The “why” is harder to nail down than the “what” or “how”. The mechanical details are evident in the product itself, in the user interface or in the code: “Click Aggregate to combine your pricing streams.” The underlying motivation, however (“Why do I want to combine my pricing streams?”) can be hard to divine and is essential to holding your users’ attention and leading them to success.
Yes, the “why” should be captured in the issue tracking system or in code comments. In the real world, they often aren’t. My product managers readily fill these gaps when I point them out. Sitting with them means they fill the gaps more quickly and thoroughly than through an email exchange. Armed with the “why”, I better identify with my users, engage my empathy, and ultimately deliver more helpful content with as little friction as possible.
And as a bonus, nearly all product managers I’ve worked with have been cracking good engineers, so I can often get a lot of the “what” and “how” as well.
Wrap Up
So what can you do with all this information? What’s the point?
The typical employee has very little control over where they sit. I don’t advocate rebellion and revolution if you’re not seated where you like. Instead, develop your own justification for location based on your experience, your working style, and the needs of your users. Use this rationale when you do have the chance.
For example, when you’re interviewing, as you and a prospective employer are learning about each other and assessing each other’s suitability, ask where the writers sit. You demonstrate some good, solid, practical interest by asking, and you can learn a lot about the company from their answer.
Reorgs and relocations happen. I’ve been through at least 10 over the years. These difficult times are an opportunity for you to lobby hard and to educate folks about your work and the best place to do it. Talk to your HR crew. Talk to your managers. Let them know that you don’t just sit in a quiet corner beautifying specs. Make it clear that you’re not angling for something frivolous like a corner office or a cube with a view. You are a cross-functional content wizard advocating for your users. Where you sit helps you do your job effectively. Where you sit matters.
