The Proximity Problem for Technical Writers
Last year I wrote a series of posts about moving from the sidelines to center stage. In the series I described how I transitioned from a low-key, hardly-speaking project member to a key player on the project team, someone with a voice that mattered in project decisions. But recently, with some projects, I’ve come full circle, moving back to that initial position of a fly on the wall.
The changes had a lot to do with location. Previously, each technical writer was embedded in a specific group. Most of us were stationed on different floors, in proximity to the developers, interaction designers, quality assurance engineers, and project managers for each project.
This proximity was useful for staying in the loop with project information, but it did nothing for our technical writing team. We used different tools, didn’t follow a common style guide, and came up with our own processes and content models.
Because we wanted to try to build some momentum towards standards, we decided to consolidate our group, sitting together in the same row of cubes. We were no longer embedded within specific project teams, but rather centralized as technical writers in a common location and shared throughout the organization.
In the previous embedded-writer model, I looked longingly towards our once-a-week meeting with technical writers, holding it as the highlight meeting of the week. But now that we were sitting together, it was like a team meeting all day long. Coordination and morale skyrocketed.
As the weeks passed, we started to form some standards. We decided to standardize our toolset, first of all, so that in case one writer won the lottery and left the organization, another writer could seamlessly fill the gap. After weeks of research, and through the luck of another group that already purchased the solution, we adopted and implemented a new help authoring system. We then attacked our style discrepancies, and quickly adopted a 42-page guide of stylistic decisions.
We were gaining momentum fast, and acquired our own servers to run help, injected a documentation template into the project manager process, formulated a content model for help, designated a team member to be the tools administrator, and more. We were flying as a team. We even stopped holding team meetings because anytime we needed to meet, we could just swivel our chairs and raise an issue. Our close proximity led to a brilliant flow of communication.
In the back of my mind, I knew that we had lost some rapport with the project teams that we no longer sat next to. But it didn’t hit me how detached I had become until, about a year later, I attended a two-hour meeting with one of my projects and found that I had nothing to say at all. All the momentum I had previously accrued as a key project voice seemed to slip out from under me.
Proximity and Communication
Sitting silently in the project meeting, not contributing towards interface text, nor quality assurance, nor jumping in on broken functionality, nor even on training strategies, I realized that my sacrifice of proximity with the project team had resulted in my impotence on the project team. I no longer had the same voice, nor was I someone anyone paid attention to. I had become that quiet fly-on-the-wall technical writer, the one whom no one expects anything from except a help file.
I’ve learned that proximity to any team makes an incalculable difference in the role you play with that team. Grouped together with other writers, we actually formed standards for the first time in years. We felt like a team. And separated from project teams, I fell off their radar, and they off mine.
This, then, is what I’m calling The Proximity Problem. The closer you are to a group, the more you interact with that group. But you can’t be everywhere at once, so you have to choose the group that gets priority. Given these dynamics, is it better to be embedded within project teams or within a technical writing team?
Comparing and Contrasting Benefits
Embedded within project teams, I did much more than technical writing. I logged bugs, critiqued designs, guided project managers with feedback from users, and was generally go-to guy for new team members who want to ramp up on the project. I became a subject matter expert on the app itself, which led to my being a key member with a voice at the table.
Embedded within the technical writing team, I didn’t get sucked into all of these secondary roles. I could focus on my primary contribution: the help material. But not having involvement in other aspects of the project, such as the design, testing, interface, planning, and so on, made it harder to write help. I was often a latecomer to information, finding out at the last minute about upcoming releases and stumbling into new pages with changed functionality.
Sitting with my colleagues is heavenly. We understand our kind. We engage in heated debates about style controversies, and sometimes crack jokes about how bad interface text is. We ask each other questions about Author-it and Camtasia. One of my colleagues even brings in peaches to share, and has his own candy store. It’s comfortable to sit with them, and share in the camaraderie.
But in the larger scope of agile development, this isolation from the project conversations that are happening on an ongoing basis seems to have negative consequences. The isolation away from other writers, as I sit near developers and other IT members, might be worth it for the end result. The problem is that projects are often short durations, so I would need to be nomadic for the model to work, moving from one project group to another as my project load shifted.
Perhaps nomadism would be ideal for help authors. When working on project X, sit next to project X. When working on project Y, sit next to project Y. And yet, even despite the improbability of such an open seating model, it seems archaic in a day of virtual collaboration and remotely located workforces. Why insist that maximum productivity is only gained by rubbing elbows with your team all day long? Surely asynchronous methods of communication, real-time online interactions, and regular meetings using VoIP or the telephone can compete with the benefits of nearby seating.
Alternatives to the Dilemma
Despite the logic of embedding myself with a project team, where very likely I’m the only technical writer present, I’m not ready to give up our new-found team momentum. We’re making a lot of progress towards standards and tools, processes and styles. Once the dust settles, we may return to our former model in which we’re embedded in project teams.
Still, perhaps I’m holding out for another reason: I’m not convinced that proximity is essential to keeping up with project information. I’m not persuaded that there aren’t equally viable ways to gather the same data and interact, because if nothing else, the Internet has shown us how remotely distributed people can be closely connected with each other. The Internet has pulled us loose from our physical relationships, distancing us from those immediately around us and drawing us closer to others whom we never see or speak with. Email, instant messaging, Internet Relay Chat, webinars, podcasts, blogs, websites, text messages — all of this enables communication to take place despite physical boundaries. Theoretically, proximity shouldn’t be a problem. But teams who already enjoy proximity have no need for virtual communication tools, so outsiders often feel the need to participate in close proximity model to keep in loop.
It’s true that proximity does lend itself to more immediate updates. When you’re sitting next to a developer and he makes a shout of joy when he gets something to work, you’re updated. When you’re sitting next to a tester who groans each time she finds another bug, you’re updated (that is, if you ask what the commotion is about).
But it’s still possible to stay updated sitting remotely, away from project teams. And this is precisely because nearly every team in most IT groups uses some form of bug tracking tool, such as JIRA, Team Foundation Server, Fogbugz, or something else. Nearly everything gets logged somewhere, and if we take the time to stay close to it, to follow it as carefully as we might read a novel, tracking comment threads, attending meetings, reviewing sprint plans and roadmaps, checking IRC logs, design and requirements documents, listening each day to scrums — if we did all this, we could circumvent the proximity problem and perhaps even stay more aware than team members in the same cube aisle. That is, as long as distance doesn’t deafen our ears, make us forget our priorities and workloads, and lull us into a false belief that nothing much is going on.
![From Overlooked to Center Stage [3]](http://idratherbewriting.com/wp-content/plugins/related-posts/static/thumbs/28.jpg)
![From Overlooked to Center Stage [11]](http://idratherbewriting.com/wp-content/plugins/related-posts/static/thumbs/29.jpg)
You make an interesting point. My developers are located primarily in China, so I don’t even get to participate in daily scrum meetings. This is a huge challenge because despite the volume of collaboration tools available, we always seem to fall back to email.
Lately, I’ve been logging in before I go to bed, which is typically when the China crew is starting their day. I frequently have instant message conversations that go a lot further than email for clarifying points where I’ve become stuck.
I totally relate to your dilemma. I’ve spent most of my tech writing career as a sole writer embedded in project teams of various kinds, and there’s plenty to be discontented about in that role. It’s much more comfortable, glorious even, to work with fellow writers. As you point out, that kind of peer interaction is a help in setting standards, introducing new approaches, and so on. Frankly, even maintaining standards is hard in a all-tech environment where no-one has heard of, let alone cares about, an Oxford comma.
Nevertheless, I think the embedded model is best. If you want to get involved in interface design, or business analysis, or content strategy, you’ve got to be plugged into the technical side. Tech writers are often highly qualified to lead in those areas, and I think more and more of them are moving towards those fields. Another issue is that, typically, the tech side has more visibility and gets more respect within the organization.
This is all from the writer’s point of view. From the organization’s point of view, I’d say the embedded model rules. I mean, what’s a bigger problem in tech comm: insufficiently cutting-edge tech writing methodologies, or writers who don’t really understand the subject matter or target audience?
The ideal situation would see the writer collaborating with both sides. One or two days a week with other writers, the rest of the time with Dev, sounds perfect to me.
About proximity: when you’re sitting with people, you communicate with them in all sorts of informal, even haphazard ways. Collaborating at a distance, you only know what someone chooses to tell you, what’s available publicly, and what you explicitly request. There’s a danger of being left out of the loop. I think this is greater with the developers, since you may be naturally somewhat estranged from them. With other tech writers, since you’re probably on the same wavelength, you’re much more apt to reach out, even when you’re at a distance.
Christopher, what you say makes a lot of sense.
I also like your suggestion of splitting time between the two groups. It is a tough decision to make. We may eventually return to the project-embedded model, especially once we have some of our team standards nailed down.
Very interesting. I face a similar dilemma as a trainer/tech writer. Currently, my desk is in IT where the action is taking place. However, the folks I support…are across the street. I’ve started to use a pedometer to see how much I walk back and forth.
It’s impossible to be everywhere at all times so I have to focus on the task at hand and the correct location for it.
Good post!
Love Christopher Burd’s comments and experience. Proximity is a difficult dilemma especially as part of two different communities. In this day and age it seems we should be able to find ways to interconnect and not be so siloed, but, as always, application of the concept is more difficult to implement.
‘Embedding’ is a luxury that has never been offered, and is probably a poisoned chalice.
Supporting several products in parallel is an exercise in keeping proximity to the product development team timelines. They’re customer-focussed, and where the deadlines live.
Pure-play Agile has nothing whatever to say about new product development, but has everything to say about efficient code development. A dev manager can talk sensibly about doing Agile delopment, but if you hear a product manager talk about doing Agile development that person could be:
* deluded.
* covering (Agile teams often seem a law unto themselves).
* talking buss-word bull-feathers.
* paraphrasing a wider management philosphy.
Notice that only one of those makes any sense.
Do I enjoy proximity to other writers? Of course I do. With project teams? Of course again. Would I always choose one above the other? Nope – depends entirely on what I’ve been asked to do. That changes with every project I take on, just as it should.
m, thanks for your comment. I like your point here:
The difficulty of the problem increases when we have multiple projects we’re supporting. If we’re documenting 3 different systems, and all of the teams sit in different locations, there’s no easy way to be close to them.
I’ve currently got the best of both worlds: I’m embedded within an Agile Scrum team of developers and testers. We all sit in a giant “horseshoe” cubicle in a large open space next to five other horseshoes with a scrum team per horseshoe. Communication is VERY open (sometimes a little too open, such as when mass debates or nerf wars break out, and people who need to get a lot done have to hunker down with noise-canceling headphones).
My fellow tech writers are just one horseshoe over, and we also meet regularly as a documentation team, reviewing each other’s work and collaborating, so we keep the team rapport up on that side as well. I find this is the ideal setup for a small to mid-size company that’s all on the same floor of a building.
Horseshoe cubicles! that sounds interesting
Yes, that would be ideal. As you say, this would work for small to mid-size companies. In my organization, we have four floors of people.
Hi, Tom–
I just logged a bug this morning and spent an hour going over our support teams list of needs prior to a mid-October release. I am the only technical communicator in our company and “being embedded” with development is my “location of choice.” I remember the good ole’ days when I worked on a large technical communication team where we, as you describe, swiveled our chairs around for impromptu meetings.
My preference, having lived in both worlds, is to be embedded with development. I crave the credibility, accessibility, and relevance that I am granted as a member of the development team.
Thanks, I enjoyed reading your post.
Thanks for commenting, Marj. You mentioned “credibility, accessibility, and relevance.” These are hard wins to give up by consolidating the technical writers. Lots to think about there.
As a lone writer, I sit among the developers, which I consider ideal. I’m right there where the action is.
I’m currently embedded in an open office with 12 developers. I’m the sole Technical Writer and I was just moved from a closed office, shared with one of our trainers. I prefer being embedded with the Development team, despite a cacophony of Nerf wars, smart phone debates, and broken code cursing. My work cycle is closely bound to the development cycle and if I’m not running with the team, I lose my way quickly. However, I do miss the customer perspective I got from our Training department. Developers tend to be out of touch with customers, especially when developing for a non-technical audience.
The best configuration I’ve experienced was with a larger company where we had a Technical Writing team that shared an open office. This is where all the writing, standards, and HAT talk happened (oh, how I miss it). The company employed an Agile Development process with several small project teams. Every project team was assigned at least one developer, a QA tester, a project manager, a product manager (who acted as the customer), and a technical writer. The project teams had short, semi-daily scrums in which each member could fully engage in the development process and build relationships with other members of the team. I do not believe such face-to-face meetings can be replaced by instant messaging, video/telephone conferencing, etc. Proximity matters. There’s just something about being in the same room together that builds camaraderie and effective collaboration.
Dan,
Thanks for commenting.
Well said. I wish I knew a better workaround, but you’re right — as much detail as one gathers from bug tracking tools and daily scrums, when you’re not embedded with the project team, you just miss out on a lot of information.
I have worked in both the environments and would give thumbs up for the option of Embedded in Project Team. The key issue is how the Project Team welcomes a technical writer and values them setting *with* them. I worked for a company “A” where a technical writer was listened to, and the inputs were appreciated. The project plans were a collaborative effort, the UI was discussed, and the environment was vibrant because of diversity of viewpoints. Then there was another organization B where a technical writer, even though as an embedded project team member, was given Minutes of Meeting (in a very poor document) to share the *decisions*.
I would rather have a hybrid model where a writer is *Embedded in Technical Writing Team* which inturn is *Embedded in the Project Team*. Provided, it is possible considering the space/structure limitations of office.
Tom, like many of your posts, one of the best and most insightful posts. It talks about the mental challenges and adjustments that writers need to make, while developing documentation.
Cheers!
Thanks for your comment, Vinish. Re the best of both worlds, embedded in a tech writing team that is embedded within a project team, that could work for larger projects where there are multiple technical writers. Unfortunately most of my projects are solo tech writer projects.
I face the exact dilemma in my workplace today. I recently moved to a new organization. Here, Technical Writers sit together on one floor as opposed to sitting with the dev adn QA team.
Even though what you say about all the tools, systems and apps available with the writer, the physical presence matters the most. Most bonding with the Dev and QA folks would happen over the Tea/coffee breaks we share, the sweets we get for the team to celebrate occasions. I have always seen that informal (in the professional realms) relations with the dev and QA help me get information much more than any scrum, any formal meeting. We can always visit their desks to ‘chat’, or ask them to come over and have a look at our problems and issues in the application.
I found it easy to find bugs, UI and usability issues when I am using the application and the developer or QA is telling me that I am wrong, or I don’t use it the way it should be! and then the ‘user’ in me tells them problems I encounter.
Proximity always would help. Either you sit with the project folks or with the writer folks,people who sit next to you will be boards to bounce our ideas
Having said all that, I also believe that since we are communicators, we know how to establish rapport with the team. What stops us from visiting the project folks every now and then to catch up outside the meetings and conferences? This kind of informal communication practices will always succeed over formal meetings.
Shweta, good point about the camaraderie and relationships that develop from proximity with the dev team. Those relationships can be essential to getting information. I agree. I overlooked this element in my post. Thanks.
Great post that brings up some larger issues besides just “where to sit”.
Where you need to sit depends totally on how you define your role. If your purpose is to “develop the help system” then you are best off being with the other technical writers so that you can standardize your tools, processes, and deliverables. This will maximize your efficiency at delivering the “help” materials.
But you might take a different view. Your role isn’t to “write the help,” it is to make the product succeed. If that is the case then you want to be as close to product development and actual users as possible. The only goal is to help users be successful with the product, regardless of the tools, methodologies or deliverables used.
If your product team feels like your purpose is to make the product succeed then you will earn their respect, you will have more input and the effectiveness of your ‘help’ system will improve because it has to in order for you to stay relevant.
You can’t optimize for everything. You have to choose. Just make sure that you are optimizing for what matters most.
Greg, good points. “You can’t optimize for everything. You have to choose. Just make sure that you are optimizing for what matters most.”
I think that what really matters most is proximity to the actual users, now that I think of it. Proximity to users matters more than proximity to the dev team. If I were optimizing, this is what I would value most.
What you have describe here is something I have observed over my career in every organization I have belonged to or worked with. I think of it the great circular migration pattern of the tech pubs function.
Over a multi-year cycle, tech pubs tends to wander among engineering, marketing, training, independence, and outsourcing, never finding a comfortable home anywhere.
The reasons for this migration pattern are several.
* Tech pubs is not a core competency for a product company, so modern business thinking suggests it should be outsourced. But tech pubs needs such an intimate flow of information from engineering, that it is hard to make outsourcing work.
* There is no glory to be had in tech pubs. There is no career path from tech pubs into upper management. Consequently tech pubs managers tend to have little clout in the organization, and if not protected by a larger department, tend to have their resources stripped away.
* Tech pubs is a cost center, and tech writers tend to be very weak at determining and demonstrating how they contribute to the bottom line. No department, therefore, is reluctant to have tech pubs taken off their hands.
Nobody really wants tech pubs, and when it becomes a separate entity, it is generally too weak to sustain itself, and so the tech pubs function wanders slowly through the corporate landscape.
For my money, however, the right place for tech pubs is in engineering. That is where you have the best access to the information you need to do the job, and where you are most likely to have some influence beyond the sphere of pubs itself (which is essential if you want to be valued by the wider organization).
At those points in my career where I have managed tech pubs departments, I always insisted on reporting to the Director of Engineering and in having the writers who reported to me being distributed among the developers rather than gathered in one place.
Mark, very insightful. Thanks for sharing your learning from years of experience in different organizations.
This is a really interesting point. I think you’re right about it, and it’s kind of frightening, actually. A centralized tech pubs dept is too weak to sustain itself without support and integration with engineering. I’m already thinking that I need to re-embed myself among project teams.
Mark, I was thinking today of your reply to this thread.
This is proving to be more and more true right now. We are withering ….
Engaging and well-written post. On most of my projects so far, I’ve been the only team member in my office. It would be great to rub elbows with the team, but it’s just not realistic. We have to learn to adapt to the distance. I am located in a tech comm group, however, which I enjoy.
I’d sure like to know what help authoring system you decided on and why!
About proximity — virtual versions thereof will not win the confidence of those empowered with forming and constructing the product. For that you need to be across the table, looking them in the eye.
John, we decided on Author-it, mainly because another group was already implementing it, and it seems to address most of our requirements.
Re the confidence and trust that develops from close proximity, you’re right. That kind of trust can’t develop without being near the people you work with.
I have had good and bad experiences in both scenarios. One thing is true, Tech pub team get very little budget for R&D, tool licenses etc. However if we are part of the development team, there is less convincing required to get to upper management as we become part of overall budget. I once worked in a company where technical writers had to share computers with night shift support staff as a cost cutting measure.
You do tend to feel under valued. When we were researching on help authoring tools, we heard responses like ‘documentation does not fetch money in itself etc’.
Also it tends to look too easy when engineers dont see the effort you put in information gathering, researching, understanding how products work etc when your sitting away from them in a different team. They just see a bunch of documents for review and think it is probably much easier and less effort than designing, coding etc. Sometimes we dont have a choice and I always recommend if not with product dev teams then please make your presence felt.
Sitting with development teams always gives you an idea about the big picture of what is happening in the product line, the road map of the product itself. Such knowledge is always important for survival. The little bits of information we gather by sitting with people who are creating the product for we are going to be the first end-user is priceless.
Interaction with tech writers however is also important and must be done on a regular basis over meetings etc.
LC, good points. I especially liked this one:
I think this observation is spot on. When people don’t see what you do, they wonder why it’s taking so long. It’s hard to communicate this virtually.
I’ve put a lot of thought into this very subject, and it’s the same across all different industries. Do you locate engineers of the same discipline together or have them co-locate on their projects? The proximity factor is huge.
Another observation is that if no one is anywhere, then the collaborative tools work. I participate on the Mac Roundtable, and we are located all over the world. no one can turn their chair around and start a conversation, everything is virtual, and that makes it work. This may be the long term future which would make the remote worker not the outlier but the norm.
I’ve also thought about having an organizational model that says you plan ahead of time to flip the org 90 degrees every 2 years. So in your example, all the tech writers are organized and sit together for 2 years. They move from silos to shared standards and become a smooth machine. At 2 years you flip it, so all tech writers report into the project functional organizations. For the first year, the tech writers will still remember the relationships and follow the standards, as they become reacquainted with their customers in the program. At the end of that 2 years, it’s flipped back, and for the first year the tech writers remember their customers as they reset their standards and processes.
I like this model because it’s what we do ANYWAY, we just do the flipping chaotically, disturbing the people and organizations. If we planned it to flip every 2 years, then the consternation and lost work because of fear, uncertainty and doubt would be minimized.
like I said, I think about this a LOT.
Allison, thanks for commenting. The flip-every-two-years model is interesting. About every 2 years a company undergoes a reorg, and this may be a natural swing of the pendulum. I hadn’t thought about actively doing it, but it seems like an interesting and possibly effective strategy for getting the best of both worlds.
Interesting stuff. The danger of writers sitting together is that they become over-enamoured of their toolsets, their gerunds, their style sheets, etc., and lose sight of the absolute need to bang out useful content. I’ve known several authors more interested in methods than output.
I agree that it’s easy to become too focused on these smaller matters when you’re surrounded by people who also care about them to such a great degree. It can lead to a false sense of importance on non-business value matters.
I also experioenced both cases, part of tech writers’ team and part of development team. What I enjoy most? Development team. Why? Taking part in the development team not only people think I’m a person important within the project and they really do understand the importance of well-written documentation, but I am informed about project/product new requirements which allows me to better understand requests. Of course it is important to be part of a Tech Writing team, but from my 4 years experience in such environment I was very surprised to see how Tech Writers colleagues did not missed a change to prove how great they are to the upper management. In my opinion being part of a tech Writing team means working together with colleagues to continuosly improve documentation and the TW process. So, it all depends in teh working environment, in the company values, people culture, etc.
Oana, thanks for joining the conversation.
I think you’re right in that proximity to the TW team leads to more efficiency and development of the TW process, with less attention paid to the products we document.
Tom, I’ve said this in private to you and I’ll repeat it now in public: The middle ground is the best option, a proximity somewhere between dev, the customer (which I don’t think you mentioned), and your techpubs group. Like many of your readers, I too have experiended the swinging of the proximity pendulum, ad nauseam.
A central proximity between these groups offers three key perspectives and opportunity: 1) Connecting to Dev (understanding [and contributing to]the technology); 2) Connecting to the customer (understanding how the technology connects to the customer’s world); and 3) Connecting to your discipline (capitalizing on your techpub’s best practices/continuous improvement).
This approach is the golden ticket to Willy Wonka’s (<:
Thanks for commenting, Derek. I like how you’ve positioned the three connection points. In the comments on this post, a lot of people stressed the importance of connecting with dev teams, but really connecting with the customer seems even more important. I think that should be the first priority, as hard as it is.
Hi Tom,
Very relevant post. I am a freelancer now and must be able to work remotely effectively. However, my recent position was ideal – I had my own office (I could close the door), but I could wander into the Engineering office anytime to discuss. It also helped that my office was intermediately next to the coffee machine so I could catch a chat while they poured coffee. I preferred the quiet of my office, but the easy access to engineers. It was also important that I establish a good working relationship with key people so I could easily tap into the engineering buzz, usually by a early Monday morning chat over tea. Being sociable and likeable seemed to me to be key to gaining the respect of key engineers who had the information I needed.
I have been working as a content writer for 1 year and 6 months until a company offered me the position of a technical writer. I was apprehensive before I took the offer, but the MD assured that they would train me up. I joined. The tech team is very helpful and so is the MD! Still, the problem is that I have a seat which is away from the tech team.