Constituting an Engineering Process

Engineering managers are responsible for a team of typically highly paid software engineers in a domain with nebulous aspects of technology and people. There has been a variety of books that advise a new EM on what to do in the first three months (most notably The First 90 Days), but by and large, different companies have different priorities and different teams have different missions so EMs need to quickly discover, adapt, and concretize a set of processes for the team to succeed.

“Process” is oftentimes a dirty word in the business world. People think of the TPS report from the movie Office Space, which depicts a Kafka-esque company culture where employees follow completely obscure and non-productivity-related processes. As a result, leaders often feel morally complicit when creating a process.

However, “process” is simply a set of expected behaviors that adhere to a standard, like the constitution of a nation. It embodies the mission of the team. When a manager starts on a team or when a new team is formed, it is imperative to solidify a process to optimize the team’s productivity.

“We are what we repeatedly do. Excellence, then, is not an act, but a habit.”

— Will Durant

👋

A manager needs to tailor an appropriate process based on the team’s needs and have it written down as soon as possible. At the outset, she needs to discern external and internal processes. They typically consist of some similar cadences — incident review, design review, architecture review, and tech talks. Internally, there is an operational process and a project-related process.

Incident reviews are for understanding defects and sharing best practices. Architecture reviews are for debating cross-impacting decisions. Design reviews are for the critique of project implementations. Tech talks are for skill-sharing and showcasing new techniques. The project process (could be either waterfall, agile, scrum, etc) is for project execution. The ops process is for post-project maintenance and bug-fixing.

With so many choices and finite engineering time, how could a manager constitute them to optimize the team performance without hitting a diminishing return?

💪

The process should be constituted in two parts:

1. defining the process cadence
2. deciding who should attend what

Defining the process cadence

Generally, a team has 3 concerns hence the process should spell out how to cover them:

A. projects: build-up of new product features
B. operations: maintenance of released products
C. engineering excellence: improvement of product domains

Depending on the project methodology (be it waterfall, agile, scrum, etc), the project cadence should consist of grooming, planning, and review components. The point is to ensure that the team is looking ahead, making commitments, and delivering on the said commitments.

Operationally, no project is released without bugs, and the team should periodically review the bugs, the fixes, and whether the fixes are done promptly. This includes internal and external incident reviews and on-call reviews.

Eng excellence consists of monitoring and improving. The former should be a collection of observable data from all product domains. The latter should be a discussion of investments for elevating the reliability of the underlying platform.

Engineering managers should outline what topics should be discussed in each cadence and widely share them on, for example, a team wiki — a team’s process should be a living document. Fault on the detail rather than the absence or the ambiguity thereof. Reflect, collect feedback, and finetune iteratively as needed.

Deciding who should attend what

Determine if the team is sufficiently isolated from or interrelated with the rest of the org. In most scenarios, teams benefit from participating in the external cadences to a certain extent. Then determine the lifecycle of the team — is the team newly formed? A new team typically has no operational debts and hence the ops process could be omitted.

Generally, more senior folks should participate in more cross-team affairs and the more junior folks should be shielded from such concerns. This allows the former to hone their design skills and the latter to focus on the immediate tasks at hand.

At a glance, the internal processes should be either required or encouraged across career levels. The external process, depending on the reporting structure, where “external” could be multiple layers, the higher the career level the more toward “required” and vice versa.

The operational process should be attended by all since everybody could be on-call and hence should uphold the bar of excellence. The project process largely depends on who’s the point of contact (POC). Grooming should attended by domain (spanning multiple projects) owners, who should ensure tech debts are paid down and improvements are made in the respective domain periodically. Planning should be attended by project leads (or tech leads) to commit to what is deliverable in the next cycle. Demo is one in which each project’s progress is showcased and should be attended by all.

*Caveat: when push comes to shove, prioritize internal over external and operations over projects.

🙌

After constituting the team’s process, how do we measure the result? Is looking at the team domain’s KPI enough?

Nay, the domain KPI is a lagging indicator compared to the team’s input, sometimes as late as a year. Engineering leaders need to also look at the IC’s performance metrics as they map to the process, as well as their personal fulfillment.

Performance metrics

For the process to self-perpetuate it must be granularly mapped to the performance metrics. At Uber, the IC performance is broken down into 3 areas: coding, design, and leadership, where more senior folks are more geared toward the latter 2. If the process is adhered to the team should be running as a well-oiled machine and the IC performances should be indicative of that and vice versa.

Personal fulfillment

If the purpose of the process is unclear and the team’s buy-in is absent, folks will be demoralized. Similarly, if the process caters only to the team’s KPI without regard to the ICs’ personal fulfillment burnouts will ensue. Hence periodically reviewing the ICs’ fulfillment à la Ikigai — aligning skill, passion, reward, and impact — is just as crucial.

Tuning the 3 KPIs

Looking at the team impact, IC performance (on the process), and IC fulfillment together, engineering leaders can tabulate a truth table with interpretations as follows:

If the team impact and the personal performance misalign, question the lagging factor of impact, then ask if the process properly reflects performance. When the team impact is high despite low IC performance, coaching should follow. When the IC performance is high but the IC fulfillment is low, review how and where the IC is allocated in the process; also, ask if they are already performing at the next level, worthy of a promotion.