Doing the work isn't the only way to add value

 So you think you can lead a team?

I’ve been talking and writing a lot about leading a software engineering team in 2025. I started thinking about it more deeply the year before when I decided to give a colleague, who was moving into team leading, some advice:

• 'Doing the work' isn't the only way to add value
• Remember to delegate
• Pick your battles
• Talk to your team every day

Out of this came a talk, “So you think you can lead a team?” which I gave at work, at meetups and at conferences in various different formats during the first quarter of 2025. I am also turning these ideas, and more, into a book I hope to release towards the end of 2025. 

I’ve already explored delegation, you can read about it here: 

https://paulgrenyer.blogspot.com/2025/04/remember-to-delegate-triangle-of-trust.html 

Seeing the Bigger Picture, you can read about that here:

https://paulgrenyer.blogspot.com/2025/05/see-bigger-picture-and-look-around.html

And Picking Your Battles, which can read about here:

https://paulgrenyer.blogspot.com/2025/06/pick-your-disagreements.html

Doing the Work Isn’t the Only Way To Add Value was the first piece of advice I gave as it was foremost in my mind at the time. As I look back at that time now, I realise that I myself still wasn’t comfortable with how little code I was writing. The experience I’ve had since then, as well as the team leading presentations and writing I’ve done since, has helped me get comfortable with it now.

How do you get satisfaction?

As software engineers, many of us feel we are better at solving problems with software than anything else. That feeling often goes deeper than the value bestowed on us by an organisation we work for. There's something personally satisfying, even identity affirming, about creating elegant solutions, shipping features, or untangling a nasty bug. It’s not just what we do well, doing the work makes us feel satisfied. My friend and colleague Hoyt explained this to me once:

Out of all the work I've done, the thing I'm most proud of was a little widget that displays some account information. It was laughably easy to implement, but I was instantly able to see the value it brought to people.

For the first few months, possibly even a year, of what I consider to be my first true team leading role, I felt discomfort, even guilt, when I wasn’t working on a feature or a bug fix my team was responsible for. On the surface it was guilt that I wasn’t doing what was expected of me. It eventually became apparent that doing this sort of work directly was not my responsibility. Then I realised my need for personal satisfaction wasn’t being met.

Finding meaning in the work that I do is important to me, and I expect it is to you. I think it’s important to understand where that feeling of purpose and reward comes from. This is how it is for me.

When I was about eight years old (1985) my parents bought an Acorn Electron (a home computer). All my friends had ZX Spectrums, so I couldn’t swap games with them and I only had the handful which came with the Electron. In those days games and other software were loaded from cassette tape and took minutes. I’ve always been impatient and minutes was too long to wait as a child. One day my dad came home from work and showed me how to write a few lines of BBC Basic and from that point on it was going to be writing programs for me, not playing games. Creating programs gave me a sense of satisfaction I hadn’t felt waiting for those slow loading games.

Fast forward a few years and I’m in my early teens and the Acorn Electron has been replaced with a BBC Master. It had a 5¼ inch floppy disk drive, so patience was no longer such an issue. My friends were doing interesting things with Amigas and Commodore 64s. I was still writing programs, but they were starting to lose their appeal. With it went the sense of purpose I’d been getting from writing them as I realised no one was ever going to use them.

A few years later I’m doing my A-Levels, the BBC Master has gone and we have a PC. I’m not writing programs anymore, as C was all that was available to me and it felt too daunting to learn by myself (I think really I was too impatient to take the time). I couldn’t see how to do anything interesting with it. What I wanted to do was write Windows applications, but that steep learning curve wouldn’t come for a few more years. Ultimately, I felt I couldn’t create anything useful. The disconnect from that feeling of making something meaningful, led me to choose to study Electronic Engineering over Computer Science at university.

Fortunately there is a lot of programming in C in an Electronic Engineering degree and I found I was good at it. Those years of BBC Basic had taught me the fundamentals of computer programming. My final year project was to design and build some control software for a simple CCTV system. I had a real world problem to solve with software, and with it came that familiar feeling of satisfaction. I loved building something useful.

My first role out of university was with a small engineering firm in Sheffield who produced marking machinery, which was controlled with software. While I was there, I only completed one project where I solved the problem from start to finish, but I contributed to a few. It took months for me to realise the software I was building wasn’t just for fun anymore. It was expected to add value (I was being paid to add value) and when it did, I started to reconnect with that familiar sense of satisfaction I’d first found as a child with a blinking cursor and a blank screen. That shift made me want to improve, to push myself, and to become the best I could be.

It wasn’t until my second role, where there was an in-house team using the software I designed and built to process data and produce physical mailshots, that I started to really see and feel satisfaction from the software I was building. By that point I was hooked, not just on solving problems, but on that feeling that what I built mattered. I’d realised that the value my software created for others was directly tied to the satisfaction I felt in myself.

For most of the next decade and a half my job and my satisfaction were defined by the problems I solved by building software. It became intrinsic to me, part of who I was and I never wanted it to stop.

Then I became a  team lead.

I’d led teams before, but my role was mostly that of a senior engineer with some responsibility for the team. Even when I ran my own business, my main activity was always solving problems by designing and building software. I was in my comfort zone. That changed when I started my first proper team leading role.

A Software Engineering Team Lead’s Value

When I first stepped into a full-time team lead role, I wasn’t sure how I’d be measured. I wasn’t shipping features, squashing bugs, or designing systems, at least not in the way I used to. 

To understand a software engineering team lead’s value, I asked key stakeholders including Product Managers, Software Engineers, and Senior Managers, all of whose roles are closely connected to the team lead’s role, to describe the value a team lead brings beyond building software. Their answers were varied, but the themes were clear, and they helped me reframe how I thought about software team leadership, my importance, and made a paradigm shift in how I felt satisfied.

Technical Guidance 

Team leads bring value by setting technical direction, offering architectural guidance, and ensuring engineers produce robust and maintainable software which meets their client’s needs. They make decisive calls during complex or critical situations and guide library and tool choices. Their technical insight and decision making ability become even more valuable when the team is composed of junior engineers or when facing ambiguous or complex challenges.

“A Team Lead creates balance in the team, bringing clarity and technical expertise to situations”
Uzma Ali - Engineer

Context

Team leads add enormous value by being the bridge between product and engineering. They are able to help form and give feedback on the “what”, and guide the team to translate it into the “how” and to understand the “why”.  Their ability to apply the bigger picture helps their team understand the context they’re working in. Their role in facilitating discussions and translating between business, design, and technical stakeholders fosters better solutions and creates an environment of respect and understanding.

“I value Team Leads that enrich their own context and that of the team. They do this best by asking the questions that bridge the gap between product, business, and tech.”
John Musk - Product Director

Culture, Mentoring & Wellbeing

Team leads add value by supporting the growth, cohesion, and wellbeing of the team. They mentor engineers, provide constructive feedback, and help individuals take ownership. At the same time, they shape how the team collaborates, communicates, and works together. They promote psychological safety, trust, and a healthy team dynamic.

By recognising individual strengths and fostering open discussion, they enable the team to thrive, not just in delivery, but in morale and sustainable growth.

“Team leading is looking out for the health and wellbeing of the systems and team members. Especially when they start acting up.”
Jon Moore - Team Lead

Product and Business Delivery

Team leads are the right hand of Product Managers. While PMs define "what" needs to be built, team leads often drive "how" it will be built and support refining the "why." Their involvement from discovery through delivery makes them invaluable in aligning roadmap planning with technical feasibility. Together, they form a partnership that balances user needs, technical realities, and business priorities. Ultimately they ensure the team builds the right thing, the right way.

"Team leads are a huge asset to Product Managers. Whilst team leads primarily drive the 'how', they also help and support the Product Manager with the 'what' and the 'why'."
Katie McGeehan - Product manager

Efficiency & Focus

Team leads add value by enabling the team to focus and deliver efficiently. They unblock issues, facilitate communication, and drive better decision-making. They standardise practices, identify inefficiencies, and promote knowledge sharing, improving both speed and quality.

"Leads and manages the technical team providing clarity, priorities and communication to align team focus."

Uday Patel - Product Manager

Role Models

Team leads are role models. They're respected for their experience, clarity, and calmness under pressure. They lead by example, showing integrity, fairness, and humility. They guide the team through change and uncertainty, and their influence stretches beyond delivery to the overall wellbeing and long term growth of individuals and the team. They create the kind of environment where people want to stay, grow, and do their best work.

"...I personally learned a lot from my team leads, they've been role models for me."
Uzma Ali - Engineer

Another aspect that stood out was the importance of shielding the team. That kind of protection isn’t just a nice-to-have, it’s a key part of enabling the environment where great work can happen and deserves closer inspection.

Shielding the Team

A team won’t get far if they can’t focus. They can’t focus unless they’re shielded from most of the external actors and forces that would disrupt them. It’s not that the external actors are malevolent in any way, at least not usually, but things change and things happen. 

As one colleague put it, being a team lead is:

“...being a shit deflector."
 Phil Wiltsher - Team Lead 

If you’re going to shield your team to allow them to focus, it is vital that you understand the bigger picture so that you know what to deflect and what to let through. Let’s have a look at some of the things which might come your way.

Change is inevitable. Requirements change as people change their minds or learn new things. The Waterfall model was designed to capture all changes upfront. That’s impossible for anything but the most trivial of systems. Agile methodologies like Extreme Programming and Scrum were designed to embrace change, but still create periods of uninterrupted focus with iterations and scrums. Even Kanban provides focus throughout the time it takes to complete a feature or fix a bug.  

Software is complex, so mistakes or something unforeseen can easily create bugs and sometimes those bugs get into production. Sometimes those bugs can be lived with for a short period of time or maybe even forever, but equally, some bugs bring down entire systems or result in too much financial loss and have to be fixed straight away.

Then there are the 'Can you just…?' requests: well-intentioned ideas that sound quick and aim to save money or drive revenue. In practice, these often take more effort than expected, especially when the complexity isn’t fully understood by those making the request. While some do deliver value, the return doesn't always match the original estimate.

Engineering teams are often pulled into organisational activities, such as training, meetings, or other activities, that may not align with their work or priorities. While well intentioned, these activities can dilute focus, and reduce engineering effectiveness. Protecting engineers’ time and ensuring relevance is critical to maintaining momentum, technical quality, and team morale.

Whether it's changes in requirements, bugs, unexpected quick wins or activities unrelated to engineering, the team lead needs to decide which should disrupt the team’s focus, which are a new ticket for the backlog and which they should do themselves. Don’t underestimate your ability to keep stakeholders happy and your team focused. Sometimes, picking up a few tasks yourself can make all the difference. There are no hard and fast rules. It comes down to your own experience and judgement.


Team leads are far more than technical contributors. By setting direction, bridging domains, mentoring individuals, and shaping a culture of wellbeing and trust, they create the conditions for great engineering. They motivate their teams and reinforce a shared sense of purpose and value. They shield their teams allowing them to maintain focus, support honest dialogue, and enable people to take ownership confidently. Their influence may not always be loud, but it is foundational to a team’s success.

These stakeholders in team leadership reveal how deeply team leads shape not just what gets built, but how it gets built. The role is essential for creating resilient, high-performing teams where people can do their best work and grow. 

As well as building soft skills, it is important for a team lead to maintain their technical skills. Let's take a look at how we might do that.

Staying Relevant

While all aspects of leading a software team identified by the stakeholders are important, technical guidance is the most important.  Staying technically relevant not only builds credibility and self confidence as a leader, but also sharpens your ability to make sound decisions and catch potential issues early. 

The team lead is accountable for the team’s primary responsibility: solving problems through building software. To do this effectively, the lead must listen to the team and apply their own experience and judgment to guide the team toward the right decisions. Staying effective also requires the lead to continually grow and maintain their technical skills.

But how? 

How you like to stay relevant and what opportunities are available to you will vary. These are some of the things which work for me:

Review Code

Your team should be reviewing and approving each other's code, so that you’re not a bottleneck. However, make sure that you review as much of the code as you can as often as you can. This might be via pull requests, sitting in on some pair programming or some other method. Review another team’s code when appropriate. Look at as much code you can.

This keeps your mind thinking about code and working with code. Something that often happens for me is that one of my team will use a part of the language, a library, a pattern or a style I’m not familiar with and this gives me the opportunity to look it up or ask them about it and learn. Code review is also a great chance for the whole team to learn, not just about tools or techniques, but to build shared context and avoid the risk of critical knowledge living with just one person.

Build Features and Fix Bugs

Why should your team have all the fun? From time to time pick up a new feature, bug fix or a maintenance task, like reducing or improving logging or improving the build system or a pipeline. It helps keep your hand in and writing, refactoring or otherwise modifying code is a more effective way of staying familiar with a code base than just reviewing the code. Make sure you get your team to review your changes.

As team lead you’re often pulled in all sorts of directions, so committing to large features or bug fixes should be avoided. You don’t want to hinder your team because you’ve committed to something you’re unable to finish in a reasonable time.

Architecture

As team lead you, more than anyone in your team, need to understand how the systems you’re accountable for hang together. Hopefully you have one or more up and coming senior engineers who can create an architecture diagram for new systems or significant enhancements to existing systems that you can review iteratively together until they’re right. If not, it’s important that you create the architecture and explain it to the team. That understanding puts you in a position to challenge assumptions, avoid potential pitfalls, and help the team think about how their work fits into the bigger picture.

Talk to other Engineers and Lead Engineers

Without a doubt the engineers around you in your organisation and the wider industry will be doing interesting things. Team leads will also be doing interesting team lead things: new processes, learning about new ways to relate to the people in their team, writing a book or an interesting mobile or infrastructure project - all sorts of things! Speak to them regularly. In at least one of the organisations I’ve worked for, the team leads got together once a week to discuss what they’d been? doing and the engineers gave Listen and Learn sessions where they talked about interesting technical things they’d been doing.

Meetups and Conferences

Keep an open mind to learning new things. Attend local meetups, large and small conferences, vendor events like AWS or DataDog summits and workshops and learn about what other people are doing and what interesting things you might be able to apply within your team or the wider organisation. 

One of the things I like most about the (London) AWS Summit is the free access to all of their learning material and I always put some time aside while I’m there (last time three hours!) to learn how to use services I’m not familiar with. 

One of the best ways to reinforce and expand your learning about something is to explain it to another person. This could be verbally, through writing papers or a blog, or by preparing and giving presentations. I like to have one or more different presentations I can give each year and try to give them at as many meetups and conferences as I can.

Learn New Things

From time to time, probably all the time, there’ll be things you’re interested in or feel you’re not strong enough in. For me, that’s been Terraform. I’ve always found it fascinating, but having worked in two organisations with dedicated platform teams, I rarely had the chance to put it into practice myself. Similarly, I’ve always leaned heavily towards the backend, so my HTML and CSS skills aren’t where I’d like them to be.

Because I was genuinely interested in both, I put aside time during the day and in my own time to learn more about both. I leaned on the experts around me who were generous with their time and encouragement. Platform engineers explained why my Terraform didn’t work as I thought it would. A designer created a design I could try to replicate in HTML and CSS. Frontend engineers helped steer me when I got stuck.

Learn in whatever way works for you. That could be from podcasts, social media, YouTube, books and more. It doesn’t matter where it’s from, just learn! And enlist those around you to help.

Personal Projects and Side Projects

I have found that having a side project and/or a personal project is the most effective way of maintaining my existing technical skills and learning new ones. I see a side project as something which lives in a context outside of your team's area of responsibility. For example, I have written messaging libraries, email lambdas and a PDF generation service which were all used by multiple teams in my organisation, but didn't belong to any specific team. A personal project is one that you do outside of work and belongs to you. In the past I have written testing libraries, clients for APIs and even an app and associated infrastructure for finding cafes with great tea.

In these types of projects you’re usually doing everything: the infrastructure, the build system, the pipeline, the backend code, the front end code, the mobile app, etc. So the experience you’re gaining is both broad and deep.

The real benefit here for me, especially in the times when I was struggling with not building software myself, is getting back the feeling of satisfaction. I have a personal library project which wraps an API and is used by a side project which processes millions of messages and sends millions of emails a year. It’s a vital component in the organisation and makes me feel important.

Technical guidance is the most important aspect of a team lead’s role within the team, but shielding the team comes a very close second. 

But what does this have to do with satisfaction? 

Getting The Satisfaction

When you progress from engineer to team lead, you will find your sources of satisfaction begin to shift. Where once the thrill came from building software, new forms of fulfillment emerge. These are often rooted in people, process, and purpose. This transition isn’t always immediate or intuitive. It can feel awkward at first, like learning a new language, but over time you will adapt, and satisfaction begins to come from different kinds of achievement.

One of the most powerful changes is the joy of helping and seeing others succeed. Supporting a colleague’s growth, unlocking someone’s potential, or seeing a team overcome a challenge can offer a deeper and more lasting sense of impact than individual coding victories. The endorphin rush that once came from fixing a bug is replaced by the pride of building a culture, mentoring others, or shaping the direction of a product or team.

You will also feel a shift in perspective from contributing solutions to shaping the problems worth solving. Being a team lead brings earlier involvement in decision making, greater influence over priorities, and the opportunity to contribute strategically rather than tactically. This broader view can be intellectually stimulating and creatively rewarding in its own right.

At the same time, becoming a team lead can introduce a more complex emotional landscape. Feelings of imposter syndrome, fear of failure, or the constant need for recognition can all come into play. Satisfaction becomes more dependent on relationships, perception, and team dynamics. The rewards are often less immediate, but when they come, for example when a team becomes cohesive, a difficult problem is solved, or a culture begins to thrive, they’re profound.

Feeling Important

In How To Win Friends and Influence People, Dale Carnegie, paraphrases the American philosopher John Dewey, telling us that the deepest urge in human nature is the desire ‘to feel important’. This leads to his second principle in the second section of his book: ‘Give honest and sincere appreciation’. Of course, it is to our team and those we work with that we give our appreciation to. When we, as team leads, provide value to stakeholders, and they demonstrate their sincere appreciation, we feel important and, I believe, get the ultimate satisfaction. 

People need to feel important. When I was building software and solving problems I felt important. The turning point for me came when I learned that the things I do as team lead are valuable too, and now that makes me feel even more important. 

Before I started my first proper role as a team lead, I was looking for senior engineer roles and one of the heads of engineering at the organisation asked me to join as a software engineering team lead. They’d seemed very keen and I’d always wondered why so one day I asked them. They told me that they’d seen me speak at an event and thought that I would add value to the organisation as a team lead. This made me feel very important and remembering it still brings a smile to my face.

This is how it is for me, but it may be different for you. Either way, I would urge you to try and feel satisfaction when you receive sincere praise for adding value.

Ultimately, the journey to team lead is not about leaving satisfaction behind, it’s about making a paradigm shift and finding satisfaction in a role which varies far more broadly. Satisfaction also comes from feeling important. That feeling will come and you need to look out for it and understand where it comes from.

Finally

Satisfaction in software engineering often starts with building things, solving tough problems, shipping great code. But when you step into leadership, your sources of satisfaction shift. You're no longer just building software, you're building people, culture, teams, and outcomes.

And while that shift can feel difficult at first, in time you’ll come to see that helping others grow, shaping a culture of trust, and being a steady hand through uncertainty can be even more rewarding than a beautifully written algorithm.

Eventually, you’ll feel it: that same spark of satisfaction, only deeper and more lasting. When your team succeeds, when someone you’ve mentored thrives, when a challenge is overcome not by you, but because of you.

That’s the turning point. Don’t miss it. When it comes, take a moment to enjoy it. You’ve earned it.

Bibliography

So you think you can lead a team?: The Reading List 

Thanks

For this chapter especially I have had to lean on a lot of people. I really couldn’t have done it without them:

Phil Chambers
Chris Cheshire
Steve Cresswell
Dom Davis
Laurent Douchy
Harvey Gwynn
John Hegarty
Will Johnston
Alex Leslie
Marco Mark
Brian Milton
Chris Oldwood
Gail Ollis
Akshatha Rao
Hoyt
Nayana Solanki
Ben Stirling 
Phil Wiltsher

Research

Thank you also to my stakeholders who provided such great material to work with.

Uzma Ali
Michael Brinsden
Phil Chambers
Steve Cresswell
Kirsty Cox
Dom Davis
Laurent Douchy
Cindy Fung
Dan Grainger
Laura Goldberg
Jay Gould
Stephen Harris
Clarisse Honore Menvielle
Katie McGeehan
Maxy Maxwell
John Musk
Hoyt
Nayana Solanki
Chris Stanlake
Dafydd Thomas
Robert Torzsok
Shawn Wilson