Senior Engineers Reduce Risk

If you read articles on career development in software, you’ll already know there are many things a senior engineer is not. They are not, for instance, just someone with ten years of experience. They are not just someone who maintains a popular open source project. They are not just someone who wrote the initial prototype for their company’s flagship product.

Instead, senior engineers possess many disparate skills, the exact composition of which varies from author to author. These laundry lists are detailed, nuanced, and typically leave the reader feeling as if they have a long way to go.

Empirically, though, there are many people who have the title “senior engineer” who do not possess all these skills. Unless all of them can be explained by title inflation or poor management, this is a serious disconnect with reality. We have to treat these articles as aspirational: a description of the industry as it should be. For someone wanting to make a significant, recognized impact on their company, today, these articles are more distracting than helpful.

Senior engineers reduce risk, in every sense. Often, “risk” is used to describe technical risk, which is that the software doesn’t function properly, or is never completed at all. But there are other issues that can prevent the business atop the software from succeeding — risks around process, or product design, or sales, or the company’s culture. A senior engineer understands these risks, and mitigates them where possible.

senior engineers affect the larger system

Most startups die because they build the wrong product. The core risks are rarely technical; if no one wants the product, building it well won’t change the outcome. The most important thing an engineer can do during this time is either speed up the search, or narrow the search space. Building prototypes, gaining domain expertise, and generating metrics all lower the chance the company will run out of money.

Once a company finds product-market fit, the risks change. The product has to work, scale, and easily adapt to anything learned by the customer-facing employees. New users introduce technical risk but, more importantly, new hires introduce risk into the company’s processes and culture. If the company can’t make new hires productive, it will collapse under the weight of its payroll.

The software will need to be broken into manageable pieces, or else new engineers will need to hold the entire growing system in their head to be productive. Where before there may have been one engineer who handled “talking to customers”, the planning process may now need to include salespeople. Above all, each new hire dilutes any clarity that existed around what the company values, and what it doesn’t. Left alone, the company will become whatever people were used to at their last job.

As the company continues to grow, any new project will require collaboration across teams. After a few projects get delayed because of one missing piece, the leadership will start to value predictable results above all else. Processes will be established, recurring “sync” meetings will be scheduled. Variance in productivity, above or below the mean, will be minimized. The largest risk is perceived to be a small component which is never completed, obviating all the other related work. In this environment, a senior engineer is an engineer who works within the processes, and even refines them, to ensure reliable output.

This narrative arc describes the average growing software startup, but no company is exactly average. The precise risks will vary depending on who founded the company, what it does, and who they hire. The senior engineers may reduce risk deliberately, or simply have the right skill set at the right time. A fresh graduate with the right domain expertise can have a huge impact on the larger system without ever understanding it.

senior engineers find leverage

Impact can be serendipitous, but the greatest impact comes from a deliberate attempt to effect change with the least effort. If production is unstable, precluding a common failure mode will have a more immediate impact than volunteering for pager duty. If the company is rapidly hiring, improving and standardizing interview practices will have a broader impact than conducting a dozen phone screens every week. If there are any junior engineers, spending an hour to talk over unfamiliar topics will have a longer lasting impact than writing more code.

Where possible, solving the general form of any problem is preferable to solving a single instance. However, this is only possible if the problem space is well understood. Premature abstraction, in code or elsewhere, introduces risk. If the failure modes in production are poorly understood, volunteering for pager duty may be the only way to really help.

senior engineers are storytellers

Most risks, especially where managed effectively, never come to pass. For this reason, it’s often impossible to tell the difference between real risk and perceived risk. By the same token, it can be difficult to tell the difference between real impact and perceived impact. If a senior engineer identifies a significant risk, they have to be able to concisely explain and prioritize it for a non-expert audience.

Some see this as a form of corporate politics; a skilled storyteller can protect their company from non-existent risks, and be seen as a hero. But the fact that storytelling can be misused doesn’t make it invalid, just something that should be approached with a critical eye.

senior engineers choose companies with the right risks

Every company has different risks, and so every company expects something different from their senior engineers. An engineer who has spent the last five years making small, continuous improvements to the processes in a larger company may not enjoy or even understand the sort of role expected by a three person startup. The expectation that “senior” is a fungible title is both widespread and harmful, leading to unrealistic expectations from both engineers and companies.

Through trial and error, engineers can identify the sorts of problems they enjoy solving. A senior engineer should find a company which both has those problems, and knows it. Anything else will lead to frustration, and eventually apathy.

Likewise, companies should try to communicate their risks, early and often. If we were to judge by what’s asked in interviews, most companies believe their only risks are technical, but that’s absurd. The interviewers know the real problems facing the company, but the polite fiction is that they’re only temporary, and soon everyone will be able to focus entirely on the algorithms, which are what really matter. Since most companies tell the same story, candidates have to read between the lines to see if there’s a good fit. Honesty would make things much simpler.

senior engineers know titles don’t mean much

Without context, knowing someone was a “senior engineer” tells you almost nothing. Titles can matter a lot in some environments, but in those cases titles are just another tool for reducing risk; if being a senior, or staff, or principal engineer is the only way to make your voice heard, then pursuing those titles is worthwhile. More often, though, it’s just a distraction.

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising &sponsorship opportunities.

To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!