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 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 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 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.


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.)

A Memo on Leadership by a Colleague

I regularly ask other people for their advice, insights and knowledge about leadership and management. The following is a memo a colleague recently wrote for me on the subject.

[memo begins]

Loose your ego

Leadership isn’t about you or what you can do and rarely are people motivated to make you look good. Itâ s all about what you can do for your team. The team needs direction and something to achieve for you. You could almost think of yourself as the helpless grandparent who has work to do and lavishes accolades whenever one of those items gets completed. It may strike some as odd, but most people are eager to please and get a great deal of satisfaction knowing they completed something of meaning. Often the work you have to offer can lack significant meaning in and off itself. So, as the leader, you can provide meaning or significance where none exists. It can also be your responsibility to paint a picture or create the mission.

In the past, when faced with an impossible task of creating meaning in completely insignificant work, I found I could inspire the team by getting them to focus on creating very elegant code. Since the result of the work was clearly not fulfilling, I reasoned with the team that producing the most elegant code would be fulfilling. The tactic got the team past the barrier and gave them the motivation to finish the required work. I really doubt I could have had the same success by appealing to get the work done just so I would look good.

Get to know your team, learn about them

Itâ s really important to take the time to know the people who work for you. Even if you have a hard time opening up to people, you need still to make the effort. Generally, people really appreciate that you actually take time to get to know them. For each person that reports to you, do you know if they are single/married? Do they have children, grandchildren? What do they like to do outside of work? What is the person passionate about? All of these are really good, safe questions to get answers to. The more you get to know the person, the more of a connection you will have. Essentially, you are building a bond of trust and mutual respect and maybe even friendship.

Listen and listen well

Listening is one of the most important skills you can learn. Yes you can learn to be a good listener with practice, patience and perseverance. Never, ever listen to formulate an answer for someone. I’m sure you can remember more than one time when you raised an issue or made a statement and there was that genius in the room who retorted a quick “You should just do ….”  Personally, people like that are never ever helpful and worse yet, they get me upset and I instantly loose a percentage of respect for the person.

When someone else is speaking to you, make every effort to understand what that person is saying to you. Try not to interrupt and let that person complete their thought. When the person has completed their thought, try and repeat back to that person what they said e.g. “So, what you’re trying to say is…” or “If I heard you correctly, youâ re saying…” The general idea is to repeat back to the person what they said thus making a reasonable effort to demonstrate that you have heard and understood. By asking, you give the person you’re speaking with the opportunity to clarify their point to their satisfaction.

The next step in listening is to make that split decision to offer a suggestion or sympathy. What is often missed, is that many times someone is raising an issue in an effort to find someone who can sympathize with him or her or offer a little empathy. They may feel they are the only person with the current concern. Most people aren’t usually looking for you to give an answer either, so it can help to ask additional questions for clarity after you have communicated that you understand how they feel. e.g. That’s got to be really frustrating.  Yeah, that would upset me too. Those types of statements can really help communicate a level of understanding or empathy, and that may be all the person is after.

Always take the blame; never take the credit. Take the heat for the team and give the team all the credit.

Nothing makes a group despise their leader/boss/manager more than watching them take all the credit and blame anyone else for the failures. Maybe that’s a little harsh, but itâ s really important to create a safety zone for your team where they know that you have their back. I like to think of this as the “obsessive parent” sometimes. My kids can do no wrong when their exposed to the world, but when we get back to the house we talk. In much the same way, taking the blame for your staff does not mean letting things slide. It means that you take the blame in the eyes of your boss but take the team or the team member aside to coach and mentor. When addressing issues, it is often better to address the issue instead of assigning blame e.g. “Our last release had too many bugs that could have been caught that is causing too many distractions. What can we do to improve?”

If you have a team that is struggling to succeed, is it really the teamâ s fault or is it your fault as the team leader? If you’re honest with yourself, the problem always lies in the leader. Itâ s your responsibility to identify the problems, come up with remedies and implement. Until identified problems are resolved, you are better served by taking the blame. It will give you credibility with your team and those you report to because it shows a level of maturity, competence and sacrifice.

Treat everyone with respect

This isn’t limited to your team in any way. Its important to treat your team with respect and dignity all of the time. Do not belittle them. Do not disregard them. Do not take them for granted. When you treat others with respect and dignity you are then seen in a positive light as someone who is respectful.

When looked from another angle or from the negative, you want to avoid being known as someone who has no respect for others, you will be avoided like the plague. Disrespecting or disregarding people is a recipe for failure.

Find someone and something to praise every day

People have a natural desire for recognition. They want to know that the work they perform has meaning and is valued. Most will not come out and ask for praise, but everyone, no matter how much they profess to the contrary, actually appreciate recognition and genuine praise.

Sure, there may be people who are so upset or jaded that you begin to doubt if it matters much if you give thanks or congratulate them. However, I would argue there is simply more work to accomplish before praising offers any significant value to them. That jaded person is simply the result of previous leadership failures and requires a lot of effort on your part before this tactic works.

Use constructive criticism. Never shoot down ideas

Really, don’t ever just tell someone they’re wrong or what they’re thinking won’t work out of hand. That kind of behavior will just kill a person’s desire to think outside of the box or to even come up with anything creative. They will quickly start to think, “Why bother?”

I once worked with a boss who was masterful at getting me to see the flaws in my plans without ever telling me something wouldn’t work. Whenever I came up with an answer that had a flaw, he would ask me questions about my direction that illuminated a problem I was unaware of e.g. “How will your solution stay within constraint…?” It was a really powerful technique that provided many additional benefits. I usually learned something I wasn’t aware of, maybe in the business or the platform, I was able to “save face” and wasn’t put off or discouraged from trying to solve a problem or be creative.

Offer up challenges and don’t do the work

Software developers like to solve problems and I will bet that most of them actually love solving problems. Itâ s your job to give them something to solve and follow the advice on constructive criticism. Whenever you have something that needs to be done, try really, really hard NOT to come up with a solution. No one likes to be given something to implement – there’s no fun at all and it does very little to stimulate the team. It may take a little more effort on your part, but instead of giving them something to build, give them a challenge with measures of success. They may or may not come up with the solution you thought or be done in the way you would do it, but if it solves the problem with all of the constraints you listed, then let it go (see first point on ego)

Help everyone

I have found nothing better to gain influence like helping others. A good leader is always looking to help, to be a person of service. Nothing is more indispensable like a helpful person. Help usually does not mean doing someone’s work for him or her, but it can be, especially if the team is on a tight deadline. When leading a team of software developers that has too much work to do, I recommend taking on all of the worst tasks. Aspiring developers want the cherry work, the stuff that will get them noticed. If you take that work away and leave them the drudgery, it won’t make you any friends. Remember that it’s not about you, it’s about creating a team that loves to work for you. So, if you take away the garbage and leave them the fun stuff, you’re definitely helping.

[memo ends]

(Posted with permission.)

Organizing a Digital Technology Department of Medium Size in a Media Company

There are many good ways to organize your technology department. This article presents some of them. It is written for a CTO or VP Technology leading a medium size department looking for suggestions on organizing or reorganizing your Digital (Web, Mobile) technology department. It is best suited for you if your organization has the following characteristics:

  • You manage software engineering, implementation and technology operations for 3 or more digital brands.
  • Yours is a medium size technology department with somewhere between 20 to 100 technology staff.
  • Internal corporate IT functions such as desktop support, telecommunications services and internal business systems are beyond the scope of this article.

The Venn diagram below presents one model of organizing your department into 3 sub-departments.

Web Technology Department Organization
Web Technology Department Organization Venn Diagram Illustrating Purposeful Overlap Among Sub-Departments

Some CTOs in smaller companies organize their technology departments as 2 sub-departments: Software Engineering and Technology Operations. Software engineering is the function that is responsible for developing and implementing Web & Mobile application software. Technology Operations is responsible for running, maintaining and supporting the Web applications.

If you operate 1 or 2 digital brands (Web sites), having these 2 sub-departments is a good approach. For 3 or more Web sites, organizing Software Engineering into Site Engineering and Platform Engineering has some benefits.

Site Engineering is focused on working on the Web sites’ direct projects. Its work includes

  • Small and large projects for adding or changing functionality on the Web sites
  • Bug fixes on the Web site applications

Platform Engineering is typically smaller than the other two organizations and typically includes functions like:

  • Architecture across sites
  • Shared applications across sites
  • Common libraries across sites
  • Research & Development (R&D)

Technology Operations includes functions such as:

  • Systems & Applications Administration
  • Infrastructure Management
  • 24×7 Tech Support
  • Builds & Configuration
  • Release Management
  • Testing & Quality Assurance (QA)1
  • Technical Analysis
  • Technical Project Management
  • Budget Management

These three departments have purposeful overlap of responsibilities as illustrated in the Venn diagram above. That helps minimize the chances of the departments becoming silos with walls between them. For success, it is important that your entire department functions as one integrated unit. Some shared goals & responsibilities are required for mutual success.

DevOps2 is a set of processes, methods and systems for communication, collaboration and integration between departments for Development (Applications/Software Engineering) and Technology Operations. Its purpose is to facilitate meeting business goals by producing good quality software products and services in a timely fashion. It is where development methodologies (such as agile software development) occur in an organization with separate departments for Development, Technology Operations and Quality Assurance. Development and deployment activities that need deep cross-departmental integration with Technology Support or QA require intimate multi-departmental collaboration.3

llustration showing DevOps as the intersection of Development (Software Engineering), Technology Operations and Quality Assurance (QA)

To make this work, you need 3 directors who head up these departments who work well together, collaborate often and are not sensitive about their turf. They should know that a successful technology manager is not an individual-only contributor, but a great team player with peers. They should have strong goodwill among each other and welcome each other to work directly with their teams. Such a collaborative team is essential.

Article Updated: September 25, 2010

  1. QA can also be set up as an independent department. []
  2. WikiPedia entry on DevOps []
  3. Article: What is DevOps? []