Strategies I used to create leverageable work as an engineer

Leverageable work helps us stand on the shoulders of giants and leap forward. It is a great way to maximize impact as an engineer, improve the team’s velocity and build your personal brand. While I was busy getting stuff done, I often wondered and asked my mentors how I could go that extra mile to create leverageable work. Here are some strategies I picked up along the way.

Prolific documentation

While it was quick and easy for me to immediately answer a technical question or “whiteboard it” to explain it to a team member, forcing myself to pause and document it instead, paid off in the long run. Although my intention was knowledge sharing, these documents freed up my bandwidth to focus on other strategic tasks.

Over time, I realized this created a collection of artifacts that meaningfully up-leveled the team’s knowledge. Some of the documents I wrote were for coding conventions, troubleshooting runbooks, code review checklists, feature ramp checklists, engineering design templates, command-line productivity tips, etc. These were easily discoverable and lived well beyond the project timelines and sometimes served as critical onboarding material for new hires. End result - leverage, using documentation as low-hanging fruit.

Templates, code gens, and skeletons

Applying a similar mindset to writing software, I observed there were ample opportunities for writing re-usable classes, or better yet templatizing some of the code which could be easily extended for future use cases. Going a step further, ‘code generating’ some of the frequently repeating “boilerplate” code (like CRUD modules) helped me speed up my velocity of execution on projects in scenarios like expanding the data model and related code to add yet another data entity. While it created leverage, it also revealed pain points that other similar teams may be dealing with, leading to ideas for a broader solution and making them widely available.

When we were kicking off a new project and building the code from scratch, I built out code skeletons, with the goal to unblock others who would be working on the project. This helped the whole team accelerate and they used this base layer to visualize what the code structure should look like in its final state.

I have also found that this pattern of thinking can be extended as I transitioned to a management role (more on that in a future post). What are some of your ideas for creating leverageable work? I’m curious to learn.

Shoutout to Bef Ayenew for being generous with his time and providing valuable feedback on this article.