In my previous post, I reviewed feature flagging and using Tailwind CSS. In this post, I continue my review of engineering management.

Measuring Cycle Time

Cycle time starts from the engineers move a ticket from To-Do to In Progress, and it ends at Done.

I review the average ticket cycle time every two weeks with my team. Jira Control Chart comes as a handy tool to measure cycle time.

When the average cycle time increases, it indicates our delivery speed slows down. The factors could be scope creep, too many WIP, big PR, etc.

When the average cycle time decreases, it indicates that we are doing well. We need to maintain the same practices.

We identify a couple of ways to shorten the cycle time and they make engineers' life easier.

Reduce PR size. We observed our code review pattern. Team members tend to choose to review a smaller PR over a bigger one. If the PR is huge, the reviewers prefer to block off an hour or two from their calendar to perform the review. This delays the time to review. To deal with this, we split the feature into many smaller chunks to make the review process easier.

Pair code review. Sometimes, we discover new information during development and we change the implementation. In this case, the review is difficult. If this happens, the code author will set up a meeting with reviewers to walk through the code together. Reviewers will ask questions and the code author answers on the spot. This minimizes the back-and-forth conversations to clear things up.

Deploy more. Before, we performed deployment only if there was a hot-fix or urgent feature. If nothing urgent, the merged code will stale for a while before going into production. Now, we deploy every day. We intend to get the task out of our heads and focus on the next feature.

Regular 1-on-1

"I work with my direct report every day. We don't need any 1-on-1 session."

I have a misconception in 1-on-1 before. Now, regular 1-on-1 with direct reports is mandatory to me as a manager.

I run two types of 1-on-1 with my reports, monthly regular 1-on-1, and weekly engineering 1-on-1.

Monthly Regular 1-on-1. In this session, I concern about their personal and career growths. Instead of acting as a superior, I position myself as a career mentor. I often give advice based on their growth in general, not limited only to the current company.

Speaking to team members and motivating them as a recommendation from a friend, more so than an order from superior. I personally enjoy the refreshing discussions we have.

This is the feedback I received from my report. I am happy our 1-on-1s bringing value to her.

Weekly Engineering 1-on-1. I started this session as an experiment with one member. In this session, we exchange our thoughts in writing code and making technical decisions. As a result, we kick-started a side project to build a design system.

Writing RFCs

RFCs stands for Request For Comments.

For better or worse, Requests for Comments (RFCs) are how we specify many protocols on the Internet. — https://www.ietf.org/blog/how-read-rfc/

IETF (Internet Engineering Task Force) adopts some of the proposals published as RFCs as Internet Standards.

The OAuth 2.0 Standard is the creation of the process of RFCs.

Some large companies, such as Uber, use the RFC process to maintain their open source projects, BaseUI. You can read how it helps Uber to scale its engineering teams from Gergely Orosz's post.

Our teams adopted this process based on similar reasons, such as information silos and too many meetings. Although, we don't have a standard process and a task force to guardrail this process yet. But, I definitely feel that this is a necessary process for growing teams.

I've written a few RFCs. I started to write one when:

1. a change is affecting many systems
2. I have more than one approaches to solve the problem

Encourage collaboration between teams. When a change is affecting many systems, we write RFC and ask for feedback from affected teams.

Crowdsource solution. In the RFC review meetings, we accept the new ideas and improve the solutions.

Documented solution. Although I don't write code often nowadays, from all the RFCs I've written, my team executed them well. I also indirectly influence the code.