Gui

Evolving as a Senior Engineer: Insights and Reflections

Last year, my manager informed me that she and some colleagues believed I was ready to begin my promotion process for Senior Engineer. At Datadog, we strive to avoid the Peter Principle, so promotions only occur when everyone involved in the process (directors, EMs, peers, etc.) agrees that you are already operating at the next level. But what does it mean to operate at a senior level?

Of course, the company has its own expectations for each level in the “ladder” (for lack of a better term, but I’ve discussed this before). I also researched what other companies expect and cross-checked with what senior engineers I admire do. This post covers aspects of the role that I don’t see mentioned very often. It’s a collection of my own observations.

Asking More About Why, Less About How

The first thing that comes to mind is that a Senior Engineer operates with a larger awareness than before. For a product engineer (and this can also apply to platform engineers with some adaptations), this means relating technical aspects to non-technical ones like business goals and user-centric approaches. Initially, a senior engineer’s priority is to understand why a given feature is being requested and its context.

This involves gaining a deeper level of understanding, possibly challenging assumptions, reviewing major edge cases, or asking for more data. Only with a good understanding of the “why” do they start thinking about the “how,” “where,” “when,” and “which.” How would they tackle the problem? Where can performance challenges arise? Which other aspects should they cover, such as documentation, maintenance, and tests?

Understanding when to stop is also crucial—knowing when they’ve achieved 80% of the feature’s value. This last part, understanding when it’s okay to stop, significantly increases their impact.

Impact vs. Effort

I see a rush to deliver smaller tickets. In itself, it’s not a bad thing if you understand when this technique is needed to produce the highest impact. For example, it makes sense when you want to close as many gaps as possible within a defined timebox before a launch. However, if you mostly focus on smaller tickets, you miss opportunities to showcase deeper work.

Deeper work involves researching solutions for complex problems, acquiring more data through metrics, or experimenting with what others in the industry are doing. You can quickly become super busy with minor tickets and feel overwhelmed. There’s a distinction between doing more and doing extra. Just as you shouldn’t jump into coding something before fully understanding the problem, take time during the week to reflect on your impact/effort balance.

Science involves observing and drawing conclusions. Taking the time to evaluate where your efforts are best spent can significantly enhance your contributions and prevent burnout.

Developing an Opinion

Like those thought leaders in the industry, develop a keen ability to observe team dynamics and identify bottlenecks. If you’re missing a clarification from product or design, signal it, but also share some potential alternatives. Keep an eye on innovation and insights, connecting distinct ideas to bring fresh perspectives to the team.

Define clear goals for what you expect from meetings and documents. Remember, your career is guided by you, not just your manager. Prepare your 1:1 agendas in advance, and don’t focus solely on yourself—discuss the team and the direction of the product as well.

Deliver feedback to your peers with a focus on achieving the highest impact while reducing effort. In summary, your value grows beyond the features you deliver by contributing to the overall growth and efficiency of the team and product.

Am I Doing All That? Maybe…

This is my line of conduct. Similar to a PID system, sometimes we deviate, but the key is the ability to self-correct. I try not to fall into the fallacy of “I know everything already.” The more I learn, the more I realize how much I don’t know.

In the meantime, I keep reflecting and striving to grow. This continuous self-evaluation helps keep me grounded and open to new knowledge and improvement.

About Me Author

My name is

Guilherme Schwade

Development is much more than just coding. Read More

You May Also Like