From Consultant To Consultant In A Box
I am consultant-in-a-box. Well, it’s a fancy title I made up for myself to spark some enthusiasm and curiosity when responding to dreaded “What do you do?” question. For the last two years my job was to create content (documentation, guidance, and code samples) for developer audience – I am programming writer. Before that I was Principal Consultant in the field working for MCS (Microsoft Consulting Services). Titles aside what really is important here is to answer a simple yet tough question “What success looks like?” Before starting a job as programming writer back in 2010 I met with few super smart people from diverse spectrum of disciplines. I wanted to pick their brain and hear insights for success.
The key theme was along the line – “keep your customer in the center.”
Wisdom of obvious? Maybe. But the more I thought about this simple truth the more insightful it got.
To add clarity to the key theme I came up with the simple frame for how to think about the customers. It is customer types or personas and questions they might ask.
Customer Types – Personas
Back when I was an MCS Principal Consultant I worked with several types of people. I recalled the following personas:
- Business Stakeholder who buys software from Account Manager – must know the big picture.
- Account Manager who sells software to Business Stakeholder – must know the big picture.
- Architect who figures out feasibility of the solution – must know what’s needed for the solution.
- Dev lead who designs the solution – must know internals and how it works.
- Developer who implements the solution – must have end-to-end how-to’s, reference, and code samples handy.
- Test Engineer who tests the solution – must know how to automate test harness and monitor the test lab.
- Operations Engineer who maintains the solution in production – must know how to monitor and troubleshoot the system in production.
- End user uses the solution – it should be desirable, useful, and usable.
What Drives Customers
During my work in the field as consultant I observed time and again customers get frustrated by investing too much time to complete the task, losing money on labor or missing customers demand, and poor performing software. I also observed customers get frustrated by unusable software (one of the reasons they call consultants). So the main drivers for customers are:
- Save time
- Reduce cost
- Improve quality
- Enjoy experience
Development Lifecycle Phases
I found it helpful to look at the development lifecycle to better understand each persona customer type:
- Inception – Account Manager, Business Stakeholder, Architect discuss the requirements. The outcomes are the problem and the vision statements. To test the outcome one can ask a simple question “What is it we really need?”
- Planning – Architect and Dev Lead discuss and define the building blocks for success. The outcomes are the architecture blueprint and the project plan. To test the outcome one can ask a simple question “Does it fit our vision?”
- Build – Dev Lead and Developers work hard to realize the vision and stay on plan.
- Stabilize – Test Engineer helps answering two questions – is it functional? Is it usable?
- Maintenance - Operations Engineer works hard to keep up the SLA’s for End User.
After reviewing the data points above I came to a conclusion that the problem scope can be summarized by three questions.
- What’ is it? or What’s in the bag?
- How does it fit? or When do I use what?
- How to make it work? and then How to keep it working?
It is interesting that “How it works (internals)?” question is not explicitly there.
Testing For Success
Based on the problem scope and the related questions I cam up with an Information Architecture I used to create technical content. This should help find relevant content quickly. The result speaks for itself, here couple of quotes from key folks whose success depends on the technology and the guidance:
- “That is a WOW piece of work! From an architect’s perspective I think I would find it incredibly useful.”, Principal Security Architect
- “Amen to that! … the stuff you have out there is awesome if not essential. Keep it coming!”, SENIOR CONSULTANT
- “It looks amazing !!! A. It includes lots if knowledge (easy to find the knowledge you need). B. It provides practical info how to implement the scenario.”, Security MVP
- “GREAT !!!CONTINUE TO MAKE US HAPPY AND PRODUCTIVE, …!!!”, CTO of ISV
- “[I like] the consistent approach used in each of using minimal amount of text and easy to follow model to describe scenario and solution” , PRINCIPAL Architect.
- “Yes, it is useful and it’s nice to have a 1 stop shopping wiki like this.” , founder of ISV
- “Useful: Absolutely. Usable: Yes. The method of presentation: short scenario description, consistent diagrams and brief highlights etc. is ideal for quick consumption.”, Sr. ARCHITECT, MCS
- Content Usability: Design Pages For Scanning
- First Law Of Usability – Don’t Make Me Think, And Other Facts Of Life On The Web
image by Yuri Samoilov16 July 2012