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.

90 Day Plan for a CTO in a New Job

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.

  1. Make a list of the areas you are responsible for. These are likely to include:
    1. Technology: Software Engineering, Infrastructure Engineering, DevOps, Cyber Security, Systems Operations, Application Support
    2. Product: Product Management, Project Management, User Experience, User Interface Design
    3. Data: Data Science, Data Engineering, Data Visualization
  2. Review what it takes to be an effective Chief Technology & Product Officer.
  3. Create a mind map of culture, technology, and operations parts of your CTO job.
  4. Meet customers, executives, stakeholders, colleagues, and team members.
  5. Connect with a network of your peers outside your organization.
  6. Get feedback.
  7. Collect, compile, and synthesize information into knowledge.
  8. Check: How are we doing in relation to our existing metrics for success?
  9. Identify common themes, patterns, and problems.
  10. Consider retaining the services of an executive coach.

2. Define and revise measurements for success.

  1. List metrics for the success of the company as viewed by shareholders.
  2. Prioritize metrics for the success of the teams you manage and how they relate to the metrics for the success of the whole organization.
  3. Determine: What metrics are no longer a priority?
  4. Determine: What new metrics do we need to add?

3. Articulate your vision and strategy.

  1. Clearly communicate it to customers, executives, stakeholders, colleagues, and team members. On a regular basis.
  2. Meet regularly with your team members, peers, executives, stakeholders, customers, partners, and vendors. Human relationships and face to face communications (when feasible) are essential.
  3. Host regular 1:1 meetings with your direct reports, at least once a week. team members
  4. 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.
  5. 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.
  6. Implement processes to have productive business meetings.

4. Organize people for success.

  1. Reorganize teams and redeploy people.
    1. Ensure that your organizational structure factors in products, stakeholders, and career growth needs of your team members.
    2. Here is an example of a technology team organization for media companies.
  2. Reinvigorate people.
    1. Implement managerial and technical career tracks.
    2. Standardize titles while still retaining flexibility, and fun.
    3. Consider that career pathways are not linear.
  3. Recruit talent.
    1. When feasible, interview people by putting them to work.

5. Build culture.

  1. Align team members towards common good, shared goals.
  2. Ask team members how they are doing. Are they happy in their jobs? Are their jobs exciting, challenging, and rewarding?
  3. 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.
  4. Remember to thank people when they deserve it.
  5. Implement a performance evaluation and career development system.
  6. Build and maintain a cohesive leadership team. Make it well known that internal rivalries are strongly discouraged and not tolerated.
  7. Encourage good life/work balance, including a sensible vacation policy.
  8. Experiment with ideas to keep the workplace interesting.

6. Revise processes for success & delivery, and suitable for the environment and the times.

  1. Create checklists to help you do your job better (like this one itself). These checklists will also help your colleagues. Encourage others to collaborate on checklists and share them.
    1. Here is a sample one I made about reviewing managed services contracts
    2. and another one for dealing with outages.
  2. Encourage a culture of sharing best practices, like simple personal productivity tips.
  3. Design evaluation scorecards and criteria to justify, prioritize, and classify projects.
  4. Ensure that your project portfolio management system and your people role definitions factor in the need to regularly evaluate and decommission projects and products that don’t make sense to continue.

7. Upgrade technologies.

  1. Pay off technical debt [external link]and continue performance enhancements.
    1. App, site, and service reliability
    2. Automation (QA, deployments, support, etc.)
    3. Performance
    4. Security (e.g. start down the path to HTTPS)
  2. Make each team increasingly autonomous and self-sufficient while enabling collaboration and economies of scale.
    1. 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.

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

 

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.  []

3 Roles of a CTO: Culture. Technology. Operations.

This is a guide for CTOs, VPs of Software Engineering and other technology managers responsible for a software engineering organization. The purpose of this checklist is to help the CTO cover the areas of culture, technology and operations in their teams. It is presented in the form of a memo to direct reports.

cto-culture-technology-operations


Dear Tech Management Team Colleagues,

For those of you who have weekly 1:1 meetings with me, this template is a guide for our regular discussions. I value your experience, so please feel free to suggest making this format even better. I’d like us to cover three major areas on a regular basis.

  1. Culture
  2. Technology
  3. Operations

Each of these three major areas is further divided into three sub-categories containing a list of items to consider reviewing.

The first time you see this list, it may seem too long to review in a 30 minute meeting. This is a guideline to structure our conversations. You are not expected to discuss each one of these at every meeting. This checklist will help us review things that are relevant at the time. Managers have successfully used this checklist to review pertinent items in less than 30 minutes.

Tip: Here is one way to effectively use this. Let us both spend 5 to 10 minutes to read this checklist in advance of each of our regular 1:1 meetings. We can even use the first 5 minutes of our meeting to read it. Then we will both have a good idea of which items are relevant for the next discussion from our perspectives.

Culture “people, behaviors & teamwork”

Relationships

  1. How well are your team members collaborating with each other?
  2. …with their colleagues in other tech teams?
  3. …with their stakeholders, customers and executives?
  4. Are there any tensions that I need to be aware of?
  5. Advocacy: What should we do to be better understood, respected, and appreciated by our stakeholders, customers and executives and vice versa?
  6. Anything in this area that you are waiting on or need from me?
  7. Is there anything non-work-related that you’d like to share?

Retention

  1. Are the people in your teams happy with their work? How is team morale?
  2. Is the work intellectually challenging?
  3. Are they learning new things and getting better at existing skills?
  4. Do they feel they are making a positive impact?
  5. Are we taking good care of them?
  6. Are we proactively providing feedback, coaching, and training?
  7. Is anyone considering leaving that you know of?
  8. Has anyone given notice?
  9. Is there anything related to retention that you are waiting on or need from me?

Recruiting

  1. Are you feeling a staffing shortage this week?
  2. Are we thinking ahead and planning for capacity, skills and having some slack for flexibility?
  3. How many open positions do you have in your team this week? How long have they been open?
  4. What are you doing for recruiting?
  5. Is there anything related to recruiting that you are waiting on or need from me?

Technology “engineering, infrastructure & innovation”

Architecture

  1. What new technologies, platforms, products and APIs are we evaluating?
  2. …implementing?
  3. …decommissioning?
  4. …consolidating?
  5. …releasing as open source or making public?

Integration

  1. What are we doing to support integrations across teams?
  2. Are you facing any challenges integrations across teams?

DevOps

  1. In what areas are we implementing temporary hacks?
  2. How are your apps and platforms doing with respect to their goals in Performance & Scalability?
  3. …Reliability?
  4. …Security?
  5. …Test Coverage?
  6. …Technical Debt?
  7. …On calls and P1s?
  8. How are the integrations, process and relationships between the development, infrastructure and security folks?

Operations “projects, sustainability & recycling”

Work

  1. Are there any projects at risk?
  2. Are there any changes to a) due dates, and/or b) delivery dates?
  3. What did we a) accomplish, and b) work on over the past week?
  4. What do we plan to do over the next week?
  5. What projects/work can we decommission?
  6. What was your budget forecast? How are we doing with respect to it? Any budget issues?
  7. Did we recently say “no” to a stakeholder or executive’s project request (or say something would be very hard to do) that I should know about?
  8. … any that we said “yes” to that I should know about? :-)
  9. Did we give any estimates that I should know about?
  10. What can I do to help? What do you need from me?

Learn

  1. What did we learn from the past week?
  2. Are we sharing these learnings with others who’d benefit from them?
  3. Did we do any retrospectives? What changes are we making based on retrospectives?
  4. Are there any process changes that you recommend? … for both outside and inside of your teams.
  5. How can I help?

Challenges

  1. What issues are we facing now or are likely to face in the future?
  2. What prioritization problems are we facing?
  3. What do you suggest are our countermeasures to address those issues?
  4. How can I and/or others help and support you or remove obstacles from your path?

Mixing it up

To prevent our weekly discussions from feeling too structured and getting stale, I suggest mixing it up a bit. Let us try this format for 3 out of every 4 of our regular 1:1s and keep 1 meeting free-form.

We can also break monotony by switching the locations of these meetings and having some of these discussions walking about.

Why discuss this in a meeting and not ask for this information in a weekly status report?

… because no one likes to write a status report, but everyone likes to talk :-)

Let us take a test and learn approach with this and adjust as we go along.

Thank you in advance for your help with this.


This article is mirrored at LinkedIn and Medium.

3-5-7 Meeting Format for Weekly Staff Meetings

If you are the manager of a team of people at your job, here is a format we suggest for running your staff meetings. We call it the 3-5-7 format because of its convention of giving 3 to 5 minutes per person to answer 7 questions. This system assumes that you have fewer than ten direct reports so that you can complete such a staff meeting in under one hour.

The purpose of a staff meeting need not be to get status reports. If you have excellent collaboration tools at work where statuses, issues and risks are already documented, that’s preferable. Some companies like Automattic (WordPress) make great use of internal blogs for communication. However, face-to-face meetings are continue to be useful because our brains have evolved being wired for being most effective in face-to-face conversations for several things.

An in-person (or via video conference) discussion structured around these questions is likely to be effective in finding solutions, building a more collaborative team and keeping everyone on the same page.

Here are the seven questions we suggest you request each attendee to come prepared to answer.

  1. What did we (you and the team reporting in to you) do over the past week?
  2. What did you learn over the past week?
  3. What do we (you and the team reporting in to you) plan to do over the next week?
  4. What issues are we (you and the team reporting in to you) facing now or are likely to face in the future?
  5. What do you suggest are our countermeasures to address those issues?
  6. What do you need help with from the rest of us in this meeting?
  7. Is there anything non-work-related that you’d like to share?

Each person may answer the seven questions the order of their choice and may also combine the answers to multiple questions. The only requirement is that all seven areas be answered in a focused, efficient, and effective narrative lasting between three to five minutes.

Some of this advice is based on management experiences shared by Don Kiefer in an operations management class he teaches at MIT’s Sloan School of Business.

Posted Signs for Productive Meetings

You can post these slides as signs in your meeting rooms and offices or include them at the start of your presentations. Click on the image below to view the slides.

Posted Signs for Productive Meetings