See the Bigger Picture and Look Around the Corner

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 and you can read about it here: https://paulgrenyer.blogspot.com/2025/04/remember-to-delegate-triangle-of-trust.html

Earlier this year, a senior engineer on my team was deeply focused on solving a problem, but it wasn’t the right problem to be solving. Instead of asking how to solve it, they should have been asking why we were solving it in the first place. After a conversation where we looked more broadly at the situation, they realised they needed to push back more. They then asked me how I knew when to push back. I told them it’s because I was looking at the bigger picture and around the corner.

The Bigger Picture and Looking Around The Corner

Engineers at all levels, even experienced ones, can often be guilty of only seeing the work they do in the narrow scope of the tasks placed in front of them. While most are perfectly capable, they don’t always consider the bigger picture and remember to look around the corner. This often falls to the team lead and those above them. One of my senior engineers has an interesting take on this:

I think engineers often lack the skills to make practical decisions, focusing instead on finding the perfect solution. They need to look for practical solutions that work within the realities of the team’s current capabilities and constraints. They may not be the 'perfect' solution, but they’re effective and deliver results quickly. They also keep things moving forward, maintaining momentum. - Nayana Solanki

It is your responsibility as team lead to make sure you have the bigger picture and know what’s coming around the corner, and where possible, make sure you pass it onto your engineers. If you don’t manage to pass it on in advance, make sure you are in a position to redirect an engineer should they need it. Let’s take a closer look at the bigger picture and what it means to look around the corner, defining each and demonstrating the difference with examples.

Seeing the Bigger Picture

Seeing the bigger picture is about understanding the broader context and how it affects the immediate context.

The work an engineer is doing next is their Immediate Context. When they look at it they need to consider what is happening, and why it is happening, in their team, the other teams they work with and the wider organisation. This is the Bigger Picture and the Broader Context. It can change what, how, when and even if the engineer completes the work currently in front of them. It helps them understand the impact it will have and aligns them with the wider organisation's needs. Let me explain this with a real example (the names have been changed to protect the innocent).

The Engineer and the Imaging System

One day an imaging system stopped displaying images. An engineer from the team responsible for looking after the imaging system, which was no longer under active development and in maintenance mode, was tasked with finding out why. They were an excellent engineer and familiar with the imaging system, and soon discovered the images weren’t displaying as some metadata was no longer coming from a third party system.

The engineer spoke to the maintainers of the third party system who told them that they had been looking at the data in their system to find out which was needed and which wasn’t. They couldn’t find anyone using the image metadata so they had stopped importing it and storing it in their system. They also said that the engineer shouldn’t worry as they could just go to the source system and get the metadata directly. The engineer thanked them for being so helpful.

There were still a few hours left in the day, so the engineer set about learning how to get the image metadata from the source system. It turns out that the source system was a type of database that the imaging system didn’t already use. A whole new set of libraries would need to be added to the imaging system and a lot of code changes made to map and use the data. The engineer could see that it was a lot of work, but they were confident it could be done. It was the end of the day by now, so the engineer resolved to discuss the new integration in the team’s standup meeting the following day.

The next day in standup, the engineer explained what they had learned and what they planned to do. The team lead, who was a very experienced and handsome person, looked a little perplexed. They asked the engineer to remind them, “isn’t the imaging service in maintenance mode?” The engineer said that it was. “...and doesn’t that mean we shouldn’t be making changes unless they are necessary to keep the system running?” The engineer confirmed this was the case. The team lead agreed with the engineer that they would discuss the problem together after the standup.

After the standup, the team lead and the engineer went over all the details together. The team lead asked the engineer what they thought would be the best solution, given that they shouldn’t be making major changes to the imaging service. The engineer thought for a bit and explained that the best thing would be for the data to be back in the third party system. “Exactly!” said the team lead, who also had a particularly nice beard. They discussed it some more and realised that the way to make that happen was to ask the maintainers of the third party system to reinstate the import. This would fix the imaging system without any code changes. The imaging system wouldn’t have extra sets of libraries to maintain or be exposed to a potentially brittle new database. Plus the third party system maintainers should have checked more thoroughly before removing the metadata.

In the example of The Engineer and the Imaging System, the engineer was focused on the problem and the advice given by the maintainers of the third party system. Once they had a viable solution, they didn’t stop to ask themselves if it was the right solution, they didn’t consider the Bigger Picture. However, they did include what they intended to do in their update in the next stand up, which gave the team lead the chance to step in with a course correction.

If you have read Remember to Delegate: The Triangle of Trust then you might recognise this as an example of the third rule from The One Minute Manager Meets the Monkey:

Rule 3: Insure the Monkey: Every monkey leaving your presence on the back of one of your people must be covered by one of two insurances:

1. Recommend, then act
2. Act, then advise.

In the example, the lead engineer waited for the engineer to Act, before they Advised.  Suggesting a course of action, such as reminding the engineer that the imaging service was in maintenance mode and advising against major changes, might have helped them reach the right solution more quickly. That would be an example of Recommend, then act.

Looking Around the Corner

Looking around the corner is about understanding what is going to happen in the future and how it affects the immediate context.

As we’ve already established, the work an engineer is doing next is their Immediate Context. Looking Around the Corner means knowing what’s coming and why, for your team, for others, and for the wider organisation. It is subtly different from the Bigger Picture as it concerns future contexts, rather than the immediate contexts. It can change what, how, when and even if the engineer completes the work currently in front of them. It helps them understand the impact it will have now and in the future. Let me explain this with a real example, (again, the names have been changed to protect the innocent).

The Enthusiastic Engineer and the Payment Form

One day an enthusiastic and very capable engineer joined the team. One of the first tasks they were given was to fix a bug in a payment form. The payment form was used in two different places and had two separate integrations which did much the same thing.

When they had completed the bug fix, the enthusiastic engineer demonstrated it to the rest of the team in the team’s standup. The team closely followed The Triangle of Trust, so they knew how important it was to demonstrate new features and bug fixes to ensure they solved the intended problem. The enthusiastic engineer was also an excellent engineer, so they were able to demonstrate to the team that they had fixed the bug successfully. The team was very happy, so they signed off the bug fix and scheduled it for release.

There was nothing more to sign off, so the team lead moved to end the standup. However, the enthusiastic engineer interrupted and told the team they had some ideas to discuss. They went on to explain how they had found that the payment form was used in two different places and that the integration was much the same in both places, but the code was separate. The enthusiastic engineer was really getting into their stride now, especially as the team was listening with interest. Duplicate code, the enthusiastic engineer reminded the team, is bad as when it has to be changed, it has to be changed in two places, meaning twice the work, twice the testing and twice the opportunity for introducing more bugs.

The lead engineer was reminded of something that the enthusiastic engineer also knew, but appeared to have forgotten. However, the whole team was engaged and there were some useful learnings coming out of the discussion so they let it run its course. By then the enthusiastic engineer had outlined the problem well and explained how they would like to consolidate the code. The whole team was in agreement and there was a real buzz about making the code easier to maintain.

The team lead, whose beard didn’t seem so nice that day, thanked the enthusiastic engineer for initiating the discussion and engaging the team. The team lead then gently reminded the enthusiastic engineer, and the team, that another team was building a new payment service, which the whole company would integrate with, before the end of the year. This would make the payment form and its duplicated interactions redundant.  While the work could be done to make the maintenance of the code easier, it would be wasted work as it was unlikely to be changed much before it was replaced.

The enthusiastic engineer was disappointed, but did remember that the payment service was coming. In their enthusiasm to improve things for the team, they had forgotten to look around the corner to see what was coming up.

In the example of The Enthusiastic Engineer and the Payment Form, the engineer was focused on improving the maintainability of some code. They knew exactly how to do it, but they had forgotten to look around the corner to see if it was the right thing to do now. However they discussed it with their team, which gave the team lead the opportunity to remind them that they did really know what was coming around the corner, and provided the team with an interesting and beneficial conversation.

I believe one of my senior engineers summed up the context well when they told me:

From an engineer's point of view, it might be the right and long-term solution, but when part of a system is being replaced, the decision often leans toward feasibility and maintainability over perfection. If a system is in maintenance mode for a couple of months, you likely won’t have time to implement and stabilise a long-term solution. The main thing to note is that context changes everything when it comes to the 'right' solution. It's not about choosing the perfect solution, but about implementing the feasible, stable solution that doesn’t introduce new unknowns. - Nayana Solanki

The example of The Engineer and the Imaging System and the example of The Enthusiastic Engineer and the Payment Form demonstrate what the Bigger Picture is and what the advantage of Looking Around the Corner is. Even ChatGPT agrees they are important:

When we talk about good engineering practices, it’s easy to focus only on what’s technically right — refactoring code, removing duplication, improving maintainability. But in the real world, context often reshapes what the "right" solution looks like. Sometimes, the best technical answer isn't the best business answer. - ChatGPT

But how do team leads, engineers and others learn to see the Bigger Picture and Look Around Corners? Let’s finish up by examining that.

How to see the Bigger Picture and Look Around Corners

One day I found myself wondering how it is that team leads often see the big picture and around corners when some engineers do not. I spent a while thinking about it and chatted it through with another engineer. I have known them for many years and they had been a team lead in a number of organisations previously. They immediately pointed out that one of the differences between us and most engineers was that we had run our own small businesses.

When you run your own small business you have a vested interest in the outcome of the work. You have an incentive, which is more than just accountability, to see the bigger picture and around corners to ensure that the outcome of the work provides what is necessary for the business. This is usually making enough money to pay your employees, yourself, your suppliers and the business’ taxes. There is also reputational risk and emotional investment in the outcome. All of these, and more, add up to a massive incentive to see the bigger picture and around corners. Often this becomes habit forming and builds a desire to always see the big picture and look around corners.

It is not reasonable or practical to expect engineers to have run their own business, although it is not unusual for them to have worked in a startup or a scale up, which can provide  the relevant experience. It is reasonable to expect them to see the big picture and around corners though. Often the right environment and opportunities need to be provided for them to do so.

As software engineers we are used to being given tasks which we are responsible for completing. Usually we have a set of requirements which explain the feature to build or the problem to fix. This can range from a one line user story, to a full description with a set of acceptance criteria and possibly even some implementation steps, to a description of a problem and an indication of where to start looking and/or details of any prior investigation. Any one of these, especially the one line user story, may require a discussion with one or more people to flesh out the requirement or understand the problem. The requirement may even include a list of people to talk to (ours do).

Even when discussions are required to get a better understanding of the feature or problem, engineers are usually still asking what do I need to do?, when they should also be asking:

• Should I be doing this?
• Does it fit with the goals, objectives and vision of the team and the wider organisation?
• Does it fit with what is happening in future with the team and the wider organisation?

Asking these questions is only part of the solution to getting engineers to see the bigger picture and around corners. They need to be able to answer those questions. They cannot do this in a vacuum. This is where creating the right environment and opportunities comes in. As a team lead, two ways you can do this are by explaining the organisation's needs and by explaining who to talk to and why.

Be in the Room

In Staff Engineer: Leadership Beyond the Management Track, Will Larson describes how senior engineers wanting to become team leads should learn how to “get in the room and stay there.” The room Larson describes is any meeting where decisions which have impact on the work you’re doing now or in the future are made. Larson says these meetings could be sprint pre-planning with the team lead and product manager, architecture reviews, performance calibration, team leadership meetings and executive team meetings. He says there is always another meeting which it is important to be part of, but he also talks about how to exit meetings which aren’t adding value.

Larson’s driving force is to get senior engineers into a position where they can be recognised and promoted to team lead. However, all of the meetings that he describes will help you, as team lead, and your engineers see the bigger picture and look around the corner. The topics discussed there will include what’s happening in other teams, the wider organisation and in the future. This makes them invaluable. Some of the meetings which Larson lists are quite high level and, while useful, won’t be as useful as some lower level meetings.

Many organisations have All Hands meetings where most of the organisation or a department within the organisation get together regularly and discuss what’s happening within the organisation and showcase what different teams have been doing. Sometimes teams arrange regular demos of their new features and invite other stakeholders and teams along. When a team is developing new features or services that are going to be of use to one or more teams, they will often schedule regular meetings, starting before, and continuing through development to release to help keep everyone aligned. Some organisations have ‘listen and learn’ sessions where engineers, product people and others share things they have learnt or are doing to the wider organisation. These and other meetings of this type are excellent places to get the bigger picture and look around the corner.

When organisations have multiple teams it is often useful for the team leads to get together regularly and share what they and their team have been doing since the last meeting. This is often somewhere where engineering team leads, infrastructure team leads and security team leads come together. This maximises the opportunity for seeing the big picture and looking around the corner. Sometimes the teams are grouped together and regular meetings between the team leads and engineers of the group can be beneficial too.

Having a good relationship with your immediate manager and those above them is also key to seeing the bigger picture and looking around corners. The better the relationship, the more likely they are to pass on interesting and relevant information.

For you, as team lead, and your engineers to see the big picture and be able to see around the corner, you need to be where the discussions are. You need to be in the room.

Tell Your Team

It’s not always practical or sensible for you, as team lead, and your engineers to be in all the meetings. I like to be there as much as I can and I usually invite my senior engineers too. If I cannot make it, then I make sure one of my senior engineers does.

Whoever absorbs the information, make sure there is a debrief with the rest of the team. Usually this can be part of a standup. I like to dedicate a small part of each standup to discuss what’s happening in other teams and the wider organisation. Some things might require a more immediate meeting with those directly affected or the creation or update of a ticket.

Wherever the big picture and the view around the corner comes from and whoever has absorbed it, make sure it is shared with the team as soon as necessary.

Finally

I was discussing my ideas on the Bigger Picture and Looking Around the Corner with a colleague of mine, Sam Berrington, who is a UX designer. Sam pointed out that if I was to replace the words "engineer" or "developer" with "UX" or "product designer" then the ideas still apply. They are not development specific. When you consider the bigger picture outside of just engineering, the emphasis shifts a little into cross discipline collaboration. Sam pointed out that for all disciplines the focus should be on anticipating change, often from business requirements, and how best to guide users through it, rather than simply reacting to sudden situations and producing quick fixes. We're often building products for users and the changes affect them first and we should keep this in mind regardless of technical speciality.

Team leads are responsible for keeping an eye on both the bigger picture and future changes and should guide their team accordingly, helping them understand and align their work with the broader organisational goals. The way to achieve this is summed up succinctly by another friend and colleague of mine:

“Teams leads must build a strong communication culture within the team and outside of it” - Laurent Douchy

If you do this, and instill curiosity into yourself and your team as well as a desire to understand why you’re doing what you’re doing, you and your team will be well on the way to seeing the Bigger Picture and Looking Around the Corner.

Bibliography

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

Thanks

Of course I couldn’t have written this alone. Thank you to:

Emma Andrews  
Sam Berrington  
Steve Cresswell  
Dom Davis  
Laurent Douchy  
Harvey Gwynn 
Stephen Harris 
Alex Leslie  
Katie McGeehan
Jon Moore
Het Patel 
Sudhakar Sabbella
Ilona Utting

for your input and reviews. And extra special thanks to Nayana Solanki for the inspiration to write this extra chapter.