How do you launch a suite of Mobile, Web, and Voice products from ideation to go live in 12 weeks?

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.

My next chapter

This isn’t something I thought I’d be writing – if you read my recent piece on Thrive Journal, you’d know how excited I was to join Thrive Global. I’d long admired Arianna, and when we met it was immediately clear that we share so much: mission, values, a dedication to science-based approaches – along with a lot of common friends and even our foreign accents. And I wrote about the twist of fate – several twists, in fact, that it took to bring me to Thrive.

And now life has thrown me another twist, which is that I’ve just accepted a job as Chief Product & Technology Officer at The Wall Street Journal. It was an emotionally difficult decision – when I joined Thrive I felt then, and still do, that living my life by the Thrive principles and helping others do the same was my calling.

Working with the team at Thrive has been everything I thought it would be, and has only deepened my passion for the mission. And personally, it’s been especially rewarding working with Arianna. We hit it off right away and that’s only continued since. I’ve learned so much from her that I’ll take with me in my life ahead. Most of all, her incredible ability to connect warmly and authentically with everybody around her — not just about their work, but about their lives away from the office. You don’t just join the team, you become part of a family. And that’s why this was such an emotional decision.

But this role at The Wall Street Journal is no ordinary opportunity, and I certainly wouldn’t be leaving if it were. There were several considerations: this is a newly created position and represents the culmination of what I’ve been working towards my entire career. It’s also a chance to reunite with several former co-workers who have remained dear friends. In the end, after a lot of persuasion, and an opportunity too good to refuse, I decided to make the move.

I’m excited, but also sad to leave. I’m incredibly proud of what we’ve built at Thrive Global. In three months we launched a media platform, a behavior change platform, an e-learning site, an e-commerce site and a number of specialty apps, including for Android, iOS, Amazon Alexa, and Chrome.

I am incredibly grateful not only for what I’ve learned but also for the friendships I’ve built and that I know will continue. And I’m especially grateful to Arianna for bringing me into Thrive and into her extended family. If I’ve learned one thing from this experience it’s that we never know what twists of fate the future may bring, but what I do know is that incorporating our Thrive principles into my daily life and my work at The Wall Street Journal will make both me and my colleagues healthier, happier and more productive.

How to be an effective CTO

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

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

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

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.

To put the above in context, I am sharing some tips from my recent talk at the Fastly 2016 Summit.

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.

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.

 

Why Data Breaches Don’t Hurt Stock Prices (Harvard Business Review)

If you are a CEO, CFO, corporate board member or investor, the article Why Data Breaches Don’t Hurt Stock Prices published on Harvard Business Review by Elena Kvochko and Rajiv Pant may be of interest to you.

STEVEN MOORE

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.

Why investors should care about cyber security breaches

If you are interested in business, technology, and cyber security, you may enjoy my article about why investors should care about cyber security breaches. I co-authored it with Elena Kvochko, a leader in the field of cyber resilience.

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.