Three Rivers: Engineer One-On-Ones for the Socially Anxious

I don’t think of myself as socially anxious. And I don’t think others in my life would apply that label either. I’m gregarious and extraverted. But I do suffer from one particular form of social anxiety at work: one-on-ones with engineers.

I know the one-on-one should be driven by the employee, and it’s the heart of my management practice. So why be anxious about it? One simple question:

What are we going to talk about?

This can be as simple as just starting with, “So, what’s on your mind?”. Then, using Kevin Kelly’s trick (#5 on this list) of asking “Is there more?” times until there really isn’t anything else to be gleaned from the topic the employee brings up.

But when I find myself stuck, or the employee doesn’t have anything to talk about, I fall back to the “Three Rivers” one-on-one. That starts with one simple question:

Why don’t we pull up your latest PR and talk about it?

The Three “Rivers” of a PR

Each PR has three main parts to it:

• the commit
• the discussion
• the commit message

Each PR is a tiny trickle that feeds into three distinct rivers that you can follow downstream to the sea, and glean tons of insight as to how things are working at every level. You can find gaps and disconnects. At the same time, you connect the engineer to how their work fits into the broader work of the company and team, and hopefully into their career. These rivers are, respectively,

• the technical architecture,
• the developer culture, and,
• the development and project management process

The Commit

This river flows downstream from a few lines of code (hopefully 🙄), to your org’s technical architecture.

As a manager, you don’t get a lot of opportunity to “patrol” your code. I ask to be shown the code. This gives me a touch point to understand the code at the most granular level.

This also gives me an opportunity to be the devil’s advocate for code quality, protecting the developer experience.

Questions:

• Is this code you would like to inherit from someone who left the org? Is it readable? How are the variable names and function names? Is it too clever, trying to do too much at once, at the expense of maintainability?
• What file does this sit in? What folder?
• Is there a part of this area of the code that you always think about when you’re in it? Why?
• If you could take time to refactor one area of this code, which would it be?

This gives me a sense of code quality and health. From there, we flow to architecture.

Questions:

• Where does this component sit in an architecture diagram? Is there an architecture diagram? What other parts of the architecture touch this part?
• Which component in this diagram keeps you up at night? Why?

This gives me a sense of where operational risk lives. Where we might want to shore up a shaky implementation with some solid monitoring, or spend some cycles refactoring.

That 15-minute conversation can spin off 15 months of potential work, but that’s not the point of it. Some of it is to help you as a manager understand your code base and architecture more comprehensively. But it’s also Socratic and didactic in nature. Drawing these answers out of people helps them to learn, even if you don’t immediately do anything about the answers themselves.

The PR Discussion

This river flows from a single dev-to-dev interaction, downstream into the team dynamics and the developer culture of your org. After all, what we call “culture” is just the aggregation of a thousand little value judgments.

This one can meander so many ways that there’s not really a set of stock questions you can ask here. Rather, we get the opportunity to dig into how much or little feedback an engineer gets on their code, the quality and tone of it, and who gives it.

Questions:

• Is there a person who you see picking up everyone’s PRs and helping them grow? Is that person a staff or principle engineer? If not, can we groom them that way?
• Is there any discussion at all on this PR? If not, should there be?

This “river” doesn’t always yield the most conversation, but it still bears following.

The Commit Message

This river flows from a single unit of work, down to the sea of what the org is trying to accomplish.

Most places I’ve worked, it’s customary to put the JIRA ticket number into the commit message. So we follow the river downstream to the ticket.

Questions:

• What ticket does this solve?
• How long had that ticket been around before you started working on it? How long have you been working on it?
• Was it well defined when you started? Are there solid acceptance criteria?
• Did the ticket criteria change as you worked on it?
• How well estimated was this ticket? If it took longer than expected, can we bring up the planning poker record in Slack and see if anyone thought it would take longer and if their reasons were right?

From there, we go to the epic.

Questions:

• Is the ticket part of an epic?
• Is there a “definition of done” for this epic or will it live forever? Is there any scope we can cut here?
• Can the work be simplified? Are the requirements clear? Who owns them?

From the epic, we go to the company goals:

• What higher-level goal/OKR/rock does this epic support? Is that goal measurable? What does it accomplish for the company if we succeed?

If you run into a dead end at any of these points, you know you have work to do. If you don’t, then you’ve taken someone’s very in-the-weeds work and connected it to a larger mission. The engagement effect is often palpable when you do this.

And, if you had to do a lot of hand-holding to connect a piece of code to the OKR/goal/rock in the dev’s mind, that’s great feedback on how well the upper levels have communicated their strategy.

Conclusion

Hopefully, you can see here that a single piece of work can spin out into a far-ranging conversation. I’ve long said “The point of the one-on-one is to connect personal goals to organizational objectives.” The Three Rivers approach can help your engineer connect their day-to-day to the direction the org is headed. Of course, the next step is to uncover their personal goals and to query whether the work they’re doing is taking them in the direction they want to go. Once you make that connection, the engagement dividend can be palpable.