From entry level to senior+ developer - Multiply impact with developer leverage

A major theme of this blog, is “how to do more with less”. For example, using time management techniques to excel at multiple pursuits at once while also increasing leisure time.

I came across the term “Leverage”, defined as “a developer’s impact produced over time invested”, in Edmond Lau’s book, “The Effective Engineer”.

\[\text{Leverage} = \frac{ \text{Impact Produced} }{ \text{Time Invested} }\]

Similar concepts are mentioned in career development books as a way to “scale oneself” exponentially, not just linearly, which becomes important once one is past entry-level roles. This is, in the career sense, how to “do much, much more with the same amount of time”.

I’ve had to learn and un-learn some patterns over different projects as my role grew in responsibility and technical leadership, and here I’d like to share the lessons I’m learning (in progress) about building leverage as a developer.

• Linear impact at the entry level
• Exponential impact at the senior-plus level
• Your path to senior-plus roles

Linear impact at the entry level

Code for one hour, output one hour’s worth of progress.

As an entry level developer and/or data scientist, one is usually handed tasks, along with prescriptive details, that the senior folks on the team divvying up this work had decided on.

Instead of saying “figure out how to predict churn”, the task will be “try and explore the DB and see what’s related to churn, and build an XGBoost model for it. For the logic, you can reference this other model.”

This can be even more prescriptive if the company has established process on churn model builds, such as “look at table X, Y, Z.” They’ll sit the entry level data scientist down and explain how the labels and features of the churn model will be.

For a task that might on average take 5 hours for an experienced developer, the entry level developer might take an additional 5 hours learning, asking questions, or making mistakes (totally normal, everyone’s been there) - for a 10 hours total.

During this initial phase, the entry level person is focused on learning - and their output will increase linearly with the hours they put in. If they were to do two tasks, it would take 20 hours (\(2 \times 10\)), and so on.

After doing various tasks over time, the junior person slowly becomes able to fill in the gaps in ambiguity, such as proposing to try LightGBM for reasons i, j, k.

Exponential impact at the senior-plus level

Spend one hour, create 10+ hours of impact and time savings.

Being effective at the above, the entry level person starts to improve their average output per hour - 10 hours slowly becomes the average 5 hours.

I’m going to use the term “senior” very loosely here, since the definition varies wildly in the industry. But let’s say this senior developer has successfully shipped some software/ML projects, and have built up intuition over time, further speeding up their troubleshooting abilities. For the exact same task, they might take 4 hours instead of the average 5.

To sum up, we have the following, totally made up estimates for the time required for the same task:

• Entry level - 10 hours
• Average - 5 hours
• Senior developer - 4 hours

For a project perspective, it would be lovely to have only “senior and above / senior-plus” folks on it - it could be completed so quickly! Of course, this is not reality - senior folks still have to learn the aspects of a project they haven’t encountered before, and teams often have new entry level members onboarding.

Instead of always letting the senior person immediately do the tasks they’re good at, and finishing it in 4 hours, there is compounding returns for the senior person taking the time instead to teach an entry level person.

So, the senior person will take 1 hour’s time to onboard or mentor (could include pair programming etc.), and reduce 3 hours of the junior person’s work. The senior person doesn’t personally do this task, instead focusing on a more difficult and ambiguous task.

In total, 9 hours are spent:

• Senior developer - 1 hour (to onboard/mentor the entry level)
• Entry level - 7 hours + 1 hour with Senior developer

At this point, it seems like over twice the time spent if the senior developer had just done it (9 hours vs. 4 hours). Why would we do this at all?

Unless it’s a super urgent feature, having the senior developer on everything is only a short-term gain, but a massive loss in the long run.

The reason for this is the senior developer’s Leverage.

By spending 1 hour with the entry level developer, the senior developer saved 3 hours (of the entry level dev’s time), and also helped save time down the road by multiplying the entry level folks’ skills.

The senior folks (and management) know that next time, the senior person can be called on for a more gnarly task, while the junior person can help with the maintenance of this feature.

If the senior person held a monopoly on that type of feature, then that takes away the senior’s time available to work on other high leverage tasks that really only the senior person can do.

In short, a senior person can increase leverage by offloading and delegating tasks that others can learn, letting the senior person focus on tasks they can do, which makes better use of the senior person’s skills and experience.

The exponential part can happen if a senior-plus person delegates and mentors enough that they create another new senior developer from the entry level developer. The cycle can then continue as the new senior developer mentors another new entry level developer.

Your path to senior-plus roles

I use this example of not “holding a monopoly” on something I’m good at, as a core lesson on leverage that I’ve learned as a Principal data scientist.

I can create more impact by mentoring someone to do those tasks, which frees me up to learn and explore more gnarly and ambiguous tasks. This is again a use of leverage since my past experience helps me learn faster than an entry level developer at these gnarly tasks which require much more technical decision making.

Over time, a senior-plus person passes down this accelerated learning, which again multiplies the skills of the entry level folks.

There are many other ways to build and use leverage - and I hope that you can take some time to reflect on what tasks you are especially effective at, that you can spend the same time but create outsized impact on.

This will be your unique way of leverage that will be helpful on your path to a senior+ or as a senior+ role.

I hope that this is helpful for folks wanting to scale up their impact and grow to a senior-plus role, and not just by linearly increasing the hours they work (please don’t)!