Sarah Maddox has recently been at Write the Docs NA 2016, and as usual she's posted a series of informative articles about the sessions she attended. If you're not already following her blog - and you should be if you're at all serious about being a better technical writer - here's the list of relevant posts:
I can't stress enough how much useful information Sarah manages to pack into a blog post, so get reading, get learning, get better at what you do.
The following comment was posted on LinkedIn recently by a fellow professional called Rupen:
"Recently, when looking for a Senior Technical Writer, I interviewed many, many participants with terrific CVs. I noticed that most did not follow basic writing principles; I try and adhere to the Chicago Manual of Style. They could write, but were unable to present information in a digestible manner. Each person seemed to have learned the principles once-upon-a-time, but after many projects, the principles vanished and delivery was more important. I wonder if this is because many companies have adopted Agile documentation practices.
I concluded that most people working as Technical Writers aren't really passionate about the field. They are makeshift technical writers, who'd rather be doing something else. It annoys me because the broader world of information experience deserves more respect.
...needed to vent!"
Rupen's conclusion that "most people working as Technical Writers aren't really passionate about the field" strikes me as incorrect, but I understand his frustration, as did many other people on the thread.
I've also seen the problem that he faces, but the issue wasn't that the writers didn't care, it was that they either didn't know about style ("how to write") or their experience was that they didn't have time - nor any pressure - to write to a specific style. Where Rupen is spot on is his assertion that "the broader world of information experience deserves more respect" (also, +1 for the previously unknown-to-me "information experience" phrase). This is the key to the problem, and it says to me that the candidates who don't know about styles are a symptom of a problem, not the problem itself.
I'll come back to that, but first a quick note about Agile documentation practises, because it's important that we don't conflate a move to Agile with a change in writing standards. Agile does encourage "just enough" documentation, but that doesn't preclude high quality, consistent output. It depends on what "just enough" means to the person responsible for setting the documentation standards, and also the documentation goals of the company employing the writer. That is the same in real terms whether your company is Agile or not.
But back to the problem of which Rupen's candidates are a symptom. I see 2 main issues which have caused a degradation of standards:
- An industry culture that assumes a documentation cost rather than a documentation value.
- An explosion in tech companies that need documentation.
Documentation Cost
Every writer has worked for companies that don't particularly value documentation, and in these companies the Technical Writing function doesn't get the resources, leadership, or, sadly, the respect that it deserves. This problem is very visible when it comes to things like standards, and the consistent application of those standards. A move to Agile can be an excuse to do away with any gains that the Technical Writers may have made in this area, often by disseminating common misconceptions about the importance, or lack thereof, of documentation in the Agile process and using this as an excuse to end "expensive" things like peer-review and proscriptive standards. Some of these misconceptions are dealt with here. But a move to Agile doesn't mean that this WILL happen, just that it can happen.
I've said previously that this perception of cost rather than value is one of documentation's big strategic, structural problems, so I won't go over old ground too much. But it speaks directly to Rupen's experience because a lot of companies don't want to put the resources into documentation, unless they're serious players like IBM or Microsoft.
Part of this cultural problem - and it is cultural, because the benefits of documentation are legion and obvious to anyone with an ounce of common sense - lies in the fact that most tech companies are started up by developers, and most developers hate writing documentation. That might seem like a trite observation, but how many tech companies have a developer right at the top? A lot of them. And by the time they sell to Google or Facebook or Microsoft or whoever, the culture is set and the technical debt in documentation is almost too large to be sensibly paid. Which brings me neatly on to point 2.
Lots More Tech Companies
Since Sir Tim Berners-Lee invented the World Wide Web in late 1989, there has been a profound change in the pace of company growth. Companies like Uber, Square and Pinterest, with virtually no staff or bricks-and-mortar resources, have achieved in a few years a market capitalisation that took traditional companies decades to reach. The WWW and the underlying infrastructure of the internet have brought about the biggest single democratization of wealth creation through creative ideas in the history of mankind. Isn't that awesome? Can I get a high five? Yeah, high five.
Now, not that I want to burst that bubble, or make it all about documentation, but democratisation does have some drawbacks. One of those is the lack of command-and-control. Dijkstra would be turning in his grave if he knew about all of the code out there that he would consider harmful. If we had command-and-control, or at least trained dinosaurs:
 |
| High Five? |
Then this could be controlled. But the WWW is a democracy (or Wild West, depending on your preference), so it can't be controlled. The explosion of tech companies has meant that there just aren't enough writers with experience of documentation good practise, like proscriptive standards, principles of consistency, a lack of dialects, and so on, and those that have it often coagulate in bigger companies that have been around for a while. This is because those companies are prepared to pay time and money for high-quality documentation, and writers who've worked in that kind of environment are often loath to leave for the chaos of a much younger company where they will spend most of their time explaining why documentation is important.
I've interviewed many people who have experience of working with tech companies I've never heard of, and when you look up those companies, a lot of them are 10 years old or younger. As documentation is often one of the last things to be properly implemented, is it any wonder that these people haven't used, or maybe ever seen, decent standards, processes and procedures?
In summation then, lots of tech companies, created by people for whom documentation is an afterthought, combined with not enough experienced writers, means a lack of credible candidates.
Whatever the cause of this problem, I'll say one thing: Everyone I know who writes for a living does it because they are passionate about it. It's up to those of us with some experience to teach them what they need to know to turn their passion into good documentation. Bang the drum, people!
In the past I've talked about multi-functional teams being the unicorn at the heart of scrum, i.e. very desirable but essentially mythical. I've also written a post explaining my take on the reason why multi-functional teams are so hard to find, but an article from Darren Wilmshurst has made me realise that I've never talked about why multi-functional teams are desirable in an agile environment (actually, required, if you don't want to do Water-Scrum-Fall). But before I go into this, I need to share a little bit about the writing process behind this blog, for reasons that will hopefully become clear.
Some of the posts on this blog are articulations of good practice, some of them are based on years of experience, and some of them - like this one - spring from a thought that occurs to me whilst I'm reading/writing/doing something in relation to agile. If you've ever spent a lot of time immersed in a conceptual framework, you'll hopefully understand how everything you see and hear that has any relation to what you're immersed in has the potential to send your mind off in a direction you'd never thought of before. This is the case with this blog; so much of what I write is the result of seeing everything professionally through the lens of trying to understand and then explain how and why agile things work the way they do, and that constantly sparks off ideas for blog posts.
Right then, that's all well and good, but what does it have to do with why multi-functional teams are desirable? Well, it's this: When I realised that I'd never written about this topic, I initially thought that it would already have been well covered in the blogosphere by other writers, so maybe I was just mentally riffing on something that has been fully documented elsewhere. This has happened before, and I didn't feel I had anything to add to the conversation, so I didn't write a post. But in this case, maybe someone has posted extensively on this topic, but I can't find those posts. There are posts that explain some of the practical benefits of a multi-functional team within an agile process, such as greater efficiency, less waste, cross-fertilisation of skills and ideas, and so on, and for a lot of people, maybe most people, these benefits are an acceptable end in themselves. No more explanation is required. But I'm more interested in articulating why those benefits are indeed benefits. What is the conceptual paradigm behind those benefits? What is the ground for the article of faith that says multi-functional teams are good?
Perhaps "article of faith" is wrong, but it captures the essence of my point. A more accurate statement might be to say that the concept of multi-functional teams has become one of the boundary conditions for what defines an agile team as agile, and, therefore, if you think agile is good, you must by default think that multi-functional teams are good. And that makes sense, because nothing is more closely associated with agile than the concept of the multi-functional team. Multi-functional teams are the hinge on which the agile process turns; without that team, you can't describe yourself as agile. And yet, this boundary condition is so universally accepted without question that I can't find much written about it, which seems like an oversight to me. I'll try to address that here.
In a previous post I talked about how agile methodologies like scrum and Kanban might be more suited to startups than mature companies. The heart of the piece was as follows:
"As a company grows though, employees become more specialised to increase efficiency and quality. This is an economy of scale that basically turns any suitably large company into a form of production line. Processes, procedures and standards provide not only the structure of the company which analysts can constantly study for new ways to increase efficiency (read: profits), but also the conceptual conveyor belt along which the product passes from conception through delivery and implementation to maintenance and support.
But scrum is the antithesis of this production line ethos with its proscriptive standards and linear flow. Scrum suggests, nay, demands a multi-functional approach to production within the scrum team, and that cannot happen if the scrum team is made up of specialists. "
Individual specialisation is the opposite side of the coin to multi-functional teams. It is the difference between the Henry Ford production line and the farming collective. There is an inherent tension here between the command-and-control, profit-driven efficiency of the production line, and the self-organising arrangement of a series of individual strengths and weaknesses for mutual benefit in the farming collective. The production line values efficiency over everything, and this is why it makes sense for a startup to move towards increasing specialisation. The key to a successful business, in the short to medium term, is to leverage a good idea such that enough revenue is generated to sustain that business as a going concern and provide enough profit for the owner to make it worth their while to continue. The best way to leverage a good idea which you've had initial success with is to hire specialists who can design, build, support, market, sell, and so on, while you focus on the good idea you had.
But in the long term, the key to a successful business - especially in an industry as fast-moving and competitive as software - is innovation, not efficiency. That's not to say that efficiency becomes unimportant, because it doesn't. It's just that efficiency is only useful so far as your products are delivering what the market wants. Even Ford, the company that made the production line famous, has the 2nd highest R&D budget of any company in the world. Why? Because without innovation their profits will wither and die. Not many people want a 1980's Ford, no matter how efficiently Ford can make them, when they can have a 2015 Toyota, so Ford spends billions every year to make sure that they have a competitive range of products for people to buy, and thus ensure their long term success.
And here's something important: innovation does not have to be mutually exclusive from efficiency. Nor does innovation have to flout a company strategy, or a divisional goal, or have no command-and-control directing it. As long as the team that is innovating knows what their boundaries are, you can let them get on with it, like a black box. Innovation might not be something that can be made more efficient in the way that piece work on a conveyor belt can be, but you can most definitely give a team of people the right conditions to innovate and improve their chances of coming up with the next big idea. If you do some research on the topic, the same recommendations for creating an environment that fosters innovation come up time and again:
- A culture of trust where people know that their ideas are valued;
- A culture of empowerment where people won't get in trouble for trying something new;
- A culture where the leadership actively encourages and rewards innovation.
In other words.....an Agile culture. Agile has all of these things, and although many people have to put up with working in Dirty Agile, anyone lucky enough to work in a company that has properly bought into Agile should have experienced these 3 things. So despite initial impressions, it is the collective that values the contribution of the individual more than the production line does, and this speaks directly to why multi-functional teams are desirable:
The collective allows the individual the space to innovate as part of a team. The production line just allows the individual to do the same thing they've always done, only a bit quicker.
Agile is firmly in the collective camp, and the self-organising multi-functional team is the tool that is used to drive innovation by building trust, providing empowerment, emphasising communication and fostering a culture of collective problem solving.
That's why multi-functional teams are desirable.
This also explains why so many companies who engage in Dirty Agile don't value multi-functional teams - they are the companies without the foresight or leadership to plan for the long term, so a multi-functional team that can innovate is never as important to them as a group of specialists who can do the same thing again and again, very efficiently. That also saves on training budgets and career development, which reduces short-term costs, although the staff turnover rate is strangely high..... I suspect that I don't need to gild this lily any further!
Perhaps you should ask yourself the question: Are you working for a company with a 1920's Ford production line, or a company with a 21st century Ford R&D department? And which one would you rather work for?
Inspired by this article, I've been thinking about how agile works better in startups than in mature companies. The article in question argues that Kanban is often more appropriate for startups due to the time-to-market imperative and the rapid pace of change, and I'm not disagreeing with that because a) she makes a great point, and b) I'm not going to argue with an agile maven like Abby Fichtner.
Rather, it occurs to me that the posts I've written previously suggest that scrum is difficult to implement in practise because of the unicorn at the heart of scrum, which tends to lead towards an inevitable Water-Scrum-Fall situation. This could imply that I think scrum doesn't work. This is not true. Scrum is a great methodology and although its application is hindered by the lack of multi-functional teams, that doesn't mean that it can't still be implemented well and have many benefits.
However, my experience comes mainly from working with mature products and teams, or new products and teams within mature companies. The larger and more mature a company gets, the more specialists they employ. No tech startup hires an agile coach as one of their first employees; it's normally 2 or 3 coders with an idea and easy access to deliverable fast food. Agile coaches come after another developer, an accountant, a saleswoman, a marketing guy, a tester, another couple of developers, and about 50 other people, because that's the point when the company stops being naturally agile and starts needing help to understand and proceduralise the things that make them good at what they do.
In a more mature company that's got hundreds or thousands of staff you'll find increasing levels of specialisation. In the technical writing team you might have editors, sub-editors, API specialists, tools experts, learning and education experts, and so on, on top of a pool of staff writers who actually document the output from development. And then there's the non-technical writers who provide marketing copy, sales brochures, company reports, blog posts, social media content, and all other manner of written communications. In a startup, the founders will do all of that as and when necessary, and as they hire staff the marketing guy will produce the marketing copy, the saleswoman will put together the sales brochure and the developers will provide some release notes or instructions on installing the product. After that, as the company grows further, someone in development will gradually start to take responsibility for documentation and eventually become the technical writer, or the company will hire someone specifically to write it. At that point, scrum starts to become more difficult.
In a startup, generalists are highly valued because there are many jobs to do and not many people to do them. The founders and early employees have to do everything from development to sales to documentation to marketing to testing to paying the wages and they normally lack proscriptive standards for these things. Therefore, an agile development methodology like scrum or Kanban is ideal: it allows them maximum agility and they are already a fully multi-functional team where the emphasis is on quick, iterative delivery. As a company grows though, employees become more specialised to increase efficiency and quality. This is an economy of scale that basically turns any suitably large company into a form of production line. Processes, procedures and standards provide not only the structure of the company which analysts can constantly study for new ways to increase efficiency (read: profits), but also the conceptual conveyor belt along which the product passes from conception through delivery and implementation to maintenance and support.
But scrum is the antithesis of this production line ethos with its proscriptive standards and linear flow. Scrum suggests, nay, demands a multi-functional approach to production within the scrum team, and that cannot happen if the scrum team is made up of specialists.
The more specialised the roles in your company are, the less effective scrum will be
This highlights an inherent tension that might help explain why so many companies end up implementing some version of Water-Scrum-Fall and not getting the results they expected. Specialism - division of labour - is a clearly defined economic tool to help companies scale up their production to make it more efficient and, ultimately, increase profits. This is one of the reasons why Waterfall is considered to be an efficient model. Scrum is a methodology that demands generalists. Therefore, whilst scrum can be more efficient and produce higher-quality deliverables in a small team, the staff needed for it are at odds with the staff needed for the traditional division-of-labour, process-driven methodologies. So large companies have specialists who work in a (conceptually) linear process, but if the company tries to implement scrum they need to employ generalists that don't fit with the perceived conception of efficiency.
In a startup though, specialisms are an anathema, and the entire company - which might be as small as 1 person - is composed of generalists who are agile by default. Agile is not so much the right methodology for a startup to use, it's the only methodology that can be used. Really, agile development as a methodology is the re-creation and formalisation of a tech startup mentality for larger companies, and larger companies have moved away from the generalised skill set needed to fuel that mentality in favour of a division-of-labour efficiency. Is agile trying to recapture a mentality that's inevitably lost in the paradigm shift to being a "proper" company? Is it possible for a large company to be agile in this way? I'm not sure it is.
I'd be interested in hearing from anyone that seen a startup move from being a small agile operation to a larger company with increasing specialisation. Did your company keep itself agile? How did it do it? Were generalists still valued as highly? Thoughts and experiences are welcome in the comments.....
