Book Review: The One Minute Manager

Yesterday I read the book on management, One Minute Manager by Ken Blanchard and Spencer Johnson. The book is really brief, and gives you an overview of the managerial technique that consists of three concepts, one-minute goals, one-minute appraisal and one-minute reprimand.

I have recently been promoted to manage a small team of authors. My scope of responsibilities encompasses delivering quality documentation and train the team to become fully fledged technical authors. The idea is that each of them one day will be able to work autonomously on separate projects with me as a general supervisor.

This is why, I was snooping around for some literature about how to manage a team efficiently, and this is how I came across “The One Minute Manager”.

I am still dubious about the whole concept, I think I need some time to process the idea. The idea itself seems simple, but maybe too simple for what I need? Basically, a good manager doesn’t interfere much, which is something that I have been trying to practice, and teach the team to be autonomous, and to manage their time on their own. All will be fine if it wasn’t for the fact that my team consists of very young people, and most often they don’t know what types of questions to ask or how to manage their own time. This is their first big job, and I can’t expect them to have the know-how of a versed office worker.

Instead of throwing them in at the the deep end, I have decided to learn a bit about them by asking each of them the following questions:

1) When is your brain most active, are you an early bird or a night owl?
2) How do you start your work day? Do you make to-do lists, or just pick up items as they fall on your lap?
3) Do you prioritise your work according to circumstances?
4) How do you tackle a problem? Do you prefer somebody to show you or figure out on your own?

At first, I thought it was a ground-breaking approach. I believed that if I hack into their way of thinking, I would know “what makes them tick”, and all my problems will be solved.

Instead, I think I scared them a bit. The answers they gave me were a bit vague and defensive. Only after they got to know me better, they were able to answer these questions more honestly, knowing that it was not a vicious test, but a genuine interest. I have showed them how I think, showed them my strengths and my weaknesses, at which point, they’ve learned I am also a human being, and although I do have more experience and field knowledge, I also have to learn and constantly improve my skill set.

The manager in the book seems a bit know-it-all. And I think this is where reality and theory don’t go hand-in-hand. I would like to have a manager that is almost at the God-like position, revered by his employees, because they are simply afraid of his wrath.

However, the book helped me realise that I spent too much time with them as a group. We had team exercises, team practice, we even wrote content as a team, so we can learn form one another. What I should have done is to first spend time with each of them separately to show them how to write content, to let them practice on their own, and only then let them showcase what they’ve learned at the team level.

Instead, we met as a team and we would do everything as a team. The most obvious reason for that approach was that at the end of the day I was still expected to meet deadlines and write quality content, and this classroom-like  environment saved time and gave them equal opportunity to learn.

Opportunity? Yes. Equal? None at all. The biggest problem of education is that it can never meet the happy medium. The curriculum can only focus either on the brightest students, leaving less gifted far behind, or focus on the slow learners, ousting and demoting the ones that acquire knowledge quicker to the level of slacking off.

This was exactly what happened to me. The brightest ones asked their questions, learned and wanted to move on. At the same time, the slowest ones, not knowing how to ask questions, felt abandoned and lost their learning drive. They started slacking off to the point that I caught them browsing through a social media site on their phone at the team meeting. Meanwhile the rest of the team also felt a bit uneasy; they were the ones who paid most for that arrangement, as I focused all my free time on trying to lift the others to their level, shadowing them and showing them how to perform a task.

At the end of the day, because of my unified focus, the ones that struggled to learn stopped listening to me, as they probably felt it unfair I am focused mainly on them, because at that point it became obvious why. The rest reached the desired level of skills, and I was able to appoint them with any task, and they would perform it autonomously.

What I should have done is to first teach the team how to be more proactive and responsible for their own work. How to approach a task. How to write, and how to edit.  It is not enough to tell the team to write something. Because they write it, no problem, but the problem will be that at this point they still treat content as student assignments,  and they submit it to me for my corrections knowing I’ll make it better, so they don’t have to worry too much about it.

So going back to the book. One Minute Manager is supposed to let his workers come up with a one minute goals, no more than 250 words each, so you’ll able to read it in one minute. Also, each goal should be written on a separate piece of paper and there can only be a limited number of goals, otherwise a person would feel overwhelmed. Now, this is not such a bed idea on its own, but the authors never defined what a goal is. It can be something very whimsical and hard to measure, and this is usual what people do when thinking of goals. I want to write better content. Boom.

But how do you measure greatness of the content? Now, if you were to say you wanted to decrease your readability level to let’s say Grade 6, than it would be something you can aspire to. So there you go, defining a goal is a really tricky thing. Also, can a goal be a part of your to-do list? In the book, each worker after defining goals, knows exactly how to approach a task. Do a one minute manager differentiate between a goal and its supporting tasks? Is this why a goal should be so limited with words on paper?

My plan is to let the team work out their own style of writing with time. Let them have their trial and error time. I will also stop correcting their work, and rather give them constructive feedback and suggestions on how to make the piece better. This will give them the opportunity to learn how to edit their own work, and how to review each other’s content. So I did “write” a goal for them, but it is my goal rather than theirs. I own it, and I take full responsibility for the roll-out and for the outcome. Maybe with time, I can work with the individuals on defining their own goals, but I believe it is too early for that.

So I’ve covered the goals. I think I have defined pretty good goals for myself for the next months to come. Now, there are two concepts that are quite interesting, also hard to practice.

There is a concept of a One Minute Appraisal. A manager’s role is to catch their employees doing something right. As soon as it happens, they should praise the employee, congratulate them, and most importantly shake their hands, or touch them to show support and respect on a personal level. I have been praising the team and thanking them for their hard work, but I was doing it on a general team level. A mistake on my part. For some time now, I’ve been practising with appraisals on a personal level. It doesn’t have to be a secret appraisal, like suggested in a book. I’ve been doing it through our team communication channel, but what I did differently was to call that person by their name and thank them for the specific task they’ve done. Sometimes, I also write to them or praise them separately, but I make sure I do it through the team channel as well to introduce a sort of healthy competition on how to become a better technical author.

This leads me to the last part of the book, the One Minute Reprimand. The manager should immediately give a negative feedback to their employees, show dissatisfaction or even anger about the mistake the employee has done, and let it sink so the worker feels the awkward silent which makes them even more vulnerable. This part of the book is hard for me. I think this approach is too harsh. However, maybe if I were strict but fair I would make a better job? The second part of the reprimand is a manager saying to the worker that despite what they did, they are still valued members of the team. Personally, what I would remove from that process is a manager telling the worker how they feel, it is not really relevant from the company stand point how the manager feels. Additionally, it would immediately place me in a mother-like position in the group, I wouldn’t like this kind of approach. Throughout the entire book, the One Minute Manager seemed a bit short-tempered all the time, and a wee bit God-Almighty-like, ready to praise and smite at the same time.

To alter this radical approach, because at the end of the day, I do think it is a good idea, I sometimes criticise their work in the presence of the others. You don’t want to end up having your employees too content with their own work, this would leave no room for improvements. They would think, and justly so, as they weren’t told otherwise, that why improve they writing if their own manager thinks it’s glorious. It is really hard for me to do, but I think it’s working. They do tend to watch out for the issues I brought up publicly, and try to avoid them in the future.

Both appraisal and a reprimand should happen immediately and the employees should be aware of the fact that they are going to be appraised or reprimanded before it happen. I could agree with that statement, I am trying to promote openness within the team, which is hard because they still treat their work as school assignment and blush or stammer when I ask them about estimates and how far they’re progressed so I can adjust my planner. I think I should show them my plan, show them what work is being planned and for when, and include me as a resource in the plan, so they don’t feel threatened. The goal here is to feel as a part of a larger machine that depends on each mechanical parts, me – the manager, being a mechanical part as well.

In the end, I really think that the book is worth reading and familiarising oneself with, as it raises good questions, outlines great concepts even if it doesn’t explore them in great details.

Posted in Uncategorized | Leave a comment

Top Nav vs. Tripane (based on a discussion with my mentor DF)

Topic-based writing: tripane or top-nav for documenting software

One of the topics that I am currently interested in is topic-based writing. My company has just adapted MadCap Flare as the main authoring tool, and we have chosen top-nav paradigm as the deliverable hosted on the password-protected website.

During our last mentoring meeting, David and I attempted to discuss the whole notion of topic-based writing, starting with a small discussion around the purpose of writing and the type of audience to consider.

David believes, and I agree with him, that the layout of the output as well as writing approach doesn’t solely depend on the latest writing fashion or your preference, you need to consider your target audience, and what you want to document.

Is your audience used to printed manuals? Are these end users, or engineers which will probably depend on a good search functionality rather than structured content?

What do you want to document? Is it software per se: how it looks like, and how to navigate within the UI, or do you want to describe the tasks you can perform using the software as the tool?

Tasks are easier to describe with top-nav, each task being a separate searchable topic. However, I find it challenging to describe UI using topic-based approach. This is why for the UI parts, I create one topic that serves as an introduction to the UI, and lists all main parts/sections of the software, providing links to the relevant topics describing them in more details. That way, I am sure that all topics are easy to find, as you can either search for them using the built-in search field, or view the list of software sections and choose the one you are interested in.

Pros and Cons of Tripane

Tripane is considered old-fashioned. However, it may be a good transitioning media for the audience that is used to printed output; it has a TOC pane that organises the content. That way the reader is always aware of where they are and how they got there. It imposes clear structure and does not include any distracting fancy design that sometimes gets in a way of obtaining information you are after. It depends on the tool used to create the tripane, but most of them have pretty decent search optimisation functionality, so it is easy to forage for information, if the reader doesn’t want to go through more traditional approach, i.e. reading the TOC.

Top-nav imposes a real web experience – the reader is usually supposed to make search against the information they want to obtain; it puts the reader right in the middle of the content, and by doing so also out of context, making it is easy to get lost. A reader needs to be a proficient web user to know how to forage for information within the top-nav system. Thy need to know how to make search in the most effective way to be able to extract exactly what they came for. One way to cater for this is to write a meta topic on how to search for information, so even the most inexperienced readers can learn how to do it effectively. It is also very important to provide additional introductory information, to minimise the feeling of being lost. I find this the most challenging part of topic-based writing, as you need to very precise and clear using as little words as possible, making sure the reader won’t skip this part.

Every writing style has its pros and cons. The most important thing to keep in mind is to know your audience expectations, and if you as a writer don’t have this luxury, cater for many different scenarios using the tools you were given. I think, my documentation team is on the good path, trying to cater for people accustomed to traditional top-down writing approach that incorporates TOCs, and people who come to the website just to search for one particular piece of information, and don’t want to waste time on looking through indexes or navigation tips. Having said that, I do recognise the long path before us to learn how to use metadata more proficient to get the best of each approach.

Posted in Uncategorized | Leave a comment

General After-UA-Europe-conference Thoughts

Conference content this year was a very broad, focusing on soft skills, theoretical aspects of documentation, documentation administration and also how to style your CSS and adapt your content for multiple media, talks that personally I enjoyed the most.

Below, I will try to describe and discuss 3 talks that I enjoyed most.

Practical Information Architecture: Building Templates For Better Content by Kelly O’Brien

Although a bit too high-level and without any solid examples, Kelly’s talk on information architecture was well-worded and it was a treat to listen to her explaining the importance of a well-structured  documentation.

As compelling as it sounds, unfortunately the challenge is that rarely a company will burn resources and funds to design IA first and content later. It is often the other way round, and it’s typically the template being adapted to the content. I am speaking from the perspective of an author hired by a fast-paced Agile software company whose main objective is to feed information to the field engineers (technical reference, UI overview) and end-users like sales and marketing people (release notes) as quick and efficient as possible. We do try to be consistent, but we are far from having a style guide and dedicated templates for each type of content.

I had an impression that Kelly dedicates most of her time to writing style guides and designing templates rather than being focus on the content that she admitted is contributed by many people of many background (engineers, sales, etc.), so I could understand the importance of a “mastermind” who is responsible for unification of the content provided. In a small company like mine, with two technical authors being responsible for the knowledge centre’s content it is not so hard to maintain consistency, hence the lack of a style guide. However, having said that, I would love to see us spending more time on administrative aspect of our work, organising templates, generating a basic style guide and documentation procedure overview.

Best-in-class Embedded UA by Scott DeLoach

This talk was a bit of an anathema to the talk given by Kelly, as it was spiked with examples on how to organise your content to adapt to different types of media (desktop, tablet, mobile).  By the use of simple jQueries, you can cater for different types of media used for reading your content. To be honest, I never took it into consideration, but the fact is that our browser-based content in all probability is rarely read on the 15″ screen, which I personally use for writing and reviewing content. I would imagine a warehouse worker, who needs to review information will use his work tablet, as this nowadays is the standard media used by non-sedentary employees who need something more handy than a laptop. I fully intent to think learn more about CSS and how to develop more responsive content that will automatically adapt to different media based on typical break points.

Zurb Foundation and Other Responsive CSS Frameworks by Matthew Ellison

Matthew Ellison allowed us to look under the hood of his UA Europe website and explained how he implemented Zurb Foundation responsive front-end framework that is free to use. As he explains, ZURB is a a collection of HTML, CSS and Javascript that makes it easier to maintain and design a website. The main idea of ZURB, from what I understand, is allowing a website designer to rework static content so that it can be viewed within various media and a plethora of different screen sizes. I took a look at the ZURB foundation website, and it’s full of friendly tutorials and walk-throughs that makes the whole learning curve ever so easy. I am looking forward to try it out. I don’t see it being used in my company, as Flare offers a really decent automated almost to the last bit (and very adaptive, if you want to change something) front-end solution, so there’s no need to reinvent the wheel, but the tutorials themselves offer a nice refreshed look at JavaScript, HTML and CSS for seamless browser experience.

Teaching by Example: worked examples in the documentation of complex systems by Caroline Loveridge

I have to admit that I went to this workshop not driven by the need, but rather I was lured by the slides. When I was browsing through speakers’ slides, the presentation prepared by Caroline Loveridge struck me as outstanding, just the right amount of information, great examples (duh, the presentation title!) and … yes, nice images. Basically, it appealed to all my senses.

So what is a worked example? It’s a step-by-step instruction on how to solve a certain problem. It is especially crucial if a software you document is complex, and combines various combinations and settings. Good worked example has a clear structure, is prompted by images and informs the reader what the steps lead to. In other words, a worked example defines the “problem”, provides instructions, and explains what happens after the reader accomplished given set of steps.

To my huge surprise, the workshop that I have attended just because I liked the slides, proved to be the most important to me, as I was able to apply my newly gained knowledge to my line of work. I came back to work, and started working on my own set of worked examples that I called, processes to distinguish it from the rest of documentation types I had: setup and configuration instructions, reference materials, etc. My process documentation defines the purpose of the instructions, and provides a generic set of steps (e.g. how to ship an international package) followed by steps closely related to the software (e.g. how to ship an international package using the App developed in-house). The second part contains images of the software. Given instructions cover only a basic idea, but once you complete the task, you may move to “Related Content” and see more complex processes (e.g. how to ship an international shipment but one consisting of multiple packages).

All in all, the conference was a real treat to me, and it was really good to attend it for the second time. Unfortunately, as we’ve learned at the end of the gathering, this was the last UA Europe conference, which makes it even more special to me that I was able to participate.

Posted in Uncategorized | Leave a comment

Couple of thoughts on Agile methodology based on a discussion with my mentor DF

Text written: 16.12.2016

16 December I met with my current mentor to have a discussion around Agile methodology implementation within software development cycle. The aim of the chat was to establish some ground rules for documentation; should it be a process on its own, running parallel to the whole cycle, or should it be fully implemented within said cycle?

The most important aspect of Agile workflow according to David is its flexibility. In other words, you should feel free to experiment with the approaches and ideas, and then if it works for you, it means that it is a good workflow. The key is to remember that being rigid with Agile structure contradicts the whole notion of this methodology.

Following this logic, it is my understanding that Agile should be adapted to the company, and what is even more important, to the team – not the management. The task of management is to understand the “MO” of the team, let them help choose the tasks, and then, factoring all these in, make a coherent plan and prioritise the tasks.

How does the documentation writing process fit into this? It is the technical author’s responsibility to interact with the development team, and become part of the team. We cannot expect developers to know documentation impact a feature implementation will bear. They will have an idea, but it is the author’s responsibility to communicate clearly the scope and the timeframe. According to David, our role is to be pragmatic, and to manage expectations. Just as we need to understand the feature, development also needs to understand documentation impact of that feature.

One of David’s suggestions is to use scrum as the means of asking questions and interacting with the team. I don’t usually ask questions during the scrum. I use scrum to communicate potential problems with the feature I might encounter while testing . I do it ad hoc, because it might prove to be consequential to the feature concept, or it might be a bug. If I don’t have a proper feature demo, what I usually do is to document the feature as I see it, and write the list of questions that come to my mind, as I write and test it. I expect to have my doubts answered as part of a technical review. I usually write an email with the list of questions, and attach a Word document in which I additionally leave the comments that indicate the particular section in the manual or particular feature description that I found problematic. This approach works fine for most developers. However, some of them prefer talking about the feature, in which case what I would do is to divide the review into two parts. Part one, I would learn about the feature by listening to the presentation, or participating in the demo. Then, I would bring the document up on the projector, and go through the trickiest parts with the developer.

All in all, the better the user story is written, the lesser interaction between the developer and the technical author is needed. This is something both David and I agreed on wholeheartedly. A good user story is usually a good ground work for documentation preparation. It can even help an author create a good skeleton, based on the user acceptance criteria and the feature description.

To sum up, the whole discussion proved the point that Agile is all about communication between all members of the team, including documentation team.

TOPICS TO CONSIDER: documentation support and how we handle it outside Agile workflow (Kanban board), is there a value in bringing it into the cycle?

Posted in Uncategorized | Leave a comment

My thoughts after MadCap Flare Basic/Intermediate Training

Text written: 25.06.2016

June 21-24, 2016, I attended an interactive online training course with Mathew Ellison taking us through basic and more advanced features of MadCap Flare. This is an on-going learning curve for now for me. We have implemented, in my company, MadCap Flare software to produce html and PDF outputs. As we have 3 different software (branded for different customer), we have decided to host 3 documentation sites. The idea is to try single-sourcing as much as possible using Flare projects that for now are stored in Dropbox to maintain basic version control. We are planning on using conditional tags to mark the three target channels. Due to the lack of resources and strict deadlines, we haven’t implemented snippets yet; however, we are planning to use this feature retrospectively; this would involve two main exercises: identifying all areas in documentation that could be converted into snippets, and then a gradual task of converting them into ones. I think we are doing well with the time constrains we have; however, I do sometimes have a feeling we are rushing too much with the content, forgetting about all administrative tasks (glossary, styles catalogue, procedures overview, etc.) which will affect us in the future.

Posted in Uncategorized | Leave a comment

Tech writers vs Devs ratio

Text written: 27.07.2016

Cherryleaf revisits the post from 2003 on ‘standard’ ratios between developers and Technical Authors. Did anything change from 2003? Is the ratio still valid?

What they suggest as an optimal solution is a ratio of 17.6% , or roughly one in six (1:6) technical communicators to programmers. This is taking into account automatization of certain document types, like API docs.

I tend to agree with that. Right now we have 2 technical authors and 12 active developers, and the workflow has never been better. Apart from producing meaningful output, you need to take into consideration time you spend on preparing your tools (layout arrangement, output configuration, etc.), researching new technologies, administrative tasks and doc maintenance (version control, peer reviews, etc.)

I would maybe stretch the ratio a bit, I think it would still be perfectly manageable with more developers onboard without a huge impact on documentation quality.

Having said that, I have not taken in consideration procedural documentation that we stopped maintaining due to other more pressing priorities (2-3 week sprints with a product patch release at the end of each sprint).

Posted in Uncategorized | Leave a comment

Non-native English in technical communication

Text written: 1.05.2016 as a speech proposal for TCUK conference. The proposal was rejected.

Is it possible for a non-native technical author to write coherent and clear documentation? How does second language influence writing?

Short overview of the proposed speech:

  1. Intro
  2. What is second language and SLA? How I learned English
  3. How does it influence my writing?
  • Daily struggles and pitfalls (over-correcting, too much time spent on grammar discourse)
  • Is it all that bad? (high grammar awareness makes it easier to edit a document in terms of: Okham’s razor, jargon, figurative and poetic lg (metaphors, similes, connotations, etc.)
  1. Summary (as usual, there are pros and cons)


Technical Authors do not write for writing sake, their writing is not so much about beautifully structured breath-taking narrative, as it is about dry, informative and very precise message dressed in as little words as possible. Such writing improves the chances of a reader not being left all confused and overwhelmed. This also means that in 90% of readers will actually read the sentence till its full stop.

What defines good documentation? It is fairly simple: it needs to be concise, clear and easy to read. That is to say, a reader can extract information that is useful to them, does not have to think twice what a particular sentence/phrase/word means, and can put the acquired information to some practical use. Basically, good documentation is “reading with understanding” taken to the next level of simplicity.

In a dangerous world of crystal-clear precision, Ockham’s razor and procedure flow charts, is it possible for a non-native technical author to survive? Is it a curse or a blessing?

To answer these questions, I would like to look into the difference between hermetic language, acquired without a cultural context, and the one acquired naturally and based on a set of stimuli received from the surrounding environment.

Which aspects of bilingualism contributes to writing in CNL (controlled natural language)? Here I would like to list some pros and cons focusing on daily struggles but also small victories. The biggest advantage is, undoubtedly, linguistic precision stemming from the ability to convey a message using language not tainted with jargon nor any linguistic shortcuts imposed by the culture. However, at the same time, the biggest disadvantage is the fact that very often a non-native techy author is the biggest critic of their own work, undermining themselves and their linguistic capabilities. How can one overcome their “grammarphobia”? In this line of work, is it really such a bad thing?

Posted in Uncategorized | Leave a comment