Most engineers believe technical leadership is about having the best answer. It’s not. It’s about knowing which questions deserve an answer at all, deciding swiftly when they do, and having the humility to admit when you got it wrong.
After more than a decade observing some of the best software leaders in Australia and spending the last 4 years practicing as one myself, I’ve picked the top 3 skills I think all great leaders need and all aspiring leaders should cultivate.
Filtering Noise
The best leaders I have seen are the ones that somehow know the difference between the noise and signal within their domain and organisation. Both sides of the equation are critically important when it comes to focusing teams. Why? Because humans are inherently limited in the capacity they have for cognitive load and there is far more noise out there than there is signal. As a leader it’s critical to know what your people are not doing so that they can focus on what they are doing.
Let’s use a hypothetical situation. A senior engineer has come to you with an escalation, two team members disagree on the boundaries of a system they are building, one engineer believes 2 microservices are needed while the other believes there are 3. You know that the team is building the first version of this product feature to be launched to 100 customers and that there is a deadline that is looming in 2 months that is business critical. You also know that microservices are cheap to spin up in this organisation. That already makes this decision noise, it doesn’t make a material difference to the functionality how the microservices are structured and the proposed initial scale means that any architecture will be fine, it would be pointless to spin up days of discussion over this to go through technical specs and the pros and cons of each approach. So what can you do as the arbiter of this decision? Your options are:
Look at each option, assess the pros and cons of each together with the engineers and pick one based on the best weighted components
Introduce a third option for a single microservice and explain why it’s the best option, convince both engineers that this is the way.
Pick one option, convince the opposing engineer.
Hopefully at this point, The 3rd approach is the obvious answer; it’s the one that eliminates the noise the quickest and brings the team back to focus.
While completely contrived. I hope this illustrates how a leader uses constraints and context to eliminate noise for the team. Imagine instead if you had decided this was a decision worth diving into and understanding in full depth. You could have possibly wasted weeks deciding something that is non-consequential for the intended scale. Noise often comes in the form of decisions or questions asked, if you’re an effective leader you will know that when they show up, you will either need to make the decision swiftly or if a question, put it to the side and answer it later (if at all).
Decisiveness
Decisiveness follows on from Signal vs Noise. The best leaders I know are able to make decisions quickly with incomplete information and stick to them when challenged by noise.
What does this look like concretely?
Let’s say you’ve made that decision to build 2 microservices instead of 3. An engineer outside your team finds the decision record and brings up that this means the module that would have been the 3rd microservice can no longer be seperately scaled horizontally. The theoretical maximum scale for this service is only 100,000 customers due to this scaling limitation. While factually true, this should not change the decision as we already know that the feature will not need to scale passed 100 customers for the first launch. An indecisive leader would re-open the decision and re-consider the architecture, a decisive leader knows that a comment like that is likely lacking context and stands their ground, protecting the team from the noise; the likely action there is a nicely worded comment detailing the constraints that have already been considered. This of course is balanced by signal, if the comment instead raised an issue with scaling passed 50 customers, you know this is something you have to address properly because it impacts the launch.
Humility
Leaders are people and they can be wrong too, when this happens the worst thing you can do is to pretend you are still right. Though counter intuitive, owning mistakes is one of the best ways to earn trust, trying to pull the wool over everyone’s eyes is the best way to lose it, being overly defensive is probably the worst thing you can do.
It’s launch day in 1 week, you’ve done some performance testing and at simulation of the 99th customer, your services fall over. It is the 3rd module and having that module separated out would have allowed you to scale it out without making the other modules significantly more expensive. Your response options are:
2 services is the golden architecture, keep this and scale out the second one so that it can take the load. We can pay the money.
3 services is the way to go, we made an assumption in the beginning that turned out not to be true after testing. Let’s scale out for launch and re-architect afterwards.
3 services is the way to go, we made an assumption in the beginning that turned out not to be true after testing. Delay the launch until we have the perfect architecture.
3 services is the way to go, we made an assumption in the beginning that turned out not to be true after testing. Let’s launch to 50 customers instead.
The way you own mistakes matter too. I hope it is obvious which of these example responses is best. The first is the obviously wrong one (which I have placed there almost as a plant). You are likely to be deciding between the last three options and each of them de-prioritises one of scope, cost and velocity. Which one you choose is contextual and depends on which one of the three is more acceptable, but each one of those three admits the mistake made and proposes an action plan. These two components are critical to owning a mistake, you need an action plan to be taken seriously.
These three skills, filtering noise, deciding decisively, and owning mistakes, don’t exist in isolation. They reinforce each other. Noise filtering gives you the clarity to decide quickly. Decisiveness gives your team the stability to execute. And humility gives them the trust to follow you when things go wrong, because they know you’ll course-correct rather than double down. If you cultivate nothing else, cultivate these.
While I’ve written about these skills in the context of software engineering teams, I believe they are broadly applicable to leadership in contexts outside of the technical. I hope they serve you well if you are in or are pursuing a leadership role at any level.