Usually, in product teams, there are more problems to address and ideas to try than capacity in an engineering team. Bottlenecks usually come from indecision, rather than lack of ideas. Ideas come from many sources:

• founders and/or product manager vision
• customers needs, surveys, feedback
• internal team needs, surveys, feedback, coordination
• engineering team suggestions for optimizations, refactoring, and improvements, as well as strategy and vision
• security fixes, bugs, support, dependency maintenance, deprecation maintenance
• compliance, certifications requirements additions/changes

… and that’s certainly not a full list! 😊

Some elements of this list are more business-related, others are more technical. This is why often different context is needed to effectively prioritize them and non-technical product manager will delegate technical tasks prioritization to the tech lead or a most senior developer.

However, identification of the work is also different between those two types - let’s dig deeper! ⛏️

High perception of the contributor

For product and business ideas almost every stakeholder has their opinion. Many of these “arrive to us” through mentioned feedback, and a skill to learn is how to say “no” 😊

For technical ideas, some changes in dependencies, suppliers, deprecation, and security patches can be identified automatically through special tooling like https://snyk.io/, vulnerability scanners, deprecation warnings. We can also stay on top of news with security or language-specific newsletters.

However, our system-specific technical projects can usually be identified only by engineers who are close to actual implementation. Daily struggles, annoyance, understanding what contributes towards the large estimation, system awareness and its complexity.

The unique perspective of engineers allows us to suggest high-impact and low-cost solutions, which justifies our early involvement in modern product discovery, but we are also the ones who know where biggest technical risks and bottlenecks are. Non-technical product managers cannot identify such tasks. An engineering manager who is barely coding or an ivory tower architect may have an opinion which may be simply wrong.

So, the first problem is that only contributors have good visibility into the technical work which has to be done. The other problem is that our perception is subjective… 😅

Difficulties in initiative of engineers

Everyone has opinions on what clean code is, but surprisingly during code review, we discover that those opinions can differ quite a lot from person to person. That sometimes leads to engineers being uncertain if their opinion is worth pursuing further. Biases don’t help us:

• Impostor syndrome - lack of faith in your skills
• Bystander effect - somebody else will do it
• Learned helplessness - we always do it that way even if it sucks
• Sunk cost fallacy - we invested so much into this, it’s better to finish it that way

As a result, tech debt often arises in projects, and there is an “accumulated feeling” that something is wrong, but there is no clarity on where exactly. Alternatively, the team knows it (gossip, whining) but it’s simply not elevated in its importance and scale to a level of a problem where it should be taken care of. In other words, if contributors won’t raise it, nobody will.

Managers are aware of that (usually) and they craft tools like DevEx surveys, and health check retros or they design career paths around initiative and ownership to “spark” those behaviours in teams. This is also why people who can overcome those difficulties and proactively discuss problems are usually promotion materials - because leadership trusts in that specialist to do what others won’t.

Challenges of convincing others

When we combat ourselves to suggest a change, then we have to convince others of it. It’s not easy. Once again we have a couple of biases to fight against:

• Ikea effect - it’s ourrsss…! My way, or highway.
• Tunnel vision - that solution HAS to be right, I won’t take a look at alternatives, leave me alone!
• Confirmation bias - you’re saying I’m wrong? I’ve found this article to prove YOU are wrong.

Usually, as engineers, we like to discuss ideas based on data and arguments. However, soft skills are rarely engineers’ strongest assets. I still recommend writing RFC as a way to spark those discussions, with a deadline (two weeks or less). With enough visibility it allows the best ideas to win even if you lack charisma or natural charm 😉

For smaller initiatives and ideas you may only need to convince the product manager, and in such cases, I found two strategies which help:

• Explain what happens if you do nothing - you may sometimes surprise yourself, that nothing will happen, and close the JIRA ticket immediately… 😂
• Try to explain consequences in money language or other measurable effects - it’s way better than saying “It slows the team down”.

It requires a bit more legwork but after enough attempts, you’ll build enough trust with the product owner they will just trust your judgement. For me, this type of initiative on a team level is mandatory for senior-level engineers.

Senior vs Staff

From my experience what often happens is that when an engineer exceeds the level of a “senior” it seems to be a waste to have this specialist work only in the scope of a small product team. This is why often those people are being moved to platform teams so they can amplify more engineers through tooling, or they are being involved in many cross-team discussions.

In other words, it’s a way to increase the influence of those specialists. Identification of large technical projects is the same thing!

As a senior engineer, you may be an amazing performer in your team, swiftly executing tasks without any help. As a staff engineer, you’re identifying technical projects for those seniors (and convincing them it’s the way to go) so they can show how fast they are on the execution layer.

This is why, for Staff, it’s also important to stay on top of the bleeding edge of technology. Technical newsletters can open your eyes (see my recommendation), side projects, experiments, newest technical books and courses can suggest how things could be improved - often other teams struggle with similar difficulties.

As a staff you should also directly contribute to technical projects like a senior engineer would do, but you are frequently identifying & creating technical work for others through your cross-team influence. Because you are still a contributor close to the code, you can do this way better than the engineering manager would do. If there are many competing ideas, this is where the people management aspect chimes in and you should fall back to the engineering manager (or above) to prioritize - otherwise you won’t have time to contribute… 😂

As a Staff, you are not just great in execution, you are the spark 🔥 of project technical improvement.

Summary

• Contributors close to the code are best suited to propose technical improvements and are usually the only ones to do it.
• It’s a common problem amongst engineers to struggle with an initiative to raise their ideas and effectively convince others to pursue them, there are many human biases which make it difficult and most engineers struggle with soft skills.
• Staff engineers have to influence outside of their team and the ability to identify large technical projects (and delegate part of this work to seniors) is one of the ways to create such influence.