Part II: Personal layoff stories and reasons

by Tom Johnson on Jul 1, 2020
categories: technical-writing

• The layoff facts
• My story
• Colleague 1’s story
• Colleague 2’s story
• Colleague 3’s story
• Colleague 4’s story
• Colleague 5’s story

The layoff facts

Let’s start with some facts, because this was a newsworthy event. In a January 2013 article titled LDS Church announces limited layoffs, a newspaper columnist wrote about a layoff that affected 5 to 8% of the church workforce. Apparently, the reasons for the layoff were “‘a planned reduction in workforce’ as a result of the ‘evolving needs of a global church.’” The article explains:

The action is based solely on the need to be sure that resources are being used wisely to meet the evolving needs of a global church,” Purdy said, indicating that it is not a matter of declining budgets, but rather a matter of “reassigning budgets to meet current needs.

The church wanted to be clear that it wasn’t in financial straits but rather had shifting priorities. Note that referring to the employer as “the church” is far too broad, as there are so many different subdivisions and groups, and many of them are unaware of each other and not directed in a top-down way with every decision. I’ll refer to the employer mostly as ICS, which stands for Information Communication Systems. The ICS group had around 1,000 technology professionals creating all kinds of tools to support both members and administrators – such as tools that manage member records, provide calendaring and decision making, map out directories and boundaries, configure networking infrastructure in buildings, manage missionaries in different areas, and so on.

What were those “evolving needs” driving the 5-8% layoff? Although not stated in the article, in October 2012, three months before the layoff announcement, the church had recently decreased the age when young men and women could begin their missions. They reduced the age from 19 to 18 for young men, and from 21 to 19 for young women. As a result, missionary numbers increased exponentially. The numbers grew so fast the event is recorded in this Wikipedia article about LDS missionaries:

Immediately following the announcement, the church experienced an unprecedented influx of new missionaries. The rate of new missionaries swelled “by 471 percent, from about 700 new applications per week to about 4,000 each week, with young women comprising more than half of the new applicants.” In 2013, the number of missionaries peaked at 89,000…

The influx of missionaries posed a financial burden on the church to provide more training facilities and other support costs associated with missionary work. Although no one officially said the missionary policy caused the layoff, it’s hard not to connect the two events, given the timing.

But even if we connect the events, it doesn’t explain why ICS made the decisions they did about who to keep and who to let go. A layoff of 5-8% of people out of 1,000 included people in a diversity of roles and departments. I can imagine the decisions were hard and uncomfortable, but it’s rare that a company would wipe away an entire job function. It almost felt like a statement of value. For some of us, the decision was deeply troubling, while for others, the layoff was less unexpected and only confirmed a cycle of low valuation they had felt throughout their tech comm careers.

To its credit, ICS provided generous severance packages. This allowed many of us to transition into another job or direction without feeling like we’d been kicked to the curb. The following sections will explain the different directions each of us took and the stories we told ourselves about the reasons for the layoff.

My story

With my severance money, I decided to relocate to Santa Clara, California, which was right in the heart of Silicon Valley, the mecca of tech. I’d actually been thinking about jumping ship from ICS some months earlier because I wanted exposure to more technical projects, and five years was long enough at one company.

After the layoff announcement, I lined up several interviews with companies, drove out to California for a week, and ended up getting a job at a gamification startup a few weeks later. The gamification job steered me into the direction of API documentation (since so many Silicon Valley companies have APIs).

Although I focused all my energies on my new job and environment, I still had to process the layoff. I barely had time to think about it during the transition. From the time I was laid off to the time I started the new job, a mere three weeks had passed, and most of the time I’d spent moving and preparing our Utah house for the rental market (selling it would have resulted in a loss).

I mulled over the reasons and implications of the layoff over the next few years. In my mind, I rationalized the layoff as a moral decision to procure tech comm services in a less expensive way, which seemed justified by an employer constrained to use donation funds frugally. We had been counting our hours on projects for years, each week noting how many hours we each spent on each project. I assumed at some point, a cost analyzer counted up the hours, multiplied them by our cost rate, and compared the result with a similar cost result from an external group that would provide this same function. I assumed the external agency could do the work for less, and that’s why the ICS managers made the decision. But in reality, that was just the story I told myself. I honestly didn’t know what the rationale was, whether any pay analysis was done, whether someone actually reached out to an external agency to estimate costs, and so on.

I think the reason I steered my career in the direction of API documentation, not just with the initial gamification job but subsequent ones as well, can be traced back to this layoff. As the primary breadwinner for a large family (four children and a stay-at-home spouse at the time), I felt pressure to provide. I didn’t want to live unemployed in my in-law’s basement. Financial security shot up to the top of my priorities. Whereas earlier in my youth I had earned a BA in English and an MFA in literary non-fiction writing, and had spent many hours writing and reading creatively, all that ended. I would be focused on tech now. I would devote my free time to ramping up on technical projects and tools rather than reading Whitman or writing non-fiction essays on topics unrelated to work. I realized that to be competitive in a more technical landscape, I had to refocus my life like this.

Actually, I had already been angling in this direction for some time, but the shift to APIs reinforced the emphasis on technical learning. If you can combine technical skills with writing prowess, you can be competitive for nearly any job in Silicon Valley, and in this mecca of tech, opportunities for technical writers seemed endless. Without the layoff, I’m not sure I would pursued this direction to the same degree.

About a year after moving to California, I also ended up leaving the Church — not out of bitterness from the layoff, but from a growing disconnection I’d felt for many years and an increased awareness of many troubling issues that I won’t describe here. Since my employment no longer depended on my Church membership, I was free to question my beliefs and choose a different direction without consequence. (Previously, had I quit the Church, I would have also been disqualified from employment.)

As I tried to trace back the details of the layoff, I realized how many gaps were present in my mind. I really didn’t know the details of the layoff, the calculations behind the decisions, how the outsourcing efforts played out, and more. Did ICS save money? I had heard that some of my colleagues were re-hired both as full-time employees and contractors at various times and in different ways, but I didn’t know the details.

After publishing the guest post from Jeremy, I decided to reach out to my former colleagues with these questions. As I reconnected with them, I realized that my understanding of the situation had been flawed and incomplete. In the sections that follow, I’ll try to tell some of their stories. Because some of them asked to remain anonymous, I have referred to them generically as “Colleague 1,” “Colleague 2,” and so on.

Colleague 1’s story

Let’s start with “Colleague 1.” Colleague 1 had been working at ICS longer than any of us, and was most familiar with different parts of the organization. This colleague had serious graphic design skills (he frequently made clever cartoons), and I always wondered why he didn’t include more art in his documentation. He also wrote fiction in his spare time (he was the kind of person who had several draft novels in his desk drawer).

Although I didn’t know it until gathering information for this post, Colleague 1 told me that a couple of years before the layoff, he had already been contemplating another career direction. He said he was “tired of the continual, field-wide feeling that practitioners have to justify their existence to other disciplines.” He liked that technical writing included writing, editing, and document design. Tech writing also introduced him to many new disciplines he was previously unaware of. And he liked working at ICS a lot. But the way technical writing was disconnected from product development troubled him a bit.

After the layoff, Colleague 1 worked a contract doing WordPress development. After some months of this, ICS re-hired him as a contract technical writer back on his former project. Apparently, the previous contractor that ICS had hired in his place had trouble understanding the authoring tools and customizations. The contractor wasn’t working out.

Eventually, though, Colleague 1 transitioned out of technical writing altogether and moved into business analysis and later functional analysis. These analyst roles involve gathering the data, requirements, and other details that determine the direction of projects. ICS hired him back in these analyst roles (full-time) as well. So technical writing ended up being a springboard for the rest of his career. Colleague 1 said, “My product knowledge contributed directly to my ability to move from tech writing into business analysis in the group who hired me back.”

As for the reasons for the layoff, Colleague 1 didn’t believe anyone did a pay-cost analysis to arrive at the decision to lay off technical writers. When I described my thoughts about someone deciding that hiring contractors to do the tech comm work would be cheaper, he said he didn’t think anyone made an analysis like that. Since the layoff was broader than just tech comm, but rather 5-8% across a group of around 1,000 people in many IT roles, he didn’t think anyone was specifically targeting technical writers as a kind of value statement about the worth of the job function. He said he thought the layoff decision was mostly made in a vacuum, involving only our immediate reporting line only and no one else.

Listening to Colleague 1 dismiss my pay analysis story made me reconsider other assumptions I’d been making. I also started asking more and more questions about his career path. Colleague 1 explained:

I enjoy doing business and functional analysis enough that I don’t know that I’ll ever go back to tech comm. Not enough organizations involve their technical writers throughout the process of developing a product. In organizations that have analysts, they’re much more involved throughout the process. That is one of my main reasons for deciding to change job functions. I like to be in the middle of solving the business needs and problems.

The in-depth engagement Colleague 1 describes is a theme that I’ll return to in the conclusion, especially as I explore some thoughts about content design roles that blur with product design roles. But for now, I just want to note how layoffs can sometimes propel us into career transitions that we might otherwise be too hesitant to make. In this case, it was like pushing someone off a high-dive. And Colleague 1 didn’t belly-flop – he swan-dived with a half twist or more, landing in a more perfect form true to his professional interests.

Colleague 2’s story

Colleague 2 stayed on for a year as an IP manager but then later transitioned to another company in the area. He told me, “For a while I went in a different direction. I was an IP manager for a year, and then I went to work as an engagement manager for a software consulting firm where I did some technical writing, but mostly did what was essentially external project management (customer-facing).”

At the time, I remember seeing Colleague 2’s Linkedin profile change to “Engagement Manager” and I wondered why he’d taken this turn in his career. I wondered if he would go in another direction like Colleague 1, but Colleague 2 eventually did return to the discipline of tech comm. He said, “I thought about letting it lead my career into a more technical consulting role for the product we worked with, but an opportunity to jump back into tech comm came available, and I jumped.”

Because Colleague 2 remained in place at ICS in an IP manager role (but not doing technical writing) while the rest of us were let go, he had more insight than others. Like the rest of us, though, he wasn’t sure and could only hear gossip and gather impressions about the reasoning and calculations behind the layoff. Colleague 2 explained,

As for what went on behind the scenes when determining how to get rid of the tech comm team, I heard some scuttlebutt. However, it was basically gossip, so I can’t validate its veracity. I had a clear impression that the solutions manager needed to trim X number of people from his team. He had actual deliverables he needed to produce. Our team worked on a consultancy basis and didn’t affect in a direct way the work he needed done. So if you have to get rid of X people, and you’ve got some that aren’t directly producing the work you need done, they are the obvious first choices. So it wasn’t so much a conscious decision to rid the organization of tech comm, it was a decision to protect the people who were getting the work done that he was committed to.

In other words, the deliverables this manager needed to produce didn’t include documentation, so when forced to reduce his headcount, he made the only logical decision based on his project priorities: let go of resources not vital to his projects.

Tech writing may not have been a need by this manager, but it certainly was needed in other groups. As I indicated with the previous story, Colleague 1 had been re-hired as a contractor by the group that he previously worked with.

Colleague 2’s theory about a manager who is responsible for certain deliverables that didn’t include documentation triggered clarity with my own memories. As I recall, about this time there was an effort to reduce engineering costs by building apps on a SharePoint framework. It was thought that SharePoint could lead to app development in a more efficient and timely way, and this manager’s primary charge was to get this SharePoint app development program off the ground.

This SharePoint manager was actually one level up from our direct manager. Unfortunately, during this time our direct manager was out of the office due to family issues. The absence of our regular manager also contributed to the layoff. Colleague 2 explained,

Our direct manager was out of the office with a family crisis, so he wasn’t able to advocate for us. It was unfortunate that he couldn’t be more involved in the process, because I think he would have fought for us.

Having a manager (especially a C-level manager) fight for you is key. It must have been hard laying off a whole team, but I know that when there are budget crunches, if you don’t have a C-level champion for docs, resources get prioritized for the higher priority projects.

Colleague 2 summed it up: “So in the end, I think it was an unfortunate combination of bad timing, and the fact that the person making the decision didn’t see us as valuable contributors to his bottom line.”

Colleague 2’s point about managers gathering the resources they need for priority projects made a tremendous amount of sense to me. It’s probably the best takeaway from all the stories here. Technical writers need to identify what the high priority projects are for their group and align themselves with these projects in deeply integrated ways with these priorities. It makes no sense to focus on low-priority projects. The problem here is that tech docs didn’t have any relevance to SharePoint app development, so it wasn’t something we could focus on.

One group’s priority isn’t always another group’s priority, and I will return to this problem later to reflect at greater length. I believe this misalignment of priorities, in part due to tech comm’s distributed nature across an organization, presents insurmountable difficulties for tech comm that lead to low estimation. Again, I’ll elaborate more about this later.

Colleague 2 explained that when other groups learned that their tech writing resources had been cut, they “birthed a cow.” These other groups ended up hiring back some technical writers to work as contractors. Colleague 2 says this proved that tech writers served critical roles on these other teams. He said these other teams weren’t consulted about the impact of removing the writers from their teams.

Colleague 3’s story

Colleague 3 provided a few other perspectives to the layoff story that I was unaware about. She said,

I actually did feel the intent was to eliminate the tech writing function as an internal team at ICS. I did not have the sense that they had an intentional strategy to continue the function by outsourcing it. Rather, I had the sense that they would do so if/as needed. I could be totally wrong on this. In addition, there was a team of writers in a neighboring group that overlapped with ours, so I think that (rightly) had an impact on the decision to let our team go.

She went on to explain that other groups outside of ICS, to whom we had been loaned out as tech writer support, reacted adversely when they discovered tech writers were no longer available for their projects. As I already indicated, one of these other groups later re-hired a tech writer for their project as a full-time employee, not even as a contingent.

The idea that an organization could hire contingents at will with a “plug and play” model doesn’t acknowledge the heavy costs associated with the hiring process, as well as the internal knowledge lost with resource turnover. Colleague 3 explained,

I don’t have information to determine if ICS saved money. In fact, I’m not sure anyone at ICS has that information. I say that because there are hidden or unacknowledged costs (particularly with the contingent model, where an employee is “leased” from an employment agency for 2 years, then forced to take a 6-month break before they can be rehired). The biggest hidden cost I see is loss of institutional knowledge and continuity, which causes quality to suffer. There’s also the cost of constant contingent churn. It seemed like this manager in charge of contract technical writers was constantly finding, onboarding, and offboarding contingents. It seemed to be a major drain on her time. And of course there were time drains as outgoing contingents had to train incoming contingents.

This point brings us back to Mark Baker’s earlier comment about tech writers pitching themselves as resources who can quickly ramp up on the needed technologies to learn what they need to know to write documentation. Although contract technical writers might be tech savvy and tools savvy, there are unavoidable costs associated with hiring and information turnover that even the most autodidactic and autonomous writers (or other contingent roles) will struggle with.

As I think about my role in my current company, I’ve seen how long it takes to hire and train a new employee. It can take six months to actually find someone proficient to hire, and another 3-4 months for the writer to come up to speed – not just on tools and processes, but on the company’s culture and workflows and existing documentation, not to mention the technical products and their upcoming releases. Knowing what’s what, who’s who, how to get the information you need, what minefields to avoid and such, etc., is not something you can just learn through a hiring orientation.

As Mark said earlier, “You can’t actually be an effective technical communicator without deep knowledge of the company, its products, its technology, and the industries it serves.” If contractors have a fixed term of two years, just as they get up to freeway speeds with productivity, they have to be let go, regardless of whether projects have finished. Being let go in the middle of an important project can be a drain on morale. Most of us like to see a project through to the end and publish our documentation. Imagine if your contract expires one month before release, right when documentation enters the crunch-time phase. This can send product managers scrambling into a panic as well.

Colleague 3 was re-hired as a contingent by the teams that needed someone to write help for their products. More specifically, she replaced Colleague 1 because he had transitioned into a new role (with business analysis). But when her two-year contract later expired, she explained,

Once again, I had to leave in the middle of some important projects based on policy, not business need. I did not want to do contingent work again, particularly because of the damage it was doing to the projects I was on (at least from my perspective).

Tired of the contingent model, she went to work as a contractor for a company that Colleague 4 started, which I’ll explain in the next section. As a more permanent contractor for this external agency, Colleague 3 says, “I enjoy not going into an office every day (I was working remotely before COVID) and I’m very grateful that I no longer have to worry about two-year limits as a vendor.”

I asked Colleague 3 why tech writers are often seen as unimportant within a company, and she mentioned a few reasons, such as the assumption that documentation isn’t needed, or that it’s not used. She also pointed out the inability to measure the effect of writing. She said,

I think very few people know how to measure the impact of good or bad writing, mainly because they don’t have the skills to recognize it. Also, the costs are hidden – for instance, no one (that I’m aware of) measures the impact to business when someone makes a mistake because a user manual was written poorly or is out of date.

The cost analysis rarely includes support costs that could have been prevented through documentation, or any understanding of what support costs would be without documentation. When the topic of metrics comes up, I often joke that if we really want to see the value of docs, we just need to take them offline for a week, but the only time we actually do this is when a server goes down.

Decision-makers often prioritize sales or business development professionals (profit centers) who land big deals or partners, but they fail to realize the many supporting points that these deals and partners rely on to get to that decision. Few partners would sign a contract without estimating the technical effort for integration. And how do partners estimate the technical effort, if not by reading the documentation?

Colleague 4’s story

We now come to Colleague 4’s story. Colleague 4 was somewhat new to the team, as he had re-located from Texas and had transplanted his entire family to a new area just one year ago. It was unfortunate that his time in ICS was so short, especially because this colleague had previously been working as a project manager and was eager to return to technical writing. He was just getting his feet on the ground when the department performed a leg sweep with the layoffs.

However, as it turns out, Colleague 4 had some serious entrepreneurial skills and formed his own tech writing company, initially specializing in Flare customization and setup. I was impressed by this because when Colleague 4 joined our team, he learned Flare for the first time (transitioning from DITA at IBM). And now, after only a year, he was ramped up so much that he was offering Flare customization services – and making good money doing so!

Colleague 4 says that his memory about the layoff was hazy (like mine). He remembers only that ICS decided tech comm wasn’t a service that ICS planned to offer anymore. However, they still needed tech comm after getting rid of the tech writers. Colleague 4 explains,

Regardless of the intention, though, the outcome was that ICS has never really gotten away from providing tech comm services. It only took a few days before they were back in touch with me to come finish up a big project, and I’ve been involved in providing tech comm services for them in some form or fashion ever since. As I’ve mentioned, they now outsource a decent amount of work to my company every year. It involves everything from content development, to training, to highly-skilled technical development to meet some business requirements. We also consult with them quite a bit on optimal translation workflows.

Colleague 4 turned out to be really good at company management. After all, he was a former project manager. I asked Colleague 4 whether he thought ICS’s decision to let full-time tech writers go and replace them with contractors was financially sound. He said this shift from full-time employees to contractors just shifts the risk rather than reduces costs. Colleague 4 explained:

The risk of employing a person long-term, with all its commitments, retirement, benefits, and so forth is gone for the employer. That responsibility shifts to the contractor being hired to do the job. Since the contractor is now assuming that risk, there is higher short-term financial compensation for the contractor. ICS is paying more per hour of work by outsourcing, but they’ve eliminated long-term costs and other liabilities.

When I asked Colleague 4 how he steered his career differently because of the layoff, he explained that at IBM, he had survived 12 layoffs over the past 11 years. He observed that the people who had been laid off had esoteric, outdated skills and had a hard time finding new jobs. As a result of seeing so many layoffs, he switched gears and wanted to become more stable. When the layoff happened, he said, “I decided to put myself in a position where I couldn’t be laid off (because I was the boss), and I had to keep my skills current in order to stay in business.”

He formed a company doing small Flare consulting jobs, mostly contract content development work for ICS, the same company that laid him off. But eventually he transitioned from content development to tools development. He says, “As my Flare consulting business grew, I eventually stopped doing contract content development, and I did full time Flare training and consulting. This was a thrilling journey for me in many ways, and it pushed me to grow in ways that I didn’t think I could.”

After 6 years of running his own company, he decided to switch back to being an employee because he missed writing, missed being on a team, missed driving long-term initiatives. He liked the way small companies came together to deliver for a customer. He told me he liked the “bold, quick decision making and ‘fail fast’ ethic” inherent in small companies with teams working together.” So he joined another company as a full-time employee. Colleague 3 is now the main employee at his consulting firm.

Colleague 5’s story

Now we come to the last story in this series – Colleague 5. Colleague 5 had been hired as a contingent technical writer and had been working for ICS for nearly two years. When he was initially interviewed, he had a full, generous beard that complemented his curly hair. Unfortunately, as per the dress code at the time, he had to shave his beard entirely. But he did so cheerfully. When the layoff occurred, he wasn’t actually laid off – his contract was just let to expire the following month, and it wasn’t renewed.

Colleague 5 had been laid off before (at another company), so he had more experience dealing with these scenarios. He went to work at another company in the area and remained there for a good 5 years with a lot of success. He had many different CTOs at the company (6 different CTOs in 5 years!), and he reported directly to this higher-up executive role. With the last CTO, however, he ran into a situation in which support for documentation dried up. Although the other CTOs were highly supportive of docs, the last was almost an anti-documentation CTO. Colleague 5 explained,

He actually told me directly, that he didn’t value technical writing. He came from a support type of background, and I think he thought that the answers users need are never found in the docs (hence the need for support).

When the company entered a budget reduction situation and needed to cut costs, they closed the entire Utah office and retained only a single writer abroad (in Scotland). The company also did not have any more major releases, so the need for technical writers was already reduced.

Colleague 5 transitioned to another company and has been there for a couple of years. He reports up through Engineering rather than directly to the CTO. However, he has also run into a similar lack of support for documentation. A senior leader expressed his view that support plays a more crucial role than documentation. Colleague 5 explained:

He just expressed to me last week the same idea that people get more value from support than documentation. This of course is a reflection on us as technical writers not always knowing the pain points of our customers, and of not making discovery of our content as easy and obvious as it ought to be. As a result of that discussion, I’ve reached out again to the support personnel to try to assess what kind of information our users are looking for the most. I’ve done this in the past with little return on the effort, but one must keep trying.

Colleague 5’s experiences demonstrate the need for documentation champions at the executive level. Cultivating a C-level documentation champion at a company is not easy. Most technical writers don’t have regular contact with C-level executives, so it’s difficult to communicate the value of docs directly. Additionally, most executives are focused on larger initiatives, the bottom line, product success, and more. Documentation doesn’t often bubble up to their radar.

In many cases, I think lack of a C-level champion is not so terrible, but having a documentation anti-champion, or a documentation detractor, at the executive level can lead to quick annihilation, as this executive level has the power to easily sweep you out the door, especially during times of budget reduction. Figuring out how to shape and influence C-level executives to bring about a more supportive culture toward documentation – which might be expressed through appropriate resourcing for documentation needs – is not something you can really affect at a company without a prolonged campaign.

Having shared the stories of my former colleagues, let’s now move on to some analysis.

Next: Part III: Correlating organization models with low value estimations