Senior IC’s, Technical decisions, Influence
This week, I've been reading "The Staff Engineer's Path" and I've decided to take a detour into a different topic and share my thoughts on it. Despite the title, I think this book applies to any technical senior individual contributor role (IC). Whether your title is lead, staff, principal, or architect, this book contains valuable information.
The first question that resonated with me was, "What kind of work should these roles take on?". This is hard to define and depends a lot on the company context, but most people agree that setting technical direction and taking important architectural decisions are part of the job.
“The work that’s most important will often be the work that nobody else sees. It might be a struggle to even articulate the need for it, because your teams don’t have good mental models for it yet. It might involve gathering data that doesn’t exist, or spelunking through dusty code or documents that haven’t been touched in a decade. There are any number of other grungy tasks that just need to get done. Meaningful work comes in many forms.”
There is much debate about whether senior ICs should spend the majority of their time coding. However, I don't believe this is the right discussion to have. Instead, I agree with the notion that "At this level, your goal is to solve problems efficiently, and programming will often not be the best use of your time. It may make more sense for you to take on the design or leadership work that only you can do and let others handle the programming."
In my opinion, the most important thing is to solve problems in the most efficient way possible. Whether coding is required or not depends heavily on the context, project, or team you are working with. Therefore, do whatever it takes to solve the problem effectively.
One thing is key: “Know why the problem you’re working on is strategically important—and if it’s not, do something else.”
Technical Decisions
Underlying the product or service your organization provides is a host of technical decisions: your architecture, your storage systems, the tools and frameworks you use, and so on. Whether these decisions are made at a team level or across multiple teams or whole organizations, part of your job is to make sure that they get made, that they get made well, and that they get written down.
There is often this train of thought that senior ICs should make all technical decisions in a given project or should own all architecturally relevant decisions, however defining this is not always easy and is not always the best way to move forward.
If the goal is to do whatever it takes to move a project forward, sometimes the best thing to do is get out of the way! Step back, and let the teams decide. Do ensure that they’re following the right process and provide context of the broader view, ensure an understanding of the impact and trade-offs, “Gathering context takes time and effort. Individual teams tend to optimize for their own interests; an engineer on a single team is likely to be laser-focused on achieving that team’s goals “.
This brings us to the concept of local maxima, often the best decision for a single team/domain, might not be the best decision for the company when taking a broader view. This is why it’s essential to have a big-picture understanding and a broad perspective about what’s happening across the organization and of the long-term technical goals. “To avoid local maxima, teams need decision makers (or at least decision influencers) who can take an outsider view—who can consider the goals of multiple teams at once and choose a path that’s best for the whole organization or the whole business.”
Influence
Having a broader context is important. However, this understanding cannot only stay in your head. You need to align the organization around a shared vision that takes this understanding into account and “steer the boat” accordingly. This requires more than just technical knowledge. You’ll need to deal with egos, politics, exert a large amount of influence, and get really good at getting buy-in for your ideas and projects.
Your ideas may be the best, but without buy-in and influencing key stakeholders, you won't be able to make them happen.
Bear in mind that getting people to agree isn’t a chore that stands in between you and the real work of solving the problem: the agreement is the work
The realization that the agreement is the work changed my perspective. Without it, your vision won’t be accomplished. Therefore, getting agreement on your technical vision is an art that you'll need to master. To do so, you must identify and onboard all relevant stakeholders (keep in mind that influence and key stakeholders for a given subject do not always match the org chart), and secure good sponsorship with the power to decide and allocate resources to your initiatives. Reputation and a good track record of successful projects are essential for this to happen (although this can be a bit of a chicken-and-egg problem).
If there’s someone who’ll need to give a thumbs-up to your plan, you’ll want those people to show up to any decision-making meeting already convinced that the change is the right thing to do
Gather alignment from your stakeholders, one by one if necessary, to convince them that the change is the right thing to do. One important thing (that you may have already learned the hard way, i sure did) is to not go into a decision-making meeting about a complex technical matter facing a cold audience. Doing so will usually lead to derailment in a number of ways, and nothing productive will be achieved.
Remember that alignment is a two-way street. As you work to align the organization around your technical vision or strategy, be open to the possibility that your plans might change and improve based on feedback and discussion.
This process is not just about getting people onboard, it's also about improving your solution based on feedback from relevant stakeholders with relevant experience.
What’s the difference between a document being yours and the organization’s? Belief, mostly