Dear Family and Friends, I’m moving into an exciting new job at News Corp, the parent company of my current employer, The Wall Street Journal and Dow Jones. Below are the announcements from Matt Murray, Editor-In-Chief of The Wall Street Journal & Dow Jones Newswires; and from Ramin Beheshti, Group Chief Product & Technology Officer of Dow Jones. The announcement from Matt was reported on earlier at other sites and the announcement from Ramin is shared here with permission.
Announcement from Matt Murray, Editor-In-Chief of The Wall Street Journal & Dow Jones Newswires
Feb 20, 2019
Most of you will have seen by now the exciting news that Rajiv Pant has been promoted to a new role as Deputy Chief Technology Officer at News Corp. This is great news for him and for the newsroom; I expect he will continue to be actively involved with us going forward and will help facilitate the next stages of tech development. In just two years as our CTO, Rajiv has been a transformative presence, bringing in a great many new talents and helping our products and technical capabilities march forward on many fronts. Thanks to him, product, design and engineering have been ever more central to the newsroom–as they must be for our continued success.
Rajiv will be with us for several more weeks before moving upstairs to his fancy new digs, and we’ll soon share plans on how we will advance the work he has undertaken. In the meantime, please join me in congratulating him and thanking him for all he’s accomplished here.
Announcement from Ramin Beheshti, Group Chief Product & Technology Officer, Dow Jones
Feb 20, 2019
As you may have read earlier today in Marc Frons’ announcement, Rajiv Pant has been promoted to the Deputy Chief Technology Officer of News Corp, reporting to Marc.
Over the last two years, Rajiv has helped transform WSJ Technology. He reimagined what it means to be a team, by bringing together the Product, Design and Engineering groups. He also evolved how we measure our successes by promoting OKRs across the department and built a stronger, more open relationship between the Newsroom and Technology.
While he is going upstairs, he won’t be out of reach. In his new role, Rajiv will help drive global digital product and technology initiatives, and continue to work closely with many of us across the department. He will also focus on developing innovation and culture, sharing many of the great ideas from his time at Dow Jones with the rest of the News Corp family. I’m excited to see what he accomplishes in this new role.
Rajiv will officially transition to his new role over the coming weeks. Please join me in thanking him for all his contributions to Dow Jones and WSJ Technology. He has truly been a valued member of my Technology Leadership Team and I am delighted to have another strong partner at News Corp.
GROUP CHIEF PRODUCT & TECHNOLOGY OFFICER DOW JONES
This is a checklist for a new CTO, head of Product, or leader in a similar role starting in a new job. It is meant to kickstart continuous improvement in your product engineering organization. I encourage you to take a scientific test and learn approach to everything you do. You should customize this template based on your own experiences over time. If you find it helpful, please feel welcome to send me additions and improvements to this list.
Repeat the following seven steps iteratively to make incremental and continuous improvements.
1. Understand your job. Learn the organization and industry you are in.
Make a list of the areas you are responsible for. These are likely to include:
Technology: Software Engineering, Infrastructure Engineering, DevOps, Cyber Security, Systems Operations, Application Support
Product: Product Management, Project Management, User Experience, User Interface Design
Data: Data Science, Data Engineering, Data Visualization
Meet customers, executives, stakeholders, colleagues, and team members.
Connect with a network of your peers outside your organization.
Collect, compile, and synthesize information into knowledge.
Check: How are we doing in relation to our existing metrics for success?
Identify common themes, patterns, and problems.
Consider retaining the services of an executive coach.
2. Define and revise measurements for success.
List metrics for the success of the company as viewed by shareholders.
Prioritize metrics for the success of the teams you manage and how they relate to the metrics for the success of the whole organization.
Determine: What metrics are no longer a priority?
Determine: What new metrics do we need to add?
3. Articulate your vision and strategy.
Clearly communicate it to customers, executives, stakeholders, colleagues, and team members. On a regular basis.
Meet regularly with your team members, peers, executives, stakeholders, customers, partners, and vendors. Human relationships and face to face communications (when feasible) are essential.
Host regular 1:1 meetings with your direct reports, at least once a week. team members
Host regular all-hands meetings and communications. Monthly all-hands for staff less than ~100 people depending on space. Quarterly all-hands for staff more than ~100 people, depending on space. Encourage your departments to hold regular all-hands meetings of their own.
Host regular social, relationship building events and activities. For example, a monthly celebration event to mention professional and personal milestones that people want to share.
Align team members towards common good, shared goals.
Ask team members how they are doing. Are they happy in their jobs? Are their jobs exciting, challenging, and rewarding?
Solicit advice, including leadership advice from your colleagues, regardless of their level or experience. You can learn important leadership lessons from people who report to you. This also encourages your colleagues to become leaders.
Make each team increasingly autonomous and self-sufficient while enabling collaboration and economies of scale.
For example, by moving to a microservices model, using tools such as Docker, hosted on a cloud service provider (AWS).
Thank you for reading this and for sending me suggestions to make this list even more helpful to others.
This article is mirrored on LinkedIn. It is a part of the ctobook series of articles related to #culture, #technology, and #operations: three critical part of a Chief Technology & Product Officer’s job.
The following memo from a department head to staff is an example of how to implement a productive maker’s schedule at your workplace. This approach recommends starting with baby steps, evaluating results and making changes accordingly.
Dear Colleagues in the Technology, Project Management and Product Teams,
We are implementing a maker’s schedule starting this Friday May 31st which means developers will have from 12 noon onwards on Fridays to focus exclusively on writing code, with no meetings or other interruptions. (This also applies to other contributors besides developers. For more information, see details below.) The goal of this is to increase productivity, creativity and job satisfaction. This practice is based on science and employed by other successful organizations. We request your understanding, your support, and your help in making Friday afternoons meeting-free.
We are implementing a maker’s schedule system starting Friday May 31, 2013. What is it? A maker’s schedule is calendar scheduling system that gives a group of people a continuous multi-hour block of time to focus on their work with minimal productivity diminishing things like distractions, context switching or frequent interruptions.
The word maker in this context often refers to people like software engineers, designers, testers, systems engineers, infrastructure engineers, documentation authors, editors or anyone else making something. What they are making could be software code, documentation or a configured server. It need not even be technical work. Managers also do the work of making: writing a memo, editing a budget spreadsheet or creating a slide presentation, for example.2
The human brain has evolved in a way that creative work, innovation and productivity are maximized when a person is able to focus and work on one task at a time for multiple hours. It takes several minutes, often half an hour or longer to get in the flow state of mind that results in peak performance at work. Hourlong or half-hour long meetings peppered throughout the day with breaks in between supposedly to do productive work result in low quality work, cause stress, and lead to unhappiness.
One way to do better quality work, get more done and be happier in your job is to divide your day into two halves. Get all your meetings, emails and administrative tasks done in the first half and spend the entire second half of the day doing enjoyable creative work that puts you in the flow state of mind. You will leave the office less stressed, more satisfied and happier each day.
Below are the answers to some frequently asked questions.
Q: Who does this policy apply to?
A: This applies to all makers as listed above, especially all engineers and quality assurance staff, people who spend the majority of their time writing, designing or implementing software code, systems or designs. This also extends to those in management roles who’d like to use this time to do maker’s work. At this time, we are not applying this policy to employees with special employment contracts like guild or unionized employees.
Q: When will we have maker’s hours?
A: Fridays after 12 noon, i.e. the latter half of all Fridays going forward until further notice.
Q: Does this mean I can go home early on Fridays?
A: No. This is not a summer hours policy. This is meant to be uninterrupted software engineering and development time. It does not change anything about when you are expected to be in the office. The prior agreed upon schedules you have with the company will continue.
Q: Why Fridays and why only Friday afternoons?
A: We analyzed our organization’s current meetings schedule and found that Friday afternoon is the period where there are least meetings and those meetings can be rescheduled with least impact. We are starting the pilot program with Friday afternoons. After some months of evaluating the results, we may extend it, keep it the same or cancel it. Until Further notice, this policy applies only to Friday afternoons.
Q: Does this mean I only get Friday afternoons to write code?
A: No :-) What this means is that we must all do our best to not organize, nor attend meetings on Friday afternoons so that time is exclusively reserved for writing code, building systems and doing other maker’s work. You are expected to do maker’s work every business day and to manage your own schedule to block off enough time to do that on others day the same way you already do.
Q: What about production emergencies? Can I get called into an emergency meeting to deal with a critical production emergency?
A: Yes. Production emergencies qualify among the rare exceptions.
Q: What about meetings between makers? For example, between two software engineers.
A: That is a slippery slope. We are strongly discouraging meetings on Friday afternoons in this policy, but we are not the meeting police and are not going to ban all meetings, especially if all the attendees have a strong desire to meet. We trust you to use your best judgement and lean towards not holding meetings on Friday afternoons unless you determine you have a good reason to make an exception to this policy. Our suggestion is this: Pair programming is encouraged. Working sessions are ok, assuming that in the entire working session multiple makers are making something together. However having staff meetings at this time is not a good idea. Nor is it a good time to have your weekly 1-on-1 with your manager. Remember your manager is likely to be using this time to do their own maker’s work. So on the question of can developers hold a meeting with just developers at this time, ask yourself why. What is the meeting for? Is it a working session where each of you will make something together? If yes, that’s likely fine. If not, schedule it for another time.
Q: What should I do when someone invites me to a meeting on Friday afternoon and I plan to observe the maker’s schedule and write code at that time?
A: Please always be respectful, courteous and friendly while declining meetings. Use your discretion and common sense. If the meeting request comes from someone it may not be wise to decline, consult with your boss. In many cases, you can politely, respectfully and nicely point the meeting requester to this policy at http://www.rajiv.com/blog/2013/05/24/makers-schedule-for-managers-too/ and suggest or request another time. Letting your collaborators know about this policy in advance will also help.
Since processing email has become such an information overload problem, distraction and waste of time these days, we hesitate to classify doing email as productive maker’s work. If you don’t have the unproductive bad habit of checking your email every 15 minutes and instead you process your email during a few blocks of time a day, you may consider email productive work too. [↩]
This article presents a system to organize your digital technology department in a media company. It is written for a CTO, CIO or EVP Technology looking for suggestions on organizing or reorganizing your Digital (Web, Mobile) technology department. It is best suited for you if your organization has the following characteristics:
You manage all aspects of technology for a major digital brand or for a large company with 3 or more Web sites.
You lead a technology department of between 50 to 250 staff.
Internal corporate IT functions such as desktop support, telecommunications services and internal business systems are beyond the scope of this article.
The following are seven areas that the CTO heading up such a technology department in a media company is typically responsible for.
Digital Technology Department in a Media Company – By Functional Areas
Each of the seven areas contains the following functions.
In a company, the above may map to the following organizational structure.
CTO / EVP Technology’s Organization
Director of Technology Administration & Management (Chief of Staff to CTO)
VP of PMO
Director of Program & Project Management
Director of Technology Budgets (has dotted line of reporting into Finance department)
VP of Technology, Client Satisfaction & Advocacy
24×7 Support Staff
Director of Technology & Business Analysis
Technology Analysts team
Business Intelligence, Research & Analysis Team
VP of Quality
Teams of Testers
Team of Test Automation Engineers
Software Release & Shipping Team
VP of Product Engineering
Teams for each technology product
VP of Software Engineering
Director of DevOps (has dotted line of reporting into VP of Systems & Infrastructure)
Web Client Technologies Team
Mobile Technologies Team
Builds & Configuration Management Team
VP of Systems & Infrastructure
Security & Privacy Protection Team
Systems & Applications Administration Teams
Infrastructure Management Team
In the above organization, each person directly reports into their functional area. In a smaller organization, the VP roles above may be director roles.
Program/Project Teams: Dotted-Line Reporting By Programs & Projects
At any given time, a company has a number of programs and projects in progress that are best suited by a dedicated team. In this system, staff is assigned to the program or project. The assignment of a person to a project is a dotted line valid for the duration of the project, not a direct line of reporting to the head of the project.
The benefits of this approach include: By directly reporting to a manager, director or VP in their discipline, the employee benefits from the learning, coaching and exchange of knowledge with others in the same discipline. That gives the employee a good feeling of belonging with others that share a passion for that area of work. By being part of a program or project team, the employee enjoys the sense of co-ownership of a project or product.
During and on completion of the project, the project head gives feedback to the direct supervisor of the employee, which the supervisor uses to coach, help and provide support to the employee both in the current project and for future projects.
Below is an alternate illustration showing teams as “vertical” and “horizontal”.
There are many good ways to organize your technology department. This article presents some of them. It is written for a CTO or VP Technology leading a medium size department looking for suggestions on organizing or reorganizing your Digital (Web, Mobile) technology department. It is best suited for you if your organization has the following characteristics:
You manage software engineering, implementation and technology operations for 3 or more digital brands.
Yours is a medium size technology department with somewhere between 20 to 100 technology staff.
Internal corporate IT functions such as desktop support, telecommunications services and internal business systems are beyond the scope of this article.
The Venn diagram below presents one model of organizing your department into 3 sub-departments.
Some CTOs in smaller companies organize their technology departments as 2 sub-departments: Software Engineering and Technology Operations. Software engineering is the function that is responsible for developing and implementing Web & Mobile application software. Technology Operations is responsible for running, maintaining and supporting the Web applications.
If you operate 1 or 2 digital brands (Web sites), having these 2 sub-departments is a good approach. For 3 or more Web sites, organizing Software Engineering into Site Engineering and Platform Engineering has some benefits.
Site Engineering is focused on working on the Web sites’ direct projects. Its work includes
Small and large projects for adding or changing functionality on the Web sites
Bug fixes on the Web site applications
Platform Engineering is typically smaller than the other two organizations and typically includes functions like:
These three departments have purposeful overlap of responsibilities as illustrated in the Venn diagram above. That helps minimize the chances of the departments becoming silos with walls between them. For success, it is important that your entire department functions as one integrated unit. Some shared goals & responsibilities are required for mutual success.
DevOps2 is a set of processes, methods and systems for communication, collaboration and integration between departments for Development (Applications/Software Engineering) and Technology Operations. Its purpose is to facilitate meeting business goals by producing good quality software products and services in a timely fashion. It is where development methodologies (such as agile software development) occur in an organization with separate departments for Development, Technology Operations and Quality Assurance. Development and deployment activities that need deep cross-departmental integration with Technology Support or QA require intimate multi-departmental collaboration.3
To make this work, you need 3 directors who head up these departments who work well together, collaborate often and are not sensitive about their turf. They should know that a successful technology manager is not an individual-only contributor, but a great team player with peers. They should have strong goodwill among each other and welcome each other to work directly with their teams. Such a collaborative team is essential.
Article Updated: September 25, 2010
QA can also be set up as an independent department. [↩]
Described here is one way to enable technologists to grow their careers in your organization while still allowing them to focus on the type of work they are best at and enjoy most.
The typical management career growth path does not suit some technical people. These information workers need to grow in their careers (gain greater compensation, responsibilities and influence) without having to become managers of other people. A good way to achieve that goal is to create a technical career growth track in your organization.
The following diagram and table illustrate management positions alongside technical positions of similar levels.
This system isn’t meant to be rigid. It is designed to find a good balance with most organizations. That balance, i.e. how many “levels of authority” there are will differ across organizations. The focus of this article is to provide a technical track as an alternative to management tracks, whether there are 3 levels or 13. There are pros and cons of having fewer “bands” or ranks. (As a side note, some organizations like the military1 require lots of ranks.) Ranks need not signify a strict hierarchy where one can only go from one rank to the one immediately above. The ranks could simply be used as “salary bands” and the levels of “hierarchy of authority” could be fewer.
In this model, for example, an architect role is at the same compensation and influence level as a manager role, assuming that the particular manager and architect being compared add similar value to the company. To accommodate more ranks, a senior architect would be at the same level as a senior manager.
If the organization prefers consistent titles for levels regardless of track, the system could name them like this: vice president & fellow, senior director & architect, etc. In the case of a fellow who is at an SVP level, they could be named SVP & distinguished fellow.
Here is a definition of the fellow role from WikiPedia:2
Large corporations in research and development-intensive industries3 appoint a small number of senior scientists and engineers as Fellows. Fellow is the most senior rank or title one can achieve on a technical career, though some fellows also hold business titles such as vice president or chief technology officer.
Such a technical career growth plan brings many benefits to your organization.
It helps retain good technologists who want to grow in their careers, but want to do keep doing the type of work they are best at and enjoy doing: technical work.
It avoids brilliant technical people from being “pushed” (by themselves or their supervisors trying to “reward” them) into people-management responsibilities.
It reduces situations of having too many people-managers but not enough people-management positions over time as people get promoted.
Care should be taken to recognize that some technical people do enjoy making the transition to people-management roles and the presence such a technical track should not discourage them. Having an alternate career growth track option is about presenting employees with more than one choice.
Similar system are also used to enable non-managerial career paths at editorial and design departments at newspapers, magazines and other newsrooms.
I look forward to living in Atlanta, a major city in the southeastern state of Georgia. I will, however, miss being around my friends in the the Philadelphia and San Francisco areas where I previously lived.
On June 1st, I start work at COXnet as Chief Technology Officer. COXnet is part of the Cox Newspapers Division of Cox, one of the nation’s leading media/communications companies and providers of automotive services. I’m excited!
Effectuation (my business venture) has been handed over to new management. I wish them the best.