My previous post looked at how software delivery has changed in the last ten years. Here we focus in on what that means for Tech Leads and how the job we need to do has altered and developed.

Architecture

New cloud technology has been empowering. The tech that brings Cloud Native, production-owning teams also brings new demands on cognitive load. This can lead to teams with little time to solve real business problems. As a Tech Lead you need to watch for burn-out or technology over-focus. Either look to use more granular technologies and Platform Services; or as Team Topologies suggests, look to your org for support with Paved Paths and stronger shared wrappers around complexity.

With the arrival of Staff engineers, the lucky are seeing a move away from Architect Ivory Towers and a shift to active governance and collaboration. Tech Leads should bring in Staff Engineers to provide problem solving and Big Picture guidance on the path forward for their architecture. Also look for paths that Staff+ are tending to and providing. Do they guide you forward?

Continuous-delivering, cloud-native teams have the ability to ship as often as they like. This demands new ways of working. We need to build to operate. Getting feedback from Production has become as important as testing before shipping. Your team should be building and using good enough observability and Test-in-Prod tooling, and you might need to push for that - both in terms of tooling, and ways of working.

The team needs to be set up and ready to deal with production problems. Avoiding one way doors is generally a key risk management mode, but it's absolutely key when testing in production, as ultimately, many of us will do. Help your teams build software that can deal with shipped mistakes. Can they roll back, roll forward, patch, and fix data? Do you have tools to manage or clear down full or errored queues? However your system operates, you will need tools to keep it operating well.

Don’t let this suggest that you should be coaching your team to avoid incidents. Get good at them and use them to learn! Counter-intuitively, infrequent production incidents (and big bang releases) often lead to fragile systems and teams ill-prepared to deal with them.

Minor incidents (from frequent, small releases) are the best kind; driving learning, tools and designs and thinking that support anti-fragility and recovery. Guide teams build their software so that failures affect as few customers as possible and do little harm.

Team

It’s harder to lead using your engineering experience alone. Cross-functional teams, tall software stacks and skill-biased engineers reduces the likely coverage of any team member’s expertise. To have successful missions, you’ll need to to use skills that access the team’s expertise and skills; look to develop and use leadership skills.

We no longer all work from team rooms. Big-visible boards and chatter no longer connect us up. Remote and Async working require documentation, collaborative communication and sync points. Teams need ways of working to help them to be drawn out of their heads, code and notepads, and into team spaces to allow alignment and onboarding.

This goes double for graduates and beginner engineers. There’s a lot to read about how remote doesn’t work for beginner engineers. I doubt that this is an absolute. Efforts to find new patterns that educate and train new engineers must be found and put into action.

Both Dora Metrics and people performance tooling can not tell the full story about the value the team and team members are adding. The Tech Lead’s job here is to add context and to highlight the value that tooling cannot track.

Risk

In 2024, teams ship. They have far more ownership and responsibility, and less necessary coordination, to get work to customers. This rightly brings more operational risks to the team where they can be well managed. But with fewer project managers embedded in teams, this can bring a gap around risk management that was not there 10 years ago.

The change in delivery style from projects to product has shifted things.. Rather than the risks of not delivering to a plan, many many teams ship frequently and measure swiftly, focusing on the next item of value. Additionally responsiveness to change and Continuous Delivery practices are great mitigations for whole classes of risk.

However risk does need focus for projects to succeed, and this can fall on a Tech Lead's shoulders. As well as ensuring that good Continuous Delivery practices are followed, Tech Leads should work with their peers to identify key risks beyond these controls. Surprises will happen. Don’t rely on luck.

Owning and operating production has other trade offs. Not only does the team need to build things, it has to ensure that what they own keeps working and meeting customer needs. An key job here is to ensure that the team balances operations, maintenance, and feature work so the right work gets done.

Business

Software products are increasingly released to customers incrementally, and somewhat experimentally. This changes how we work as Tech Leads.

How we write our software needs to change. We need to align our software design to the bets being placed and how they succeed and fail. Good bets need to be augmented and become part of what we deliver at scale. Bad bets get in the way and slow future work down, these need to be cleared out.

These bets, and what we build next, are judged by data we collect. Measuring what our users do is not just for operations or auditing; it drives business choices. The products we build need to measure as much as provide features.

The data a team produces can become an operational need beyond team boundaries. An organisation may rely on it being accurate and consistent. Ownership and maintenance of the data, what it means, context and consistency is paramount to success as products change and grow. This is a new focus for many teams. At minimum the Tech Lead’s job is to ensure these requirements are visible and can be supported.

Here's to another ten years

The job has shifted, but to my eye, in optimistic ways. Teams are more empowered and their choices; engineering teams are far more able to innovate and experiment to find good results. That does place new demands on the leadership in those teams. The good news is we are not alone. There are good shapes and practices to support what we need to do.

Want more?

This thinking all pays into the developing outline of the Well-Rounded Tech Lead - take a look and let me know what you think.