Watch the 30 minute video on Cloudflare TV
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
- 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.
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.)
Many books on leadership are like fairy tales: Inspiring, but misleading about leadership that is actually effective in our real world. Real leadership — i.e. leadership based on evidence and science, and thus statistically more likely be effective in practice — is less commonly found in leadership teachings. Instead, what we often hear is “feel good leadership” that sounds good, but is often ineffective, or worse, counterproductive at worst.
Few books open our eyes by revealing truths hiding in plain sight. Thinking, Fast and Slow by Daniel Kahneman is one. Leadership B.S. by Jeff Pfeffer is another.
Many books, lessons, and word-of-mouth teachings about leadership are misleading, misrepresentative of real world experience, and based on feel-good ideals. There are five reasons why several things we are taught about leadership and management are wrong.
- Lack of Rigor — Many leadership lessons based on someone’s experience are not based on a systematic analysis of complete data, comprehensive understanding of circumstances, and other available options at the time. What worked for the winner may be simply chance (luck), weakness of the opposition, or insufficiently acknowledged help from others.
- Before and After — The behaviors that lead a person to a powerful leadership position are often not the same as the good qualities the person assumes later in life after they are already successful. Take the case of Bill Gates, who as a competitive businessman was a different person from the kind, caring philanthropist he is today.
- Delusion — Human beings have a positive, good impressions of ourselves that are often not accurate. Studies have shown that about 80% of people believe they are better car drivers than average, better looking than average, and better human beings than others. The Overconfidence effect and above average effect are well documented. How a successful leader feels they act (morally) is often quite different from what they actually do based on observation.
- Deception — Human beings, especially successful ones, lie, mislead, and often don’t give away their coveted secrets that given them their competitive edge. There is plenty of scientific evidence that lying is a common daily habit.
- Leaving a Legacy — Many leadership books and articles are written to make the author look good, to build a good reputation and brand for the leader, and to make money. They are not primarily written for the purpose of making other people successful, even if the author thinks so. This could be due to delusion, deception, or a bit of both.
For the above reasons, my friend Jeff Pfeffer and I sometimes say that most leadership books and products should be labeled like packs of cigarettes: “Warning: This information will make you feel good in the short term, but is likely to be harmful to your effectiveness, career, and well-being.”
So how should you minimize your time and effort wasted learning ineffective leadership and management methods that are likely to backfire?
I highly recommend reading the excellent book Leadership BS: Fixing Workplaces and Careers One Truth at a Time by Professor Jeffrey Pfeffer of Stanford University. It was finalist for the 2015 Financial Times and McKinsey Business Book of the Year and Best business book of the week selected by Inc.com. This book will help you identify real and effective leadership and management lessons based on evidence that are more likely to work than platitudes.
Disclosure: In the acknowledgements section of this book, Professor Pfeffer writes:
This book was inspired in part by my interactions with Rajiv Pant. It was Rajiv who first used the phrase “feel-good leadership literature.” It was Rajiv who provided some of the stories and examples incorporated in this book. But mostly it was Rajiv Pant who helped me see how much damage was occurring because of the current incarnation of the leadership industry. Rajiv’s support and friendship mean a great deal, not only for this book but in my life.
Pfeffer, Jeffrey. Leadership BS: Fixing Workplaces and Careers One Truth at a Time (pp. 221-222). HarperCollins. Kindle Edition.
My rating of this book: 5/5 stars.
In follow-up to earlier work on a) versions one and two of these technical and related career tracks, b) pathways for career development in product engineering, c) job titles, and d) employee evaluation & career development, here is an updated version three of the career growth tracks.
This version 3 includes software engineering & architecture, quality assurance & test engineering, data science & engineering, infrastructure & systems engineering, product & product management, and design & user experience. This version moves “chief” and “head of” type titles to the discretionary column, keeping only four main levels (contributor, manager, director, and vice president) with three sub-levels designating seniority within each.
This is presented in a Google Sheet embedded below with tabs containing areas like engineering and product. I’m also providing a direct link to to the Google Sheet you can copy and edit for use in your own organization.
As always, I’d love your feedback. Thank you.
Check out the blog post by Very, the product development partner I worked with in my previous job at Thrive Global to design, build and launch multiple Mobile, Web, and Voice-controlled products from ideation to go live in 12 weeks!
Thrive Global was created to end the stress epidemic. Founded by Arianna Huffington, the comprehensive platform tackles burnout — a widespread barrier to productivity and success. By delivering sustainable, science-based solutions, Thrive Global enhances wellbeing and performance, so that people can move from surviving to thriving.
Here are 6 reasons that should be used to justify, prioritize and classify projects engineering teams work on. The 7th item is not a valid reason to be used.
- Deliver products, features and services as driven by business priorities (#product)
- Improve time to market (#speed)
- Improve quality of experience (#quality)
- Improve efficiencies and reduce costs (#cost)
- Provide security and protect privacy (#security)
- Continue to be able to survive, do business and operate (#survival)
- Not a reason: Do not do it for vague “strategic” reasons that can’t be supported by one or more of the above six. (#invalid)
#Speed, #quality and #cost improvements are directly measurable. The results of the #product are measurable and its delivery is measurable as a binary. (E.g. was the feature delivered or not.) #Security fixes are measurable as binary. (E.g. Was the flaw fixed or not?) #Security upgrades can be compared to product upgrades.
Why a vague “strategic” reason is not a valid justification:
Organizations sometimes categorize projects as strategic and in alignment of the company’s mission, vision and value and use that as the primary reason to justify them. We do not support this as a valid reason, because it is too often misused as a way to work on pet projects or projects that someone in a position of power believes in but is unable to defend rationally.
Note that #survival is not the same as maintenance. Maintenance as a broad category is not listed here as a valid reason because maintenance is commonly misused as a bucket for holding on to projects that the organization should reconsider. Projects that can be well-defended as maintenance should qualify under the #survival category if it can be established that not doing them would prevent the organization from continuing to be able to do business. In other words, #survival is the small essential set of truly necessary maintenance projects. Using a stronger word like survival instead of maintenance can help avoid it being used too broadly.
We suggest tagging the projects and other initiatives your engineering teams are working on using these tags (#product #speed #quality #cost #security or #survival) as described above. In most cases, if more than one tag applies, tag it using the primary reason for doing the project. Only in exceptional cases should you tag the same project with multiple tags. By being strict about the reason, you will have greater clarity on why the project is being done.
In the role of chief technology officer, you have to be concerned with many topics. Some relate to functions you have direct supervisory responsibility for and some in areas that are managed by others but you still need to share responsibility for.
To keep all of a CTO’s concerns organized, I created this mind map using XMind. The items are classified under three major categories: culture, technology, and operations.
The purpose of this mind map are manifold. It serves as a visual job description. It is a map for CTOs to use to prioritize and focus their own work and that of their team members, based on the organization’s needs, the skill sets of the CTO and others. It is also used to identify gaps, both in terms of areas and coverage.
2019-August-7 Update: I now maintain this mind map on GitHub at https://github.com/rajivpant/cto-mind-maps
This mind map is a general version for CTOs across industries. You may find it useful to create a version of this specific to your role. I plan to expand this to include more information over time and to keep it current with the technology landscape. If you create versions of this that you are willing to share, please let me know via comments here or via Twitter @rajivpant.
Some senior leaders choose to work alongside their teams in cubicles, eschewing private office rooms. New York City’s former mayor Michael Bloomberg is an example. Facebook’s founder and CEO Mark Zuckerberg is another. Intel’s former CEO Andy Grove is often credited for setting this example.
As I’ve worked at various news media companies, I have been impressed to see editor in chiefs and other senior editors spend most of their working time in cubicles alongside their teams where the action in the newsroom is. They use their offices only when needed for privacy.
Having access to a private office room is useful too, whether you are a manager, maker, or both. So as an experiment, for one day every week, I decided to share my office with my colleagues in the technology team who don’t already have an office.
In the spirit of supporting our makers’ schedules, I’d like to make my office room available on Fridays to anyone in our technology team who does not already work in a private office. Here is how it will work. For any Friday, you can book my office in advance for a 2-hour period of your use. I will not use the room on Fridays. Instead, I will work at various temporarily available locations alongside other tech colleagues.
You can use my office for any productive work for your job. You can write code uninterrupted for 2 hours in a change of environment. You can pair-program with another colleague. You can use the dry-erase white wall in my office to hold a brainstorming workshop with fellow contributors. You can close the door and use the privacy to think of solutions to complex engineering problems in your work. Research indicates that a refreshing temporary change of environment can be helpful for such tasks.
I should also clarify what this is not meant for. If you need to hold a meeting, join a teleconferenceI suggest you continue to book regular meeting rooms. If you’d like to have a social lunch with colleagues, there are other more suitable places in our building. I’m offering my office to you on Fridays for maker’s work: to build software/systems, and to solve engineering problems in a temporary change of scenery.
I plan to run this experiment until at least the end of this year. If we determine that our software engineers and other tech contributors find this experiment productive, or even just enjoy having it as a part of our culture, we will consider continuing it into the next year.
This organizational design for a technology department aims to optimally blend the need for the technology team to be an engine of innovation, a customer-service organization and technically excellent.
- Products and projects the technology teams work on
- Partners, customers, and stakeholders of the technology department
- Professions of the various technology staff members
It refers to a digital entity, a physical good or a combination of the physical and virtual. For example, it could be a communication app that people use via their smartphones and computers. It could be a health device that people wear and access via their smartphones and computers.
The goal of a product is to meet customer’s needs & desires, to solve problems for customers including ones they didn’t know of, and to delight them. Many products aim to help make the world a better place, be it in small or big ways.
A Key Difference Between a Product and a Project
A project has preset start and end dates. A project, by definition, is supposed to be complete when it delivers its desired outcomes.
A product typically does not have a preset end-date. Most products are meant to exist and evolve for the foreseeable future. Products are (and should be) discontinued for good reasons (e.g. when they no longer have a viable future, or the organization needs to divert resources to other products).
Upgraded versions of the product are delivered via projects.
Projects are successful when they end.
Products are successful when they persevere.
These roles are not necessarily each held by different people. There is no prescribed restriction on who can hold which role or how many roles. Depending on the team’s needs, people’s skills & interests, and budget & resource situation, any permutation of the roles can be held by the people in the team.
A team should make the best decisions in allocation of the roles. The roles held by people are expected to change as the team scales up or down. The team should give importance to checks and balances via separation of duties where required for compliance of regulations.
As a minimum requirement, at least three people are required for it to be a product team that encompasses a sufficient set of the roles required. In a few rare cases, the team might be able to start with just two people.
An important recommendation is that the team “resides” together, i.e. works together on a weekly if not daily basis. If the team works out of the same office, then they should work in close proximity. If the team is geographically separated, like the teams at Auttomatic/WordPress, then they should have “virtual proximity”, i.e. be in close contact using video conferencing and other online collaboration tools.
The technology partner is a senior, widely-respected and influential member of the technology management team who serves as the primary technology leader for that business, department or product/service. Excellent client-relationship skills are a requirement.
The technology partner is the go-to person for all technology matters for the client department, including for engineering, project, and technology, areas that the technology partner does not directly manage. For example, a large department like Advertising will have projects that could span multiple tech departments.
- Assess Current Capability: Evaluate the current technical capabilities of all the technology systems.
- Define Future Capability: Understand strategic industry trends to plan future technology roadmaps.
- Technical Lead for product development: Responsible for technology execution, bringing new products to market and optimization of existing offerings.
- Plan Capacity: Translate roadmaps into future year capacity plans.
- Collaborate with other tech teams: Work with other product teams to service the needs of the business needs / departments / products where other teams in the technology organization are the owners of systems.
- Subject Matter Expert: As the primary contact for a business / department / product act as the SME for all technology.
This is a sample list of professions and roles gleaned from companies that have products in the digital media space. This list can be easily adapted to other industries, for example, by including the relevant subject matter expert roles. This was compiled between the years of 2007 to 2014 and reflects some prominent roles from then.
Software Development Engineer, Server-side “backend” Software Engineer, Client-side “frontend” Software Engineer, Mobile iPhone and Tablet Software Engineer, iOS Software Engineer, Android Software Engineer, Content Management (CMS) Engineer, Testing Engineer, App Release Engineer, App Operations Engineer, DevOps Engineer, Systems Administrator, Database Administrator, Security/Privacy & Compliance Analyst
Some people believe that “reporting relationships are irrelevant in today’s world”, but social science research has repeatedly proven this to be false.1 Reporting structures and hierarchies are an essential and integral part of any organization of humans.
Let us start by acknowledging that human relationships are complex, nuanced and changing, so there is no one formula to organize your teams. Every approach to organizing reporting relationships has its advantages and drawbacks. Here, we present a reasonable but imperfect model.
This model applies to medium to large size organizations, but not to small companies or very-large companies. In a small company of less than 10 people, there are unlikely to be departments by profession where people report into. In very large companies’ each business unit may operate as an independent company with its own departments by profession (e.g. their own finance, HR and engineering).
We also make some assumptions. For example, that it is preferable that each team member has exactly one primary boss who they formally report to.2
- Does a boss’ role include the long-term development of the employee’s career, existing skills and new skills?
- Does a boss need to be a subject matter expert in the chosen profession of the employee? Or, is the employee best served by being part of a team of others with the same or similar professions?
- Does a boss need to objectively and independently look at the employee’s work as serve as a checks and balances relative to the product/project team the employee is presently doing day to day work in?
What does reporting relationships by profession mean? It means that primary (and formal) reporting relationships are organized by departments of people in similar professions. For example, HR professionals report into the HR department, finance professionals report into the finance department and software engineering professionals report into the software engineering department.
In medium to large sized companies, having the primary reporting relationship by professional departments often has advantages over having direct reporting into the product/project team. In fact, most consulting firms use this model. Some of the benefits include:
- As new products are created, old products decommissioned and projects start and end, employees don’t need to switch from boss to boss. By having a boss who has seen an employee’s work over multiple products, services and projects, the employee can receive better coaching and development support.
- A boss who manages a team of employees of the same profession helps share best practices, standards and development opportunities across the organization.
- Such a boss can also serve as a check and balance for a product/project team’s short-term needs vs. the best long-term interests of the company. The employee has a primary person higher up to consult with outside their current product/project team.
Most medium to large size companies have departments by profession. For example, they have departments for finance, HR, sales, marketing, software engineering, design, etc. This makes good sense for reasons like the above.
Such departments often assign (or even embed) their professionals within other departments and product/project teams. For example, finance (or HR) may assign a finance person or team (or HR person or team) to work with the technology department. This person would likely be assigned full time to the technology department and work in close proximity to a part of it.
The organizational model recommended here views technology as a collection of departments by technical professions. For example, software development, quality assurance and testing, infrastructure engineering, and project management. Each of these technology departments embeds their staff into product/project teams.
In setting up direct reporting relationships by professional departments, it is critically important to not let the departments become siloed. Each employee should be focused on, deeply care about and feel accountable to the product/project they are working on.
When the person’s primary boss is a functional head outside the team they are currently doing day to day work in, both the employee and the boss must ensure the employee is highly committed to their product/project team whether it is in their department or outside it. One way to accomplish this: Each employee can also be accountable to a lead within the product/project team via a dotted line if needed. In some cases, the employee’s boss and their lead within the team can be the same person.
While this article was written for organizing technology departments at companies where a substantial amount of work involves software engineering, the thinking here might be adaptable to other types of departments. If you have thoughts on how to do that or have other approaches to organizing teams in organizations, please do share them.
- Hierarchy is Good. Hierarchy is Essential. And Less Isn’t Always Better by Professor Bob Sutton at Stanford University https://www.linkedin.com/today/post/article/20140112221140-15893932-hierarchy-is-good-hierarchy-is-essential-and-less-isn-t-always-better [↩]
- If someone has scientific evidence supporting this, please let me know. [↩]