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.
Rajiv spoke at Fastly‘s Altitude 2016 Summit in San Francisco. #Altitude2016 was a full day conference featuring technical content and idea sharing about the edge, web performance and content delivery from industry experts. Rajiv spoke from his personal knowledge of a CTO’s role in getting, maintaining, and developing buy-in for infrastructure engineering projects from business stakeholders.
Here is a link to the slides.
A CTO’s job combines Culture, Technology, and Operations. Each of the three is necessary; a field of knowledge, experimentation, and learning in itself; and interdependent with the other two. To be successful as a CTO, you need to work on and continually master all three areas. If you’d like to see the responsibilities of a CTO as a picture, here is a mind map illustrating things CTOs are responsible for.
Culture, as the first part of a CTO’s job is the answer to who you are you as a team. A CTO’s role starts with the culture they develop, evolve, and lead by example.
Culture can be described as people, knowledge, and behaviors in a community connected by relationships, norms, and purpose.
The people in a CTO’s job include internal stakeholders and colleagues, engineering and product teams, partners, and external customers. As CTO, it is your job to foster constructive collaboration among them.
Regular sharing of knowledge among members and teams is essential for a culture to be developed, sustained, and evolved. As CTO, you are accountable and responsible for compiling, updating, and sharing knowledge among your teams, stakeholders, and customers.
Observed behaviors describe your culture as it really is. Talk is hollow if you and your teams don’t walk the walk. If you are in a leadership role, people observe what you do, and learn from and emulate what you do, far more than from what you say.
An article in the New York Times about Google’s findings on what makes teams effective reports: “Norms are the traditions, behavioral standards and unwritten rules that govern how we function when we gather: One team may come to a consensus that avoiding disagreement is more valuable than debate; another team might develop a culture that encourages vigorous arguments and spurns groupthink. Norms can be unspoken or openly acknowledged, but their influence is often profound. Team members may behave in certain ways as individuals — they may chafe against authority or prefer working independently — but when they gather, the group’s norms typically override individual proclivities and encourage deference to the team.”
I recently participated in a week-long Design Thinking workshop hosted by Matter.vc that used various activities to reinforce the critical importance of having norms in a team. The Matter boot camp is valuable because it brings many best practices in product development from successful startups to traditional media companies wanting to embrace lean and agile product engineering. The path to mastery is to practice, test, and learn.
The path to mastery is to practice, test, and learn.
As CTO, you need to appreciate, learn, and apply cognitive science, behavioral psychology, and social science with integrity and in ethical ways to develop a culture of excellence. You must not let a mentality of us-versus-them take root between technology staffers and other parts of the company. Remind yourself and your team members that your allegiance to your whole organization is not less than that to your department or team.
For example, if as CTO, you are resentful of the marketing department and you mock the Chief Marketing Officer and her team, then your team will absorb this poisonous behavior from you. If you disparage your boss behind her back while pretending to be loyal in front of her, your team will learn to do the same to you. If you put the needs and desires of the technology organization ahead of those of the overall organization, then the teams that report in to you are going to act similarly towards your overall technology team. To be a good corporate citizen and team player with your peers is not only the right thing to do, but is also in your self-interest.
A mistake that CTOs sometimes make is that they organize their team and prioritize their work based too much on what they think is best for the company mainly from the perspective of technology.
A mistake that CTOs sometimes make is that they organize their team and prioritize their work based too much on what they think is best for the company mainly from the perspective of technology. This results in their stakeholders not seeing eye to eye with the tech team, and stakeholders complain that “things here take forever to get done.” Whenever you hear something like “work takes ages to complete,” there is a deeper problem underneath: The real problem is that engineering and stakeholders are not on the same page about priorities and are not communicating sufficiently with each other about value, progress, problems, and risks.
You can implement the most suitable rapid development practices (e.g. continuous delivery, agile, and lean startup methodologies) and use the best modern techniques, tools, and technologies (e.g. microservices, machine learning, and magic :-) ), that deliver projects with great speed, scalability, and success, but if you and your stakeholders are not in sync, things will be perceived as too slow, stubborn, and substandard.
Without a good culture, technologies and products decay and operations fail because people do not do the right things towards the shared mission.
Technology, as the core part of a CTO’s job, is the answer to what you do as a team.
Technology includes engineering, architecture, data, infrastructure, scalability, reliability, trust, security, privacy, and other ingredients. The specific areas of technology in a CTO’s purview vary based on the organization, its scale, and condition. Here is an example of an organizational structure that worked well for a smaller media company and another that helped a larger media company be successful.
Even though most CTO’s job duties do not include writing code yourself, to be a credible CTO, you need to not only know how to write good software code, but you should also enjoy doing it as a hobby. You must have a passion for many areas of technology combined with a perpetual desire to keep learning as technologies progress.
As CTO, you are the head coach, mentor, and guide to the technology staff. You preside and govern, not dictate or micromanage. You are not a middleman requiring every communication, decision, or solution to go through you. You are sincerely interested, engaged and involved in the work your teams do but you are not an obstacle. You are a connector who links the technology staff with other members of the organization. You remember that you have two ears and two eyes but only one mouth, so you listen and observe more than you talk. You respect the makers and the managers who report in to you because you are both their teacher and their student.
Without good technology, operations are inefficient and have trouble overcoming roadblocks, resulting in undesirably slow progress and heavy costs. With good technology, there is a strong sense of pride and that helps develop a culture of excellence where recruiting, retention, and productivity flourish.
Operations, as the integrating part of a CTO’s job, is the answer to how you do your job as a team.
Operations can be described as how and how well things get done and are delivered. Operations span how resources (including costs) are allocated and managed, how processes and systems work, and how trade-offs should be made. They involve managing the portfolio of projects, products, and services; prioritization; and decommissioning and letting go of products and projects.
Any team that does product development, infrastructure engineering, or provision of services needs to be operationally effective. For this, you and your team need to track progress, record data, measure results, report results, compile lessons learned, and implement improvements. Continuously.
Operations are critical to every organization’s success. This is where the rubber hits the road. You can have a wonderful culture and innovative technologies, but if you don’t get projects done successfully, you won’t have the other two for long.
5 Lessons I learned as a CTO in major media companies
To succeed as a CTO or head of engineering, you need to work with the APIs of your fellow human beings
1. Instead of trying to be salesperson, be a friend
- It is better to win people over, than to sell them your idea
- Don’t push your solution. Draw others to your solution
- Don’t pander either. Win over
- Don’t make B.S. claims about future benefits of the project. Instead, emphasize the purpose and passion
- Don’t try to falsely attach your infrastructure project to a product development the business has asked for. Present it on its own merit
- Don’t spend your time as a technologist writing a business justification. Partner with a finance or business analyst to do that
- Empathize with your business colleagues and help them empathize with you
2. Speak to the heart, not just to the brain
- Go beyond making a rational business case. Generate excitement about the engineering work
- Getting true buy-in requires evoking emotion and passion
- Identify an external enemy
- Share your genuine fears about potential losses resulting from getting hacked or systems crashing.
- We are all averse to losses
- Make it “our” project instead of “my” project. Request business stakeholders to talk about the project to their colleagues’ stakeholders, and bosses. Encourage them to include it in their presentations.
- By doing this, they make a public commitment to it
3. Leverage reciprocity
- Deliver successes to the business to build credibility first
- Before you pitch a major infrastructure project
- As a new employee, don’t use up your honeymoon credits on a project whose benefits to your stakeholders aren’t as clear
- When your colleagues ask for something that you don’t value as much, be open minded to them
- Your colleagues will reciprocate by embracing your ideas if you embrace theirs
4. Don’t be a “middleman.” Be a connector
- If you are a CTO or senior manager, it is in your interest that your business colleagues know, appreciate, and have direct connections with your teammates
- Their expertise supports and complements yours
- They bring additional credibility
- You make a stronger case as a team
Invite business colleagues to select gatherings of the product engineering teams
5. Regularly discuss your projects and their value with your colleagues
- Never assume that your business colleagues won’t understand or appreciate technical stuff. Be a translator
- A critical part of your job as a technologist is to regularly describe what you do and its value to your colleagues
- …and vice versa. Take an interest in what they do
Where to go from here
So you are about to or have just started as a CTO or other technology leadership position. What’s a practical way to proceed? Here is a template for a 90 Day Plan for a CTO in a New Job.
This article is mirrored at LinkedIn.
Rajiv Pant is managing partner at Solutions at Scale, a technology leadership and management consulting firm that advises established companies and startups. Prior to this, as CTO at The New York Times, he led the development of numerous acclaimed products during his four year tenure. His leadership experience includes Conde Nast, Reddit, and Cox Media Group. Rajiv was honored as a Young Global Leader by the World Economic Forum.
As The New York Times’ chief technology officer, I had a crucial role in guiding the company’s successful transition to digital, and an opportunity to work with and learn from some of the most talented journalists and software engineers in the world. It’s undeniably one of the world’s most influential institutions doing work in the public’s interest, and has been since 1851.
I love The Times and its vision, and cherished my four years there. But, there was something missing in my career. I had been in CTO roles at four major media companies, with accomplishments I was proud of. However, I didn’t want my 3 year old son Fitz Raj to know me for only being a successful corporate executive, but for accomplishing something significant for the greater good.
So I took a leap: A couple of weeks ago, I left The Times to join Vinit Bharara and fellow Times alum Paul Smurl at Some Spider–a startup creating a network of brands dedicated to community, content and commerce. In many ways my move is not surprising. Throughout my career friends and colleagues asked me why I hadn’t “done the startup thing yet.” People saw me as an entrepreneur inside and wondered why I hadn’t already become one.
However, until I met Vinit and Paul, I hadn’t come across a company with all the right ingredients. The most important thing about a startup, even more important than the idea, is the team that supports it. An idea evolves over time, the product and business pivot as the environment changes, and the technology improves and gets disrupted. But throughout, the people make all the difference between success and failure. Both Vinit and Paul share a dedication to building an outstanding team, which is a large part of why I chose to become invested in the company’s vision.
The people also make all the difference when it comes to giving back, and working for the greater good.
My grandfather, Dr. Krishna Chandra Pant, was a doctor under British rule in India. As the chief medical officer (i.e. the only doctor) at an institute in Mukteshwar, his job was to only treat the (mostly British) employees of the institute. But he knew no borders when it came to helping the sick and injured. There was no other doctor for more than 50 miles, so he welcomed all patients who came to him and he gave them the same treatment. His British employers didn’t appreciate that, and a drawn out lawsuit ensued. The courts finally ruled in his favor and he prevailed in not only keeping his job, but also in gaining the formal authority to treat all patients equally.
He continued his medical practice out of the family home long after his formal retirement. I remember he used to treat poor patients without charging them fees. He would even give them the medicines free of charge.
In 2014, the World Economic Forum selected me to join its Young Global Leaders community. I didn’t realize at the time the impact it was going to have in my life. I thought it was simply another award. But I met exemplary leaders like Ayesha Vera-Yu, Analisa Balares, Pardis Sabeti, Lorna Solis, and others who have dedicated themselves and already accomplished more for the greater good of humanity than I could imagine accomplishing in a lifetime. I realized that YGL wasn’t really an award for past accomplishments, but an invitation to start a new journey committed to help make the world a better place.
We should challenge ourselves to make the world a better place
in the ways that we can.
Making the world a better place is no small feat. Last year, when the Ebola epidemic was at its peak, I felt a strong desire to help, but I didn’t know how. I have always admired the organization Doctors Without Borders for the work they do around the world. While many people and organizations claim to work for a greater good at personal cost, people who work at Doctors Without Borders live (and die) by that. In the past, I helped out by giving them small donations here and there, but I wanted to do something more impactful.
My move to Some Spider gives me a chance to use my specific abilities to make a substantial contribution to a cause that I believe in. As a part of my hire, I decided to pledge 20% of my equity to charity, most of it to Doctors Without Borders. This may come as a surprise, especially to those who know me only as a CTO. But just because we have talents in one field doesn’t mean that we can’t be of service in another.
We should challenge ourselves to make the world a better place in the ways that we can. For the doctors serving overseas, their commitment may be their life. For me, it’s dedicating myself to a company that shares my vision, and dedicating part of the reward from being at that company to the people on the ground who can make a difference where I can’t.
My grandfather passed away before I could make him proud. I pray that I am able to do something for this world that fills his great-grandson with pride.
The following is the farewell memo I wrote to my colleagues at The New York Times.
Subject: A career is like a garden
As you may know, I have accepted an offer to join a startup on June 1st, and therefore have made the difficult decision to leave The New York Times, an organization I have loved being part of for the past four years, and a brand I have admired all my life. I will continue to be a loyal reader, vocal supporter and paying subscriber.
I care deeply about The New York Times. Let me know any way I can be helpful. I remain personally invested in your continued success.
Over the past four years, many of you have become close friends to me. The Times building has felt like my second home. I will leave with fond memories of being part of this wonderful institution.
Paraphrasing Leonard Nimoy’s farewell Tweet:
A career is like a garden. Perfect moments can be had, but not preserved, except in memory.
Live long and prosper.
On Mon, May 4, 2015 at 12:21 PM, Marc Frons wrote:
I am writing to let you know that our CTO Rajiv Pant is leaving The Times to join a startup focusing on community, commerce and content, where he will be heading up technology, product and design. Rajiv told me he has long wanted to be an entrepreneur, and this new position gives him the opportunity to roll up his sleeves and help a startup he co-owns become a successful business.
In his four years at The Times, Rajiv has made an invaluable contribution to the company. He has played a leading role in building and managing the technology behind the growth of our digital business, and the expansion of our mobile and data science teams. Always a magnet for top talent, Rajiv’s proteges can be found in every area of the technology department. Most of all, he has been an unflagging champion of the culture of technology innovation at The Times, and a model of collaboration and good cheer.
Rajiv has agreed to stay on for the next two to four weeks to aid in the transition and help in the search for his successor. Although we are sad to see him go, we wish him every success with this new venture. Regards,
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.