Over the years, I’ve learned that good engineering leadership rarely comes down to having all the answers. More often than not, it’s about creating trust, supporting team growth and building an environment where people can thrive.
In this article, I wanted to share a few principles that have helped me build healthier and more collaborative engineering teams. Some may sound obvious at face value, but sometimes going back to the basics is all that is required.
Get to know your team personally
You can make generalised assumptions of what you think is right for your team, but if you don’t even know your team, then how can you confidently make those assumptions? I have seen autocratic ideas implemented that destroyed a team’s morale just because decisions were made without any input from the team who were affected by those decisions. Getting to know everyone in your team, on a professional and personal level, is an imperative part of being a good leader. Understanding the people you support and what helps them succeed is a fundamental part of leadership. Good leadership is rooted in serce to the team around you.
Sometimes autopilot can drive your day-to-day, without stopping to question whether the decisions you make are actually right for the team around you. One professional goal I often encourage is for team members to contribute to a shared knowledge base through presentations or leading discussions. For many people, that’s a decent way to build up their confidence and give an opportunity to really deep-dive into a topic with the wider team.
It wasn’t until I happened to be chatting with the next speaker that they confided that they were dreading it. It wasn’t the topic itself, but the pressure of simply speaking in front of the whole practice was daunting. While public speaking can absolutely be valuable, I didn’t want anyone to feel uncomfortable or unsupported, so instead we explored a different way for them to contribute to the knowledge base: by creating an internal wiki for our team and writing about that topic there instead. Not only did that team member feel far more comfortable and suited them better, but it also opened up new opportunties for the team that I hadn’t considered before. Understanding the differences between your team helps you support them more effectively instead of assuming the same approach works for everyone.
My advice would be to introduce regular one-to-one’s with your team members, even if it’s just for a couple of minutes. Organise regular scheduled team meetings so your team can get to know each other as well. As soon as you feel like a team and not just a group of individuals, you can pull in the same direction together to meet the team’s goals.
Continuously look at opportunities for others to grow
This should be second-nature to leaders: constantly look for opportunities for your team to gain experience from, whether it be project-focused, personal or in an organisation-wide context. Is there a small task that needs doing? Great, see if someone in your team would benefit from doing that instead of you. Is there an important topic or bit of industry news worth sharing? Maybe someone else who needs a confidence boost can make the announcement instead. Giving someone else an opportunity to present themselves in the limelight, especially if the eyes of the bosses are watching, can change the course for someone’s career. One thing I’ve learned is that visibility matters: if nobody knows who you are or what you do, nobody knows why you should be promoted.
Using the information learned from talking to individual team members can give you insight into what opportunities will benefit each person on your team, especially if they have goals in mind. Making the effort to remember these will not only serve the individuals but the team as a whole.
Be open that you don’t know everything
Ever since I can remember, there has always been a touch of ego and gatekeeping in software engineering. I have seen communities where everyone is expected to know every single thing or they’re not a ‘real’ engineer. It can be an incredibly toxic place to be, created and sustained from insecurity. Not only does this become an internal psychological battle for some, but confidence breeds success, so without it your team is at a disadvantage.
I once had a chat with a junior report who said that they don’t feel comfortable asking our community for help because they were embarrassed to do so, fearing they would be judged for not knowing the answer to something. They also didn’t feel comfortable speaking in our internal web space because they wrongly perceived that they “couldn’t teach anything to anyone at a higher level”. As disappointed to hear that as I was, I have seen this a lot and even experienced it myself. I like to think anyone can learn anything from anyone, and I don’t like spaces where there are the seniors at the top of the tree create unnecessary hierarchy between themselves and the juniors. It’s a bit of a cliche, but asking for help shouldn’t be a weakness, it should be a sign of growth.
After all, everyone has something to contribute; the gatekeepers were juniors once themselves, so they should know better. Early in my career it was overwhelming to see how some people seemed to know everything and I felt that I knew barely anything in comparison, so nowadays I try to be the person I needed back then.
But what is the solution exactly? Given the opportunity, I always make a point to openly admit to other developers when there’s something I don’t know, or that I had to search something I had forgotten. Ask your team for advice, even if it’s just to clarify your own thoughts or it’s something you already know the answer to. Post things to your team that you’ve learned that week, somebody might see that and feel “oh, well maybe they don’t know everything!”. Imposter Syndrome is quite prevalent in our industry, showing that we experience it too helps others feel less of an imposter. Admitting it to ourselves shows that we still have a lot to learn too.
Embrace the difficult conversations
Uncomfortable conversations are an inevitable part of leadership. It’s about handling those conversations constructively, with care and respect, that makes a good leader. Sometimes protecting the team means pushing back on unrealistic expectations, addressing poor communication or helping someone improve. Sometimes these conversations are necessary for the good of the team and the project.
Many times have I been handed an impossible deadline or unrealistic expectations and stressed about how to handle the situation. In order to protect the team from any burnout or unnecessary stress, I have had to make difficult calls that I knew would not please everyone. But avoiding those conversations could potentially create bigger problems in the future.
Difficult conversations aren’t always about conflict, however, as they often come from a place of support and accountability. If communication is poor, expectations simply aren’t being met or someone on the team is struggling, it’s so important to address those early before they grow into something more serious. For the most part, the people affected would rather have those conversations too and accept honest, constructive feedback rather than continue with uncertainty.
Leadership ultimately involves discomfort at times, but handling the discomfort thoughtfully and respectfully is part of supporting the team around you.
Clarity builds confidence
Ambiguity is confusing, unproductive, and in some cases, dangerous. Speaking from experience, poorly-defined requirements can be interpreted wildly differently and add unnecessary risk to a project’s delivery.
One of the most important parts of leadership is creating clarity. Leaders often act as the connector between different spaces on a project; without clear communication in those spaces, misunderstandings and uncertainty can quickly begin to grow. Clear expectations help people work with confidence. When priorities and responsibilities are vague, teams can waste their energy second-guessing decisions instead of focusing on doing the work itself.
This is why strong technical leadership is so vital during planning and delivery. Technical leads should play an active role in refining and validating work before any implementation begins. The requirements themselves need to be clear and consistent, whereas code standards and documentation should also establish a shared vision across the technical team. Healthy codebases and clearly-defined responsibilities will reduce confusion and help teams collaborate more effectively.
The more context and understanding a team has of the project goals, the better equipped they are to make good decisions, communicate effectively and deliver quality work together.
Conclusion
Most of my points can be boiled down to “have good communication”. Without it, we find ourselves in the same traps: unclear expectations, misunderstandings or a lack of knowledge.
Leadership can be complicatedm but one of the simplest pieces of advice I’ve ever received was to lead by example. Successful teams are shaped not just by processes and documentation, but ultimately by displaying the behaviours leaders show every day.
