Activities, Outputs, and Outcomes — A framework for your job

This is a framework for understanding, describing, and performing your job duties, roles, and responsibilities. You can use this as a template to create a useful job description that you would actually use while you are in a job.

It divides a job into three categories: activities, outputs, and outcomes. To be successful in your job, it is useful to understand the difference between these, and to achieve an optimal balance spending appropriate time and energy on each.

This article is written for multiple audiences — people who are primarily in maker (direct contributor) roles as well as those primarily in leadership and management roles. The ratios of time spent on activities, outputs, and outcomes as well as the types of items in each varies based on your particular job. You should determine in collaboration with your organization how your job should be defined and described in terms of these.

Ask yourself this question: After being hired in a job, do you ever refer to your HR job description to guide you or to check if you are doing what your job is described as?

I prefer to use this framework rather than the commonly seen job descriptions. Most job descriptions are not real descriptions — they are job advertisements to get candidates to apply to. After the employee is hired, they rarely, if ever look at their job description. Conventional job descriptions are usually a formality to check certain HR, legal, or compliance boxes. The commonplace job description is like the marketing ad for a product. This is meant to be the summary version of the owner’s manual. For examples of longer handbooks for jobs, you can view my previous articles 90 Day Plan for a CTO in a New Job and How to be an effective CTO.

You can’t magically drive results. To meet your company’s objectives and key results (OKRs), you must spend time on activities and produce outputs. I link to more information on OKRs later in this article in the outcomes section.

Activities

Activities are the things you spend time doing in your job. Certain activities may be doing the work of creating deliverables, but others may not deliver tangible outputs. Some activities may directly lead to measurable business results, but others may not.

Activities can be beneficial to the organization or they could be busywork of low value. It is better to spend more time on activities that lead to outcomes  — or at least to outputs — than on activities that can’t be confidently tied to valuable business results.

Always to know its clear purpose before engaging in an activity. For example, attending a meeting is an activity. If you do not have a clear and valuable purpose for why you are attending a meeting, you are likely wasting your and others’ time.

Here are some examples of activities.

  • Reading and answering emails and slack messages. Being responsive
  • Attending (preferably participating in) meetings
  • Talking 1:1 with colleagues to build good professional working relationships
  • Interacting with team members and colleagues to uplift their morale
  • Mentoring and coaching others
  • Organizing working sessions, meetings, and presentations
  • Resolving conflicts
  • Reviewing the work output of others
  • Soliciting input from other teams
  • Providing substantial and insightful feedback provided on work, documents and plans created by others
  • Leading by example. Demonstrating leadership, management, and ethical behavior
  • Demonstrating expertise or deep experience in one or more areas
  • Interviewing job candidates
  • Collaborating with others and helping them with their work

The activities in the above examples by themselves are often insufficient. You could have a very busy day at work every day, and yet accomplish little in terms of valuable and meaningful results. Imagine a car stuck in sand, spinning its wheels but not moving forward or a wild animal in a zoo enclosure pacing back and forth yet accomplishing little beyond getting light exercise.

When I ask someone how their work is these days, and they reply “busy, very busy,” I’m usually unimpressed. It implies that their schedule is busy and it is likely not by their own choice. Unless you work in extraordinary circumstances — as a hospital ER or are an active duty soldier engaged in a war — that response likely signals your schedule is completely out of your control — a sign of weakness and poor prioritization. When the first word that comes to someone’s mind in describing their work is “busy,” it is a sign that they are far more focused on activities than results. If you had to describe your work in one phrase, I’d prefer hearing words like “exciting,” “meaningful,” or “challenging“.

Don’t be busy, be purposeful

Outputs

Outputs are the tangible deliverables you create or co-create. Outputs are maker’s work. Your team’s outputs do not count as your own unless you had a significant hands-on part in creating them as a maker, not just as a manager.

While outcomes are the most valuable part of any job in any organization that cares about results, outputs are the most easily measured and attributable to you. Examining your outputs is one way for your company to know about the value you personally add. Good outcomes usually result from teamwork. Because outputs are tangible and can be reviewed by others, their examination leads to your management being able to continually better align your work to the organization’s desired results.

Creating outputs on a regular basis also helps you avoid failing the lottery test:

Below are some examples of outputs. To be considered outputs, these must exist in a tangle form as physical and/or digital product. For example: documents, presentations, spreadsheets, diagrams, videos, software code, or physical objects. Drafts and prototypes are acceptable.

  • a vision, strategy, plan, recommendations, and works of thought leadership
  • thoughtful memos
  • written down plans
  • proposals, business cases
  • competitive research
  • budget spreadsheets
  • diagrams
  • status reports with evidence of material work you did or progress you made
  • software code
  • multimedia, videos, photos, artworks
  • digital and/or physical products

As a general best practice, you should not create most of your outputs in isolation. You should share early drafts and prototypes of your work and ask for input and feedback. Your colleagues should have clear idea what you are working on and why. Stanford Professor Baba Shiv’s Art of the Imperfect Pitch is another reason to share early versions of your work.

I can’t stress enough that to be considered your outputs they need to be authored or significantly co-authored by you. Even if your job role is strategist, planner, or thought leader, you still need to write down (or make a video of, if that’s your thing) your strategy, plans and thoughts. Writing down ideas also helps refine and evolve them. On that note, while slide presentations have their value and place in specific situations, they should never be a substitute for a well thought out document. To quote the famous and successful founder and CEO of Amazon:

“The reason writing a ‘good’ four page memo is harder than ‘writing’ a 20-page PowerPoint is because the narrative structure of a good memo forces better thought and better understanding of what’s more important than what.”

Jeff Bezos

Outcomes

Outcomes are the results. These are the most valuable and important part of your job. The activities you engage in and the outputs you produce should be towards these results. I recommend the OKR framework that I mentioned near the beginning of this article. Here is a link to a comprehensive guide to objectives and key results

Below are some examples of types of results. Results should be measurable (preferably with numbers), directly lead to objectives being met, and of real, high value.

  • meeting or exceeding revenue, profit, and/or growth targets
  • delivering products and services to customers that meet their needs or delight them
  • process changes in operations and/or product areas resulting in savings of time and/or money
  • culture improvements shown to increase employee morale, productivity, and retention
  • other measurable improvements that can be directly or indirectly attributed to your work
  • better collaboration or relationships among distinct teams leading to quicker and higher quality product delivery

Next Steps and An Alternative To This

To illustrate how to use this framework, I’ll share an example of a job description using this as a template at a future date and update this article. If you try this out and would like to share yours, Tweet it to me at @rajivpant and I’ll include a link to it from this article.

An alternative to this framework I’ve provided is Holacracy‘s system of describing a job a different trio: purpose, accountabilities, and domains. I plan to incorporate some lessons from those into this system in future and will update this article.

Takeaways

To avoid the cycle of often being too busy yet not accomplishing the goals to your organization’s and your satisfaction, consider describing your job using this framework to create a quick user’s guide for your job.

If you go so far as to create a handbook to help you do your job better, include checklists because they are effective. The CTO 90 Day Plan I mentioned earlier is such a checklist.

Once you have drafted an actionable job description you can refer to periodically, use it to guide your work. You should review your actual work (your calendar, deliverables, and results) along with your job description on a regular basis, making changes to your actual work or to the description, as appropriate.

Such a living handbook is also immensely valuable to the next person in your job (when you are are in your next even greater job.)

Maker’s Schedule (For Managers Too)

The following memo from a department head to staff is an example of how to implement a productive maker’s schedule at your workplace. This approach recommends starting with baby steps, evaluating results and making changes accordingly.

Comic strip from XKCD

Dear Colleagues in the Technology, Project Management and Product Teams,

Executive Summary:1

We are implementing a maker’s schedule starting this Friday May 31st which means developers will have from 12 noon onwards on Fridays to focus exclusively on writing code, with no meetings or other interruptions. (This also applies to other contributors besides developers. For more information, see details below.) The goal of this is to increase productivity, creativity and job satisfaction. This practice is based on science and employed by other successful organizations. We request your understanding, your support, and your help in making Friday afternoons meeting-free.

The Details:

We are implementing a maker’s schedule system starting Friday May 31, 2013. What is it? A maker’s schedule is calendar scheduling system that gives a group of people a continuous multi-hour block of time to focus on their work with minimal productivity diminishing things like distractions, context switching or frequent interruptions.

The word maker in this context often refers to people like software engineers, designers, testers, systems engineers, infrastructure engineers, documentation authors, editors or anyone else making something. What they are making could be software code, documentation or a configured server. It need not even be technical work. Managers also do the work of making: writing a memo, editing a budget spreadsheet or creating a slide presentation, for example.2

The human brain has evolved in a way that creative work, innovation and productivity are maximized when a person is able to focus and work on one task at a time for multiple hours. It takes several minutes, often half an hour or longer to get in the flow state of mind that results in peak performance at work. Hourlong or half-hour long meetings peppered throughout the day with breaks in between supposedly to do productive work result in low quality work, cause stress, and lead to unhappiness.

One way to do better quality work, get more done and be happier in your job is to divide your day into two halves. Get all your meetings, emails and administrative tasks done in the first half and spend the entire second half of the day doing enjoyable creative work that puts you in the flow state of mind. You will leave the office less stressed, more satisfied and happier each day.

If you are interested in learning more about the maker’s schedule concept, the article titled Maker’s Schedule, Manager’s Schedule by Paul Graham is a good introduction.

Below are the answers to some frequently asked questions.

Q: Who does this policy apply to?
A: This applies to all makers as listed above, especially all engineers and quality assurance staff, people who spend the majority of their time writing, designing or implementing software code, systems or designs. This also extends to those in management roles who’d like to use this time to do maker’s work.  At this time, we are not applying this policy to employees with special employment contracts like guild or unionized employees.

Q: When will we have maker’s hours?
A: Fridays after 12 noon, i.e. the latter half of all Fridays going forward until further notice.

Q: Does this mean I can go home early on Fridays?
A: No. This is not a summer hours policy. This is meant to be uninterrupted software engineering and development time. It does not change anything about when you are expected to be in the office. The prior agreed upon schedules you have with the company will continue.

Q: Why Fridays and why only Friday afternoons?
A: We analyzed our organization’s current meetings schedule and found that Friday afternoon is the period where there are least meetings and those meetings can be rescheduled with least impact. We are starting the pilot program with Friday afternoons. After some months of evaluating the results, we may extend it, keep it the same or cancel it. Until Further notice, this policy applies only to Friday afternoons.

Q: Does this mean I only get Friday afternoons to write code?
A: No :-) What this means is that we must all do our best to not organize, nor attend meetings on Friday afternoons so that time is exclusively reserved for writing code, building systems and doing other maker’s work. You are expected to do maker’s work every business day and to manage your own schedule to block off enough time to do that on others day the same way you already do.

Q: What about production emergencies? Can I get called into an emergency meeting to deal with a critical production emergency?
A: Yes. Production emergencies qualify among the rare exceptions.

Q: What about meetings between makers? For example, between two software engineers.
A: That is a slippery slope. We are strongly discouraging meetings on Friday afternoons in this policy, but we are not the meeting police and are not going to ban all meetings, especially if all the attendees have a strong desire to meet. We trust you to use your best judgement and lean towards not holding meetings on Friday afternoons unless you determine you have a good reason to make an exception to this policy. Our suggestion is this: Pair programming is encouraged. Working sessions are ok, assuming that in the entire working session multiple makers are making something together. However having staff meetings at this time is not a good idea. Nor is it a good time to have your weekly 1-on-1 with your manager. Remember your manager is likely to be using this time to do their own maker’s work. So on the question of can developers hold a meeting with just developers at this time, ask yourself why. What is the meeting for? Is it a working session where each of you will make something together? If yes, that’s likely fine. If not, schedule it for another time.

Q: What should I do when someone invites me to a meeting on Friday afternoon and I plan to observe the maker’s schedule and write code at that time?
A: Please always be respectful, courteous and friendly while declining meetings. Use your discretion and common sense. If the meeting request comes from someone it may not be wise to decline, consult with your boss. In many cases, you can politely, respectfully and nicely point the meeting requester to this policy at http://www.rajiv.com/blog/2013/05/24/makers-schedule-for-managers-too/ and suggest or request another time. Letting your collaborators know about this policy in advance will also help.

  1. Thanks to David Perpich for suggesting this executive summary. []
  2. Since processing email has become such an information overload problem, distraction and waste of time these days, we hesitate to classify doing email as productive maker’s work. If you don’t have the unproductive bad habit of checking your email every 15 minutes and instead you process your email during a few blocks of time a day, you may consider email productive work too. []

Management & Technical Career Growth Tracks

Described here is one way to enable technologists to grow their careers in your organization while still allowing them to focus on the type of work they are best at and enjoy most.

The typical management career growth path does not suit some technical people. These information workers need to grow in their careers (gain greater compensation, responsibilities and influence) without having to become managers of other people. A good way to achieve that goal is to create a technical career growth track in your organization.

The following diagram and table illustrate management positions alongside technical positions of similar levels.

Click on the diagram above to view it as a zooming presentation.



This system isn’t meant to be rigid. It is designed to find a good balance with most organizations. That balance, i.e. how many “levels of authority” there are will differ across organizations. The focus of this article is to provide a technical track as an alternative to management tracks, whether there are 3 levels or 13. There are pros and cons of having fewer “bands” or ranks. (As a side note, some organizations like the military1 require lots of ranks.) Ranks need not signify a strict hierarchy where one can only go from one rank to the one immediately above. The ranks could simply be used as “salary bands” and the levels of “hierarchy of authority” could be fewer.

In this model, for example, an architect role is at the same compensation and influence level as a manager role, assuming that the particular manager and architect being compared add similar value to the company. To accommodate more ranks, a senior architect would be at the same level as a senior manager.

If the organization prefers consistent titles for levels regardless of track, the system could name them like this: vice president & fellow, senior director & architect, etc. In the case of a fellow who is at an SVP level, they could be named SVP & distinguished fellow.

Here is a definition of the fellow role from WikiPedia:2

Large corporations in research and development-intensive industries3 appoint a small number of senior scientists and engineers as Fellows. Fellow is the most senior rank or title one can achieve on a technical career, though some fellows also hold business titles such as vice president or chief technology officer.

Such a technical career growth plan brings many benefits to your organization.

  • It helps retain good technologists who want to grow in their careers, but want to do keep doing the type of work they are best at and enjoy doing: technical work.
  • It avoids brilliant technical people from being “pushed” (by themselves or their supervisors trying to “reward” them) into people-management responsibilities.
  • It reduces situations of having too many people-managers but not enough people-management positions over time as people get promoted.

Care should be taken to recognize that some technical people do enjoy making the transition to people-management roles and the presence such a technical track should not discourage them. Having an alternate career growth track option is about presenting employees with more than one choice.

Similar system are also used to enable non-managerial career paths at editorial and design departments at newspapers, magazines and other newsrooms.

Related Articles on Other Sites

Some updates to this article are published at http://www.rajiv.com/blog/2012/12/17/tech-career-tracks-v2/

(Thanks to Brian MurphyBobby Chowdhury, and Janet Kasdan for their contributions to this system.)

(Updated: 2012-Dec-17)

  1. US Military Ranks []
  2. Definition of Fellow at WikiPedia http://en.wikipedia.org/wiki/Fellow and Wikitionary http://en.wiktionary.org/wiki/fellow []
  3. IBM or Sun Microsystems in information technology, and Boston Scientific in Medical Devices for example []