Merge code every week. That’s what you should be saying to your new Software Engineering hire. Let’s discuss.
Managing performance for something like software engineering sucks. Performance management is never fun. But with something like software engineering, it’s particularly difficult. There’s just too many variables.
If your star quarterback throws less touchdowns, the decision is easy.
If your new engineering hire didn’t properly translate semi-ambiguous requirements into a high-impact feature over their first three months while the Tech Lead was out on leave and the team was mid-stream on a migration to a new frontend framework that ran into many unforeseen issues, uhhhhh - who’s fault is that?
In a complex game, simple heuristics are your friend. Here’s the simple rule for managing a new-to-the-team software engineer: software engineers should merge code every week.
This rule is powerful because: 1) it helps avoid a number of classic onboarding issues, 2) it is just as useful for holding the manager accountable as it is their report and 3) it has a whole slew of good long-term outcomes for the new team member.
Onboarding Issue One: You Weren’t Ready For Your Report
What’s that you say? There’s no way this new hire could contribute code their first two weeks? There’s no work ready for them?
Cool story. You weren’t ready for your report to join.
Go find some simple things for them to work on to get practice with the SDLC. It should take all of 10 minutes. You probably have a PM who is just itching to get a bunch of small “one day, but not yet” things off of their backlog. Today, they’re your best friend.
Onboarding Issue Two: You Didn’t Set Clear Expectations For Your Report
Huh? You’re giving critical feedback on month three and your report says they had no idea you expected higher velocity on projects?
Sounds like you didn’t give them clear expectations. Instead, you let them waste time watching optional training videos about outdated architecture. You should have had them made sure they were shipping code each week from week 1.
Onboarding Issue Three: You Didn’t Unblock Things For Them
Your report wasted 15 hours at the end of the week because they didn’t want to interrupt you, but they don’t have the access to your CI system and they need it to get this work done.
Next time, tell them that their once-a-week-item is a top priority. Give them permission to make it a top priority, because it should be.
Onboarding Issue Four: Fuzzy Work
Pushing for at least one PR per week forces conversations on the tractability of work. You can avoid sending your report down rabbit holes by forcing the discussion each week of what can be shipped. Regardless of whether it’s an issue with the work you gave or with their ability to do it, you need to confront that issue head-on if it seems like something can’t be done this week.
From the SWE POV
If you’re joining as a Software Engineer, you should aim to follow this rule as well, and hold your manager accountable to making this able to happen. All of these anti-patterns exist from both perspectives, and both the manager and the new engineer should aim to work to avoid them.
If you’re a new engineer, you need to learn to ship code as soon as possible. Each time your ship code in a new environment, you learn something new. Delaying those learnings can meaningfully hedge your impact in the short, medium, and even long term.
Relatedly, the biggest mistake many engineers make when joining a new team is normalizing slowness: slowness in coding, slowness in deciding, slowness in testing, slowness everywhere. There’s often fast-ways and slow-ways of doing things. Pair with senior engineers, scrutinize things that seem to take awhile. Hold up everything to the rule of “ship code this week” and assume anything blocking that is either fixable or should be fixed.
Long Term Success
The one-item-per-week rule should also live well past onboarding. It helps avoid the version of these onboarding issues that show up well into one’s tenure. Plus, it also helps avoid other fun challenges like:
- When a mid-level engineer takes on a big project and needs to make sure they’re chunking well.
- When you a manager need to track and prevent performance regressions.
- When you as a manager need to prevent very senior staff from slipping into a role is too much advisory and not enough execution. A great Staff Engineer, for example, should be able to ship ~50 PRs a year and do high level design and advise teams and more.
- When you need to track and prevent performance regressions.
- When you as an SWE need to have simple weekly goals for motivation and focus.
A Note On Other Vocations
Note: this works for many vocations. Work is about output, and the longer you delay creating output, the harder it is for people to learn how to create and do what they were hired for. Many, many jobs have the equivalent of tech debt and complex systems, and the sooner people can poke through to the other side by doing, the sooner they can start conceptualizing the system.
If you’re a chief surgeon designing an onboarding program, maybe don’t do this. But for anyone else, especially if you’ve had issues with performance managing people, think about the one-deliverable-per-week rule as a guide.
A Note On Other Criticisms
- This just optimizes for meaningless work. Only if you let it. Obviously, review the work that’s being done.
- My vocation has no concept of a deliverable like a code-merge. Your vocation definitely has deliverables. Whether it’s an outbound email target or a strategy statement or writing 10 cards for the backlog or writing a design document or conducting user interviews - your entire job is to do things that create tangible value. And even if you happen to have some job that is mostly something abstract, like making decisions, you should write that down, it’s a deliverable. Writing things down is a key part of scaling. You can’t run a startup off of spoken word in one-off meetings like you’re in Goodfellas.