A Subject Matter Expert (SME) is a person who is an expert in a particular area. In technical communication environments, the term is used to describe professionals with expertise in the field of application but without documentation, procedural discourse, or project management knowledge. Technical communicators often collaborate with SMEs both prior to and during the editing of technical writing projects.
A 20 minute monologue about the best way to get information from SMEs: sit by them, permanently if possible. Many IT organizations station the writer remotely from the developers, programmers, and other SMEs, but nothing could be more damaging to getting the information you need. Increasing your proximity also increases the communication you receive.
Just the thought of dealing with Subject Matter Experts (SMEs) can create stress in the life of any documentation manager. Philip Rastocny provides in-depth insight on how best to deal with SMEs.
Just the thought of dealing with Subject Matter Experts (SMEs) can create stress in the life of any documentation manager. Some SMEs can be self consumed, preoccupied, distant, and even rude. But why do these behaviors exist? This article briefly describes how to interact with people who might be difficult to motivate and how to work with people who have priorities different from yours.
Part 2 switches the focus to members of your management team and what you can do to sell your team’s professionalism. Also included are hints on how your writers can individually sell themselves to gain cooperation from SMEs.
The development of a modern software product is a complex process involving a variety of disciplines, including that of the technical writer. It is essential that the writers establish close relationships with all other groups in the process and that they build effective and efficient systems of communication between them. The job of the writing manager is to ensure that the writing team obtains the information it needs in a timely manner and that the group interacts effectively with other groups in the process. This can be achieved by a blend of intergroup communication, background research, documentation and schedule planning and a well organized documentation review process.
This article first reviews the current literature that addresses the value of the technical communicator. Whereas those discussions focus on what is delivered to the user (reader), this article examines the value the technical communicator adds by creating organization (internal) knowledge. The article then examines the philosophical underpinnings that support any discussion of knowledge and defines the role of technical communicators as creators of knowledge. Finally, it offers an expanded value proposition for technical communicators and examines its practical implications.
Who should you contract to update an outdated policies and procedures manual–subject matter expert or a policy and procedure writer?
If developers only hears about bugs, problems, quirks, errors, and other issues, where’s the motivation to code? In a recent post on Joel on Software, Joel Spolsky stresses the importance of giving positive feedback to developers, not just negative. But there was no where to log my praise in our bug tracking system.
What should technical writers ask engineers when writing support materials for a product’s end users? Guest blogger and leading tech comms expert David Farbey wraps up his ‘What to ask…’ series with questions for engineers.
Double agents on writing teams provide benefits to both product developers and technical writers with their unique skills and perspectives. You'll be more likely to get the information you need when you need it because your double agent has already set the stage for success. Learn the benefits of having a double agent working with technical writers as a part of the product development team. Discover valuable secrets never before divulged to the public that you can use to work with your product developers. Take out your magnifying glass and look for the clues.
To meet the challenge of addressing the needs of subject matter experts (SME) and non-experts, alleviating fears, and keeping the public informed requires knowledge of communication theory, subject-matter expertise, and adherence to a code of ethics. A model illustrating the professional technical communicator's knowledge base and relationship with the SME and non-expert is presented.
I admit that I don't know everything about subject-matter experts or SMEs (rhymes with please). But I do know that there are some things that you should avoid asking SMEs, the main ones being 'Does the user know this already?' and 'Do I need to explain this to the user?' The problem with these questions is that the SME is likely to reply 'No!' to both of them when in fact the answer is most definitely 'Yes.' SMEs tend to believe that everyone knows as much about technology as they do. Never, never, never let the SMEs tell you how to write the documentation. A SME is the subject matter expert, not the documentation expert (that's you).
Content strategists often rely on the specialized knowledge of subject-matter experts (SMEs) to get the job done. But that job isn’t always straightforward; it’s complicated by different perspectives, communication styles, and project goals. Amanda Costello shows us how people skills—and the right mindset—can lead to better collaboration with SMEs and a smoother process from start to finish.
This month we’ll discuss the process of putting users at the center of the design process and what that means in regard to both design and product strategy. We’ll also discuss some different approaches to a user-centered design process that we’ve come across and outline their positives and negatives. Finally, we’ll outline the steps necessary to make user-centered design a reality and how to get the most out of a user-centered design process when working on different types of products. The insights we gain from interacting directly with users are invaluable. They can assist us greatly throughout the product development process and ensure user adoption.
Most companies want to be recognized for producing usable products, for the quality of products must be high if they are to be accepted into today's competitive market. However, usability planning relies on interaction with other departments and their members. In other words, the most successful way to ensure product usability is to set up a test team consisting of representatives from various departments. This paper details the members of that test team and discusses their overall responsibilities in the testing process.
Almost a decade ago, Walkowski's (1991) study of the interaction between subject-matter experts (SMEs) and technical writers focused on the perceptions of software engineers toward technical writers. Her findings gave technical writers insights on how to improve critical relationships with these organizational colleagues. This study partially replicates Walkowski's (1991) study of technical writer-SME interactions, but instead of collecting data from SMEs, we surveyed technical writers themselves. We report perceptions collected from 31 technical writers and contrast them with Walkowski's original findings, offering interpersonal and organizational recommendations for addressing tensions between these groups. By examining both the SMEs' and the technical writers' perceptions of their relationship, we are able to provide a two-sided view of a dynamic and complex interaction. We also argue that participants in the SME-technical writer interaction cannot fully alter their relationship without the strategic supp
As a technical writer, it is not enough to document something and send it out for reviews. You must take the ownership of getting your work reviewed and incorporating the inputs from reviews. Getting your reviews done is a common challenge and, thereby, a pet excuse for the lack of accuracy and quality in documentation. This article discusses tips to help you optimize the review cycle by managing your deliverables (organization, format, content), time (deadlines), and stakeholders (developers, managers).
As user experience professionals, we deal with experts a lot in the form of Subject Matter Experts. And in doing so, we become experts. Plus we deal with experts and expertise in a dozen different forms in our routine lives every day, so it is good to stop and talk about the three big mistakes experts make.
The time-compressed training development methodology involves putting together a team of subject matter experts (SMEs), a designer/facilitator, and one or two scribes, then giving them the time and space required for focused effort in a three-phase approach. The three phases are: prework; development sessions; and, postwork. During the prework phase, a preliminary course outline and formats for the materials are developed. In the development sessions, the outline is refined, objectives are defined, and the content is developed. And, in the postwork phase, the materials are reviewed, refined, published, and distributed.
Outside of the formal SME interview, a writer's relationship with engineers and experts is built on trust, respect, and a little bit of bribery.
Technical editor or writer needs to close the gap between the subject matter expert and the novice. A close collaboration between the technical editor and the expert results in better manuals.
This paper discusses tools and techniques for editors and writers who need to work with subject matter experts (i.e., engineers, programmers, accountants, etc.) to create plain language manuals.