Automate Your Influence

Time in the day is constant, but as your career grows, so should your impact. You can scale your impact while managing your time commitment by learning how to automate your influence on and across projects.

Testing

Nearly everyone agrees that testing your software is good, but it’s essential to see a project’s test suite in the context of the big picture.

Why do we write tests? Well, manually testing everything is tedious and time-consuming. So, we automate some of these checks in unit, integration, and end-to-end tests.

When we have a test suite, we can quickly get a quality measure on the codebase. Does this change break existing functionality? Do things look okay after updating my dependencies?

What does this have to do with your influence? As you become more senior, your responsibility for a project or team will grow. If you’re a lead, then the buck stops with you. Spending all your time manually testing the project’s quality will prevent you from contributing to other areas. Also, as the project grows more complex, you won’t have enough time in the day to check everything. Property testing is unfortunately underutilized in the industry. I like to think of it as second-level automation. It helps automate your tests, which are automating various checks.

There’s limited time in the day, so you’ll need to prioritize testing things that will have the most impact on the product, given its current state. But once you’ve invested in a sufficient testing suite, it will help you scale. It will also free up your future time to work on other initiatives.

Static analysis

A codebase’s quality depends on more than just producing the correct outputs given specific inputs. If the code is hard to change, then its utility diminishes. As your career grows, you’ll need to concern yourself more with the code quality and its effect on the product.

Static analysis can detect quality issues with code, and depending on the tools you use, it can even automatically fix common problems.

Again, as we said above, there’s limited time in the day, and spending your time manually checking code for specific problems is not the best use of your time. Investing in a linting suite will help the team catch problems early and enforce standards.

With a linting suite, you’ll influence the codebase for much longer than the initial time investment it takes to craft the suite.

There are numerous different linters, and like tests, you’ll need to prioritize which are best for your particular project. Type checkers are one of my favorites, and luckily their use is growing within the industry.

But some specific lints or linters will cause more harm than good, so continually evaluate their effectiveness and don’t be afraid to iterate.

Tooling

Tooling is a more general version of the previous sections, but it’s important to mention. Tools shape culture, and you can help shape the team’s culture by advocating for and building quality tools.

People gravitate towards the easier thing to do, so you can guide this with the tools you help craft.

Tooling is vital because tooling decisions are often sticky, and they become integral parts of our workflow. Tools even influence the way we think about problems.

Like above, there’s a balance in prioritizing what tools to invest in or what even needs tooling.

Tooling work also allows escaping from a local maximum since tools often entrench past decisions. Iterative improvements within the current system are essential, but you risk missing the forest for the trees. The chances of arriving at a global maximum with only iterative improvements on the status quo are slim.

Part of your mandate as an organizational leader is to improve the status quo. Therefore, updates to foundational tools and processes may be important—or even required—to move the needle.

Documentation

The curse of knowledge is real, and documentation is a critical component in counteracting it.

When you work on a project, you’ll gain a lot of “folk” knowledge about it. This knowledge presents a risk because if it’s only in your head, then you’ll need to be present in conversations for others to learn and benefit.

Once again, there’s not enough time in the day for you to be in every conversation, so we must turn to documentation to scale your influence. Walking someone through an aspect of the project is quicker than writing a detailed document, but the document will persist. It’ll continue being a valuable reference for as long as it tracks reality.

The same applies to your product’s users, who will have even less context. Quality documentation can resolve problems before they bubble up to you, while insufficient documentation can prevent market uptake of your product. If your documentation addresses 80–90% of common issues, you can spend your time on other impactful work.

Testing, static analysis, tooling, and documentation are all things you can use to automate and scale your influence. They will continue to impact your projects long after the initial time investment. And if they’re of sufficient quality, you’ll have more time to pursue other initiatives and further scale your impact.