I’ve been leading teams for a couple of years now and I often receive feedback from my direct reports that they’re either unsure on how best to contribute to team discussions, or they’re newer senior engineers and don’t understand the weight their voice carries in discussions. What you’ll find below are some examples of how you can use your voice to benefit the team regardless of your role, and a couple of pitfalls to watch out for as you become more senior.
An early career software developer - between 0 and 12 months experience.
Being a junior developer is an opportunity you only really get once. Question everything. Why are you using this framework over that one, what does that acronym mean, why is this thing important? These questions are expected and should be utilised to the fullest, for both your own benefit and that of you team. Just like a new joiner to a team (which you are as well as a junior developer) you have an unjaded viewpoint from which to objectively question any and all processes.
Honestly questioning existing processes and tools causes the team to reevaluate their choices up until now. Does this service/process/tool still provide value? Can I justify why this exists? Do I understand this thing enough to explain it to someone new? Anything that doesn’t have clear benefits or can’t be explained fully should be followed up on by the team later - either it’s no longer adding the value it once did, or there’s a gap in understanding that should be filled in.
A developer that has just changed team - any level of experience.
📢 Note: If you haven’t changed domain or looked for new opportunities in the last two years, this is a reminder to do so. You’ll benefit immensely from taking your experience and applying it to a new problem. Likewise, the problem you work on next will benefit from a new perspective and different experience. This often doesn’t need to be a job change, in fact you’ll often benefit from a rotation inside your current workplace.
Welcoming new members to a team is a great way of reevaluating the current stack and processes (see the previous section) as well as injecting a new viewpoint into discussions. You have the opportunity to input into discussions without carrying the baggage of previous work. “We tried that before and we can’t do this because of x”, “Vendor y doesn’t want to do z” etc. Things change, problems evolve, existing tools become obsolete and are replaced by new ones, so why not reevaluate some decisions that were made in that past.
This is your opportunity to ask questions of your new teammates, both to gain context on the decisions that have gone before and to challenge the status quo. Pairing with a member of the team on some of these opportunities is a great way to get to know your area of the business better and build bonds with the team.
As a senior developer your voice carries more weight than you might realise, especially if you've recently been promoted. Other members of the team will look to you for feedback on their ideas - both explicitly by asking for it, and implicitly by listening to how you react to the things they're talking about. Junior engineers may follow your lead without realising it as they learn what it means to be a software engineer. Before contributing to discussions you need to be aware of how your ideas are perceived.
In general, I encourage senior engineers to speak last. This helps to avoid anchoring bias and provide space for less senior engineers to voice their thoughts. It’s much easier for you to critique them than it is for them to critique you.
This isn’t to say you shouldn’t feel comfortable contributing to discussions first, you just need to pick your moments. If there is a decision you feel strongly about, or is potentially high impact, then that’s the time to use your influence to reinforce your point.