Management & Technical Career Growth Tracks (v3)

In follow-up to earlier work on a) versions one and two of these technical and related career tracks, b) pathways for career development in product engineering, c) job titles, and d)  employee evaluation & career development, here is an updated version three of the career growth tracks.

This version 3 includes software engineering & architecture, quality assurance & test engineering, data science & engineering, infrastructure & systems engineering, product & product management, and design & user experience. This version moves “chief” and “head of” type titles to the discretionary column, keeping only four main levels (contributor, manager, director, and vice president) with three sub-levels designating seniority within each.

This is presented in a Google Sheet embedded below with tabs containing areas like engineering and product. I’m also providing a direct link to to the Google Sheet you can copy and edit for use in your own organization.


As always, I’d love your feedback. Thank you.

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 content, 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.

A Key Difference Between a Product and a Project

A project has preset start and end dates. A project, by definition, is supposed to be complete when it delivers its desired outcomes.

A product typically does not have a preset end-date. Most products are meant to exist and evolve for the foreseeable future. Products are (and should be) discontinued for good reasons (e.g. when they no longer have a viable future, or the organization needs to divert resources to other products).

Upgraded versions of the product are delivered via projects.

Projects are successful when they end.
Products are successful when they persevere.

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.

HR Classification and Discretionary/Business Job Titles for Makers, Managers and Leaders in Technology

This article presents an organization system and policy for job titles of makermanager and leader roles in technology staffs.

Separate job titles for HR classification and discretionary/business use are used at many technology organizations, ranging from medium-sized, innovative and fast-moving companies to large, established and enterprise technology companies.1 This is a well-established practice that balances HR requirements with the rapid pace of innovation and change in job functions. They each serve a different purpose: HR classification titles are designed for use by information systems and discretionary/business titles are designed for use by humans.

HR Classification Job Titles are meant to be comparable in the entire organization (across different departments) and sometimes even comparable with other organizations. The purpose of these is to maintain standardization across the organization for HR purposes such as payroll, benefits and eligibility for things. The number of HR classification titles at each role level should be finite and small. They do not change unless there is a major change in the person’s job like a promotion or new functional role. They map to the employee’s internal level, status and eligibility for things in the company. They follow a standardized naming convention for logical classification.

Discretionary/Business Job Titles, on the other hand, are used to describe the job (or a key part of the job) in easy to understand language. A person’s discretionary/business title can change, if desired, with smaller changes in the role compared to what warrants a HR classification title change. These titles are named in human-friendly language (and do not need to be worded for logical classification like HR classification titles). Discretionary/business titles are usually the ones employees put on their email signatures, business cards, online forums and social media sites. The number of discretionary job titles at a job level is limited only by the requesters’ imagination.

Below are some examples of HR classification titles along with examples of some corresponding discretionary/business titles. Employees may propose their discretionary/business titles to their supervisors. Most of the titles below are for technology staff, but some non-technology titles are included for comparison.

HR Classification Job Titles Examples of Corresponding Discretionary/BUSINESS Job Titles
  • Engineer
  • Senior Engineer
(Software)
  • iOS Software Developer
  • Software Engineer, Mobile Applications, Android
  • User Experience Engineer
  • Release Engineer
  • Product Engineer
  • Software Development Engineer in Test
  • Test Automation Engineer
  • Web Developer
  • Mobile Apps Developer
  • JavaScript Programmer
  • Code Ninja2
  • Software Artisan
  • Developer Advocate3
  • Video Software Developer

These are software engineers, also known as computer programmers and software developers. The key job requirement is that they write software code.

When appropriate, the prefix “Senior” may be applied to these titles except where noted.

  • Engineer
  • Senior Engineer
(Systems)
  • Systems Engineer
  • Systems Administrator
  • Unix Systems Engineer
  • Infrastructure Engineer
  • Network Engineer
  • Security Engineer
  • Windows Systems Administrator
  • Unix Guru4
  • Video Systems Engineer
  • Robotics Engineer
  • Hardware Engineer
  • Web & App Servers Administrator
  • Database Engineer
  • Database Administrator
  • Sysadmin
  • Email Administrator
These are systems, networks and other engineers. They implement, maintain and upgrade systems. While they are not required to write as much code as software engineers, they are likely to do some scripting to assist in their jobs.
When appropriate, the prefix “Senior” may be applied to these titles except where noted.
  • Analyst
  • Senior Analyst
  • Technical Analyst
  • Quality Assurance Analyst
  • Quality Assurance Tester5
  • Business Analyst
  • Product Analyst
  • Functional Analyst
  • Financial Analyst
  • Business Intelligence Analyst
  • Technology Support Analyst

Analysts are generally not required to write code, but some may.

When appropriate, the prefix “Senior” may be applied to these titles except where noted.

  • Designer
  • Senior Designer
  • Graphics Designer
  • Photo Designer
  • Art Illustrator
  • Graphics Artist
  • Visual Designer

When appropriate, the prefix “Senior” may be applied to these titles except where noted.

  • Manager
  • Senior Manager
  • Technology Manager
  • Engineering Manager
  • Software Development Manager
  • Manager of Quality Assurance for Mobile Apps
  • Manager of Engineering for Product X
  • Staff Software Engineer6
  • Lead Software Engineer7
  • Software Architect
  • Applications Architect
  • Systems Architect
  • Program Manager
When appropriate, the prefix “Senior” may be applied to these titles except where noted.
  • Director
  • Senior Director
  • Technology Director
  • Video Technology Director
  • Director of Engineering for Food & Dining Products
  • Director of Content Management Systems
  • Director of Quality for Products XY & Z
  • Distinguished Software Engineer8
  • Program Director
  • Director of Project Management
  • Director of Products XY & Z
When appropriate, the prefix “Senior” may be applied to these titles except where noted.
  • Vice President
  • Senior Vice President
  • Executive Vice President
  • President
  • CEO
  • Chairperson
  • Board Member
  • Chief Technology Officer
  • Chief Information Officer
  • Chief Scientist
  • Fellow
  • Chief Operating Officer
  • Chief Financial Officer
(any title)
  • Founder
  • Co-Founder
  • Emeritus

Often used in combination with other words, these can be used in a discretionary/business title, but obviously, only if they are true.

Discretionary Titles are official, significant and used inside and outside the organization. Therefore, like HR Classification Titles, they also need to be approved in advance.

Policy and Guidelines for Discretionary/Business Titles

  1. Assignment of discretionary/business titles (and changes to them) must be approved in advance by the same people who approve assignment of HR classification titles. Once assigned, it must be documented in the HR information system.
    • Typically this requires two people: 1. the immediate supervisor of the employee, and 2. an HR representative to comply with these guidelines. In case of doubt, dispute or disagreement it should go to a department head, staffing committee or similar body for confirmation.
    • The benefit of this process is the employee will feel good in knowing that the discretionary title is official, recognized and endorsed by the company.
  2. Please refer to the examples above see what types of discretionary/business titles are likely to be acceptable.
  3. Inappropriate, offensive or harmful language is disallowed. (E.g. “Code Nazi” and “Architect of Terror” are not ok.)
  4. It must not reflect poorly on the organization. (E.g. “Underutilized Engineer” and “Dissatisfied Manager” are not ok.)
  5. It must not make unauthorized use of trademarks, copyrighted material or anything else that is likely to run afoul of the law, policies or best practices. (E.g. “Facebook API Engineer” is not ok unless you work at Facebook.)
  6. It must reasonably relate to or represent the job, at least partly. It can’t be completely meaningless to the job. (“E.g. “Ninja” is likely not ok, but “Code Ninja” is likely to be ok, provided it is not someone else’s trademark.)
  7. The title must not exaggerate the scope, authority (decision making or staff), or level of influence of the role. (E.g. you must not call yourself just “Head of Software Development” unless you are the one and only head of all software development.)
  8. When the employee and their supervisor do not see the need for separate HR classification and discretionary/business titles, they can be the same. (E.g. Software Engineer).
  9. When required, sensible and appropriate, the discretionary and HR classification titles may be written together in combined form. (For example, on a resume or biography, the employee can write “Director & Distinguished Software Engineer”, “Staff Software Engineer (Manager-level position)”, “Vice President & Fellow”, etc.)
  10. When in doubt, consult with your department head or HR representative.
  1. For example, discretionary/business titles are used at Oracle. []
  2. Fun titles may be acceptable as long as they match the role []
  3. Assuming that the developer advocate needs to also be a software engineer []
  4. Another example of a fun title that matches the role []
  5. For testers who are not software development engineers. Those who are would have an HR classification title of software engineer []
  6. Staff Software Engineer is a people-manager level maker role. It is equivalent to an architect level, but unlike an architect who often reviews others’ code, a staff software engineer is generally an individual contributor. []
  7. Equivalent to Staff Software Engineer []
  8. The word distinguished is reserved for software engineers who are contributing value at the people-director level. At the VP level, the distinguished engineer becomes a Fellow. The bar for earning this title is exceptionally high and requires extraordinary achievements. E.g. inventing a programming language or software framework used by hundreds of people in multiple companies. Distinguished Engineers are typically well respected outside the organization. Prefixes such as Senior cannot be applied to the title Distinguished Engineer. []

Case for a Consistent, Comprehensible & Cost-Effective Vacation Policy

This article makes a case for having a vacation policy that is simple, sane and standard across the organization.

Some organizations have unnecessarily complicated vacation policies that require a lot of labor and time to implement, manage and support exceptions for. That is substandard because such vacation policies are costly for the organization, they distract from the organization’s other work and they make some employees feel unfairly treated.

Most companies would be better off with a simple vacation policy for all full-time employees.1 Here is a such a vacation policy. It can be described in one sentence as:

Every full-time employee gets 25 days (5 weeks) of paid time off per calendar year.

Detailed explanation and justification

To some managers in the United States, it may initially seem that 5 weeks is too much for entry level employees or workers at the early stages of their careers. 25 days is not too much, especially considering that these also include paid personal days off. Many organizations already give employees about 5 personal paid days off (in addition to their vacation days) to use for personal/family/religious/social events, the day before/after major holiday etc.

An example

So you could think of this policy as: Every FTE in the organization gets 20 days (4 weeks) of paid “regular” vacation, plus 5 more paid personal days off per each calendar year.

Here is one way the 5 weeks could be scheduled: 4 four weeks set aside for “regular” vacation would be meant to be used for typical vacations. As long as it is ok with the employee’s supervisor, it could be one 4-week long trip to another country, two 2-week long vacations, or even 20 separate Fridays taken off during a calendar year.

The 5 remaining days could be set aside as “personal days” would be meant to be used for other purposes like birthdays, anniversaries, personal/family/religious/social events, needing a day off at the last moment to run errands, take off the day before/after a company holiday.

This system actually makes no distinction between regular vacation and personal days off. The above is simply an example of how an employee (in consultation with their supervisor) decide to use the 25 vacation days.

Fair, consistent, and simple

Every FTE from the CEO to an entry-level engineer gets the same number of paid days off.

Vacation time is a necessary downtime for employees to relax, recharge and refresh. It should not be viewed as a perk. By giving senior-level executives more vacation days and making vacation seem like compensation sends the wrong message at multiple levels: Is the organization implying that senior-level people put in less time and effort? Is it implying that being away from work more is a valuable and desirable thing that employees should strive for?

Senior executives and entry-level employees alike get a two-day weekend. They get the same number of company holidays. They have the same sick-day policies. They should also have the same number of vacation days per year.

All prospective employees are informed of this consistent policy: 5 weeks vacation for all full-time employees, regardless of role, level and compensation. This eliminates distracting negotiations during the hiring process about vacation days. After which, existing employees can feel demoralized learning that some of their peers have more vacation days for no fair reason. Unlike compensation, vacation time is not private information. In a team that works closely together, people can often observe how much vacation their colleagues are taking if they choose to.

Speaking of sick-days, a detailed discussion of that is currently beyond the scope of this article and likely the subject of an article about employee health policy. Sick days should be separate from vacation.

Accrual, carry over, and Trading

Vacation days are not collectors items. Also, they do not have any cash value as per this policy. Employees should be encouraged to use all of their vacation days each calendar year. Taking vacation is good for the employees. It increases morale, productivity and innovation.2 So it is good for the company. Vacation days may not be carried over from one calendar year to the next, nor can they be transferred to other employees. They can definitely not be redeemed for cash.

In this system, vacation days do not accrue incrementally over the year, so employees can’t redeem any unused ones for money even if they leave the organization. You could think of it this way: They accrue all together at the end of the year. When an employee leaves the company, they are not expected to pay the company back for their vacation days used either.

As for when a new employee (or any employee) can take vacation, that should be discussed between the employee and their supervisor and needs to be signed off by the supervisor. Use trust and common sense. In almost all cases, it would not make sense to take a month-long vacation after just one day at the job.

As for the first calendar year of new employee’s joining, we can apply the following simple formula: The number of vacation days you get in your first calendar year is adjusted based on the number of weeks remaining in that year, using whole numbers rounded up. For example, if you join in the middle of the year with 26 weeks remaining (half the total number of weeks in the year), you get 13 days of vacation that first calendar year (half of 25 days, rounded up).

“Unlimited” vacation policies

These days, a few companies offer open-ended “unlimited” vacation policies, where there is no pre-set limit to the number of vacation days an employee can take, within reason.3 Realistically, these are not unlimited vacation policies, the same way credit cards with no pre-set spending limit don’t allow unlimited spending.

The data on these open-ended vacation policies is not yet conclusive, but initial data indicates that they have a number of potential drawbacks:

  1. They have been shown to result in employees taking less vacation time4
  2. They pressure employees to keep working during their “vacations”, which defeats the purpose and benefits of vacations.
  3. They put employees in uncomfortable situations with their employers. For example, when an employee gives 4-weeks notice to leave and wants to use the last one or two weeks for vacation. In such a situation, the employer is likely to feel taken advantage of under an “unlimited” vacation policy.

For these reasons, I recommend this 25 vacation days per calendar year policy over so called “unlimited”  policies.

Benefits

A clear, consistent and complete vacation policy like this is likely to lower administrative costs, make employees happier and increase productivity. It is also likely to make the company more attractive to potential hires and improve retention.

  1. By full-time employee (FTE), I am referring to a person directly employed by the organization who is expected to work ~40 hour/week, typically on a Monday through Friday schedule. []
  2. The Case for Vacation: Why Science Says Breaks Are Good for Productivity: article in The Atlantic  []
  3. IBM’s un-vacation policy: All you need, all the time: article in The New York Times  []
  4. Companies Offer “Unlimited” Vacation Time Because They Know Perfectly Well People Won’t Use It (Slate)
    How One Company’s Unlimited Vacation Policy Totally Backfired (Inc.) []

Product Maintenance vs. New Development on Web Sites, Mobile Apps and Other Digital Products

maintenance

Maintenance of a digital business product (e.g. a Web site, mobile app, or software) refers to the work that includes modifications made after delivery to production to fix bugs, address compliance/security issues, or improve scalability/performance These modifications can be to the product’s software code, configuration, documentation, hardware, or surrounding network.

Maintenance is often contrasted with the development of new features and functionality to enhance or increase the capabilities of the product.

The distinction between maintenance vs. new feature development comes up in both internal and external contexts. In the external context, it pertains to a maintenance contract with an outside vendor. A vendor is likely to define maintenance in strict and narrow terms to minimize costs the vendor has to incur. In the internal context it is helpful in analyzing staffing and resourcing capacity of an organization which is needed to understand the bandwidth available to work on new initiatives.

The purpose of this article is to help answer questions such as: What do you mean by maintenance work? What should we consider maintenance vs. new feature development? Is there an industry standard definition? What’s our selection criteria? Can you give some examples? Other questions that often accompany these are: What ratio of maintenance vs. new features development work is considered best practice for our industry? How does our organization’s situation compare with that? These latter two questions require analysis specific to your organization and a set of reference organizations to answer.

The following illustrates some typical attributes of maintenance vs. new features.

Maintenance

New Features

Consequences of not doing Often maintenance work is not optional, i.e. the consequences of not doing maintenance range from the gradual decline of the product to complete breakdown of the product. Not doing maintenance often causes legal, security and other compliance issues. Implementation of new features, functionality and services is often optional. The negative consequences of not implementing new features typically include loss of competitive advantages, loss of market share, and decrease of relevance.
Financial impact The financial value of an asset decreases in the absence of maintenance. Maintenance work helps maintain the value of the product, but typically does not substantially increase it. New features and functionality increase the financial value of an asset.

Types of Maintenance Done on Web Sites and Mobile Apps

Learning from the The International Standards Organization and International Electrotechnical Commission’s ISO/IEC 14764 specification, we define maintenance of a digital business product such as a Web site or mobile application into the following four categories:

  • Corrective maintenance: Reactive modification of the software, configuration or infrastructure powering a Web site or mobile app performed after delivery to correct discovered problems. E.g.
    • Bug fixes
    • Fixing design compatibility (HTML/JavaScript/CSS) issues with Web browsers that have been around for a while.
    • Install security patches to address existing security/privacy holes.
  • Adaptive maintenance: Modification of a software product performed after delivery to keep a software product usable in a changed or changing environment. E.g.:
    • Modifying a Web site to work with an newly emerging Web browser like a recently released version of Google Chrome.
    • Modifying a mobile app to comply with changes made by third parties, e.g. new terms of service from Facebook or Twitter, a new API released by Google+.
    • Increase capacity to handle increasing traffic on a Web site.
  • Perfective maintenance: Modification of a software product after delivery to improve performance or maintainability. E.g.:
    • Changes to servers or network to make the Web site serve quicker.
    • Refactoring the software code to make it less expensive to maintain and modify.
  • Preventive maintenance: Modification of a software product after delivery to detect and correct latent faults in the software product before they become effective faults. E.g.:
    • Y2K :-) fixes made on or before December 1999. Remember that? When we had to install patches and test software on the Web sites in the 90s.

The following are some examples of maintenance work contrasted with new features development.

Maintenance

New Features

Fixing bugs in existing software. Developing new Web applications or mobile apps. Adding major new features and functionality to existing apps.
Modifying software code on a Web application to comply with changes to Facebook’s application programming interface (API). Adding new software code to add support in a Web application for a new social network, e.g. Google+.
Rewriting parts of a Web application to handle increased usage (E.g. more users, users storing more data, growing traffic.) Developing a complete new Web application to replace an existing application to address the shortcomings the previous one has.
Routine work like generating, analyzing and publishing periodic reports. Designing, developing and automating a new report that has not existed before in the organization. Adding significant and major new features to an existing report.

In certain cases, the distinction between maintenance and new development can be blurry. For example, when rewriting (rebuilding) major parts of an application to overcome its shortcomings, at what point do we consider it a replacement (new development)? In such cases, it may be subjective based on how the output of the work is classified, branded and marketed. If it is being announced, launched and sold as a great new product to replace the old, it would be new development. This can cause issues when a customer has a maintenance contract with a vendor and doesn’t want to pay for the new version that doesn’t add substantial new functionality. That, however like all contracts, becomes matter of trust, relationships and reputation.

In the cases where an external vendor has a maintenance contract with a customer, the vendor is likely to not classify certain maintenance activities as maintenance since doing so would incur significant and unexpected costs the vendor would become responsible for. For example, a vendor may not include many adaptive types of maintenance in the contract. A vendor may want to charge the client more to handle increased usage.

Ratio of Maintenance vs. New Development

There is no “magic number” answer to this question. Ratios like 80/20, 70/30, 60/40 or 50/50 are specific to an organization in a specific phase. In today’s dynamic and hyper-competitive environment, seeking a best practice ratio for an industry may be misleading. A company or project in the startup phase typically has a lot more new development than maintenance happening than a organization with a mature product. Even within a particular company, the ratio changes as new projects start, are worked on and are completed. Decommissioning obsolete products also lowers the maintenance.

Related observations

Going down to maintenance mode for specific products does make good sense in certain circumstances. For example, when you are working on a major new version of the Web site or product, you can put the current (soon to be replaced) version in maintenance mode.

Sometimes, in times of financial hardship, companies try to hunker down to maintenance mode where they shed the new development work and do only the work required to “keep the lights on” to ride out the storm. This type of horizontal cutting of all products may initially seem like a good approach but in most cases, it is not a wise practice. In most circumstances of financial hardship, it is often wiser to cut products vertically. In other words, focus on doing a fewer number of products well rather than keep doing the same number of products poorly. Stopping new development and product innovation enables existing competitors to gain a huge lead over you. It creates opportunities for new competitors to your business and leads to the decline of your brand.

My article titled Trinity Method of Technology Management makes a case for decommissioning products the way Google does seasonal cleaning by ending products that no longer suit the company’s revised strategy.

References

 

Management & Technical Career Growth Tracks (v2)

This second version of the diagram illustrating technical career tracks reflects the following updates since version one:

  • A product management track is now included. (Future updates may include other tracks like design, editorial and marketing.)
  • There is no longer a contributor-level position on the people-management track. This is because most organizations do not have an entry-level position whose main job is to manage people yet is below the manager level.
  • The number of levels is still 5, but we have merged the two contributor levels below manager into one. We have added the C-level (as in CEO, CTO, CFO, …) band above the VP levels.
  • The director-level position in the technology track is now called principal architect or simply principal.
  • In the people management track, we suggest that a manager directly supervise at least 3 contributors and that a director supervise at least 3 managers. Exceptions can be made to this guideline when it is well-justified, but these are suggested as the default requirement to hold these titles.

(Thanks to Brian Murphy and Brad Kagawa for their contributions to this system.)

Organizing a Digital Technology Department in a Media Company By Functional Areas

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.
Click on the diagram above to view it as a zooming presentation

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)
    • Administrative Staff
  • VP of PMO
    • Director of Program & Project Management
      • Project Managers
    • Director of Technology Budgets (has dotted line of reporting into Finance department)
  • VP of Technology, Client Satisfaction & Advocacy
    • 24×7 Support Staff
    • Technology/Developer Advocate(s)
  • 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)
    • R&D Team
    • SEO Team
    • Web Client Technologies Team
    • Mobile Technologies Team
    • Builds & Configuration Management Team
  • VP of Systems & Infrastructure
    • Security & Privacy Protection Team
    • Systems & Applications Administration Teams
    • DBA Team
    • 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.

An example of this is a Scrum team.1

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

vertical-and-horizontal-teams

  1.  More articles related to Scrum teams. []

Organizing a Digital Technology Department of Medium Size in a Media Company

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.

Web Technology Department Organization
Web Technology Department Organization Venn Diagram Illustrating Purposeful Overlap Among 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:

  • Architecture across sites
  • Shared applications across sites
  • Common libraries across sites
  • Research & Development (R&D)

Technology Operations includes functions such as:

  • Systems & Applications Administration
  • Infrastructure Management
  • 24×7 Tech Support
  • Builds & Configuration
  • Release Management
  • Testing & Quality Assurance (QA)1
  • Technical Analysis
  • Technical Project Management
  • Budget Management

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

DevOps
llustration showing DevOps as the intersection of Development (Software Engineering), Technology Operations and Quality Assurance (QA)

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

  1. QA can also be set up as an independent department. []
  2. WikiPedia entry on DevOps []
  3. Article: What is DevOps? []