我寫了一些這樣的回答，不只是面試會問到，其實也是我心底想的事情，這種體悟比較接近工作幾年後會出現的轉折。迷惘是一定有的，也希望可以讓邁向中階或senior的人，去思考與團體工作和自己的目標是什麼。
Justify the necessity of this position and its economical benefits for a company?
Technical writer is a rare role, so most hiring managers will have doubt to defend the necessity for this position.
I think the most obvious benefits with having a such role in a company is that employees can communicate asynchronously easier. There is an implicit limit for effective number of participants in a group discussion: 20 participants in real time.
As a result, I always look for the diff. of before/after because that's usually the critical part and business value being manifested.
No matter how many fierce debates had been made, these are the subtle things that being traded off by professionals.
It's an echo to 'circulate all forms of value' for experts in diff. disciplines. As a man in the middle it's hard to being grouped into certain discipline, but the effect of collecting the undefined tasks, subtle key info then refining them up is incredible.
The end results definitely paid off.
Works with multiple technical writers
My personal experience is each technical writers can work directly with 20 people on a long term base project (highly confidential) or a team, relatively connected to 40 - 60 coworkers (Infra, platform, fronend, UX, backend, pdm, sales...etc) , or indirectly with more than 100 people in an organization if the work result is accessible to a company-wide level.
Sometimes 10x potential viewers is possible when an well explained article is published on the internet. I was in a open source community and the statics from a backoffice and physical events shown that only 1-5% of the people are willing to leave their comments after reading a post.
The same ratio applied to most groups or companies. Not much people actively comments or reveal their suggestions even when they are experts. So the best way to do with twin engines is that you make sure they work with each other, just in the opposite cycle. They shall work on the same topics together, but on diff. phases of maintaining the knowledge base. For example, one works for reviewing while the other work for drafting and collecting info. They can shift the phase later, so they got balanced skills training.
It is worst to make each of them own certain topics for a long time, creating a inconsistency for style or topics covered. This would create problems once some of them left the company and the others or new comers can not pick up the area easily. Technical writers need diverse input and exposure to grow, so the best reward for them is to get the topics fully covered by balancing all aspects of work.
Evaluate the work quality of a technical writer
I have some practical metrics:
- Can people find certain information easier by themselves
- Did people update or comment on the doc?
- Does the version being well maintained so there is no conflict
In a nutshell, these are factors on how async the org has become by hiring a technical writer. In that way, customer service or engineers won't be flooded with answers that should be found in FAQ.
When a technical writer does a good job, new piece of info will be contributed by all employee on the system because they think it's worthy to do so.
(下集會在本周末發布，請期待)
留言
張貼留言
Please leave your comments. I will read them in mailbox and reply.