Why I left being CTO of The New York Times, joined a startup, and am pledging 20% of my equity to charity

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.

Dr. Krishna Chandra Pant (Rajiv Pant)
Dr. Krishna Chandra Pant (Rajiv Pant)

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-YuAnalisa BalaresPardis SabetiLorna 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.

The author and his son, Fitz Raj Pant (Rajiv Pant)
The author and his son, Fitz Raj Pant (Rajiv Pant)

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.


Follow Rajiv on Twitter. This essay was originally published in Quartz.

A career is like a garden (farewell memo to nytimes colleagues)

The following is the farewell memo I wrote to my colleagues at The New York Times.


Subject: A career is like a garden

Dear Colleagues,

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.

Working with you has been an honor, a pleasure, and a learning experience for me. I would love to stay in touch. You can connect with me on social networks and find my contact info via rajiv.com.

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.

Rajiv

On Mon, May 4, 2015 at 12:21 PM, Marc Frons wrote:

Dear Colleagues,

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,

Marc

7 minus 1 reasons why technology/engineering teams should work on projects

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.

  1. Deliver products, features and services as driven by business priorities (#product)
  2. Improve time to market (#speed)
  3. Improve quality of experience (#quality)
  4. Improve efficiencies and reduce costs (#cost)
  5. Provide security and protect privacy (#security)
  6. Continue to be able to survive, do business and operate (#survival)
  7. 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.


This post is mirrored at LinkedIn and Medium.

 

CTO Mind Map: Culture, Technology, Operations

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.

CTO-Mind-Map-highlevel-view-export-v1.0
CTO Mind Map: Culture, Technology, Operations: High Level Summary View

 

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.

You can view it as an image in the SVG format (scalable vector graphics) in your Web browser or download the editable document in XMind format.

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.

CTO Mind Map version 1.0 by Rajiv Pant
CTO Mind Map version 1.0

 

Cyber Resilience Towards the Quantification of Cyber Security Threats

The World Economic Forum and its partners have developed and shared a way for organizations to calculate the impact of cyber security threats. The framework, called cyber value-at-risk comes at a time when cyberattacks are increasing in velocity and intensity, and when 90% of companies worldwide recognize they are insufficiently prepared to protect themselves against them.

Cyber Resilience workshop at the World Economic Forum meeting in Tianjin, China. September 2014.

Download the full report here: Partnering for Cyber Resilience Towards the Quantification of Cyber Threats

Cyber Resilience workshop at the World Economic Forum meeting in Tianjin, China. September 2014.

I feel honored to have been one of the participants in the development of this. The project is led by Elena Kvochko and team of the World Economic Forum in collaboration with Deliotte and other Forum partners.

Cyber Resilience workshop at the World Economic Forum meeting in Tianjin, China. September 2014.

The World Economic Forum announced this today at the annual meeting in Davos.

(Source: WEF Press Release: New Framework to Help Companies Calculate Risk of Cyberattacks)

9 Reasons Why News Media Web Sites Should Consider Moving to HTTPS in 2015

If you work in news media and are interested in technology, you may enjoy my article listing 9 Reasons Why News Media Web Sites Should Consider Moving to HTTPS in 2015. I co-authored it with Eitan Konigsburg and Elena Kvochko, two colleagues with expertise, deep knowledge and passion for cyber security, privacy and technology.

It is published on the Times Open Blog maintained by the Software Engineering Team at The New York Times.

My personal Web site, rajiv.com is served exclusively on HTTPS thanks to CloudFlare.

Dear Makers, On Fridays My Office is Yours — An Experiment

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.

Below is the memo I sent to my team. I’ll share the results of this experiment after a few months.


Dear Software Engineers and Technology Colleagues,

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.

This is an experiment. We will test, solicit feedback, measure and change. For example, if time-windows other than 2 hours work better, we will adjust the experiment.

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.

Details on how the sign up and feedback process will work to follow.

Thank you for your interest.

-Rajiv


This article is mirrored at LinkedIn and Medium.

3 Dimensions of a Technology Team

Organizing Software Engineering Teams to Balance Products, Partners & Professions

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.

It views the staff, roles and responsibilities in three dimensions: products, partnerships, and professions.

img

  1. Products and projects the technology teams work on
  2. Partners, customers, and stakeholders of the technology department
  3. Professions of the various technology staff members

Organization by products focuses on providing great user experiences via small, agile and nimble teams that have ownership of their work.

Organization by partners focuses on being an effective client-service organization to other parts of the company.

Organization by professions provides for learning, best practices and career development of the tech employees.

This article first describes the three models and then suggests ways to bring them together into one integrated organization design.

Organizing by small product focused teams

Product

A product is defined as something that customers use and experience. A product consists of features and functionality.

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.

Product Team

One way to think of a product team is as a mini-company within the larger organization. A product team has customers, which could be external, internal or both.

A product team develops the product, makes it available to customers (“ships” it), and maintains the product. Maintenance of the product includes new features, major upgrades and innovations.

Roles in a product team

A product team has several roles which are filled by professionals with certain skills, knowledge and interest.

The roles can be narrow in scope, like front-end JavaScript developer or broad, like software engineer. The roles include the professions of engineers, designers, subject matter experts, marketers, and managers. For a longer list of roles in a product team with examples, see the section titled “list of professions/roles” under organization by professions below.

People and Roles

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.

Team Size

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.

Proximity

For a product team to be successfully implemented, it needs to consider and address evidence-based management science related to human collaboration.

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.

Organizing by Partners, Customers, and Stakeholders

Aligning the technology department with business departments

In this model, each line of business, department and product/service at the company is assigned a technology partner in the technology organization.

Examples of stakeholders in a media company include the heads of advertising, marketing, finance, customer service and editorial.

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 may also serve as the solutions architect for the client, or may have solutions architects assigned to them.

Technology Partner Role Description

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.

The responsibilities of the partner include:

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

Organizing by Professions

In this model, the technical people are organized by the professions they choose to belong to.

Professions and Roles

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.

Each profession/role is grouped under one of five major categories:

  • Technologist/Maker
  • Designer/Artist
  • Subject Matter Expert/Analyst
  • Marketer/Seller
  • Manager/Admin

List of professions/roles

Technologist/Maker
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

Designer/Artist
User Experience Designer, Visual Designer

Subject Matter Expert/Analyst
Product Manager, Business Analyst, Journalist, Reporter/Content Author, Editor

Marketer/Seller
Salesperson, Marketer, Customer Service Representative, Internal Advocate, Documentation Writer

Manager/Admin
Project Manager, Finances & Budget Manager, Team & People Manager

Integrating the three dimensions

Now that we have described the three dimensions, let us discuss ways to make it all work together.

Reporting Relationships

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.

So rather than pretend that reporting relationships in a team don’t matter, it is important to address them in setting up these teams.

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

Departments by Profession

It is important to define what is expected of a primary boss in your organization so you can best determine how to structure reporting relationships. For example:

  • 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?

If your answer to the above questions is yes, then it is likely that setting up the primary reporting relationships by profession is a good solution for you.

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.

The overall technology department also assigns a technology partner to every other department by profession. That’s how these three dimensions come together.

Balancing Professional Departments with 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.

The goal of the functional department is to both support product/project teams and serve as checks and balances, but never to work against them.

Non-Technology Departments

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.


This article is mirrored at LinkedIn and Medium.

  1. 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  []
  2. If someone has scientific evidence supporting this, please let me know.  []

Victory is winning people, not defeating others.