A little over ten years ago I was a Tech Lead and a consultant Software Engineer. I published the first version of the Well Rounded Tech-lead
I grew, and so did the tech industry. Engineering Managers became a thing, and so did Staff Engineers. Product management got good, real good. As for me, I got a job doing something in-between Eng Management and Staff Engineer, then focused-in on exploring different dimensions of Staff+ for quite a while.
Here I look at what I have seen that has changed before I take a view on how that affects a Well Rounded Tech Lead.
So, what's changed in the last 10 years?
Organisation and delivery patterns
As mentioned in the introduction, in modern engineering departments, Engineer Managers and Staff+ do some of the organisational heavy-lifting. Staff+ around governance of architecture, design and build; EMs: personnel, IC management, goal setting and delivery management. Project/Programme Management is often there to solve complex problems that span seams and teams, but are less often found organising individual teams.
Why’s this? Delivery has become more dynamic. Whilst we make Quarter and Half year plans, the cycle time of software delivery has kept reducing. Changes now ship to production multiple times a day, and for some, multiple times an hour. Tools and techniques to deliver value and to gain understanding of what our users do with what we build have massively increased. What we often plan is the learning journey we take with the user and the business, not a long master-schedule of increments towards a big release. OKRs (or other target and measure models) and North Stars often guide us.
Creativity, ownership, and adaption falls into the shape of a cross-functional team by default. Some orgs focus on poly-skilled engineers, others build multi-disciplinary teams. 10 years ago I would argue that is the way it should be. Now it often is.
Architecture and software delivery
Looking at technology, we are on the other side of the Microservices battle. From where I’m standing: small, modular units-of-service that teams own, steward and ship ‘won’. That doesn’t mean the idea-space of how we build our software at scale has stopped developing. Mono-repos and serverless continue to provide new options to deliver software, whilst Kubernetes keeps us on our toes. Generally whatever way we do it, we are looking to build team ownable, scalable, independent units of work.
The Dev-ops movement disappointingly drifted from a change in collaboration and a drive away from silos to a label for tools and a type of team. But it brought us both Team Topologies, Cloud-Native teams and Dora Metrics. All wins for me.
Cloud-Native teams grew from the fan-in of the Dev-ops movement and the growth of PAAS offerings, leading to teams being owner-managers of their products and services. This empowerment can lead to Cognitive overload and make it hard to manage an org's tech cost and stack, and make fluid movements between teams an impossibility.
As we shipped more continuously and our services divided into small units of work, testing exhaustively before production became something that slowed us down as much as raised quality. We committed to Testing in Production, reaching for better Observability tools, and ways to control how we introduce and release software changes to users. The growth of monitoring and observability tools allows us to take more risk and react faster, but also to get us into bigger messes
Architecture Decision Records (ADRs) and Design Docs have become a clear method How we hold Team Memory. The GitHub implementation of how open-source software gets made has grown to become something that can be used to collaborate asynchronously to make and hold decisions.
Team Topologies arrived. Providing a vision of an emergent and growing platform that supports scaling of software driven companies. This combined the concepts of Platform Engineering, Developer Experience, Paved (and golden) paths as a method of how engineering orgs scale and enable Cloud-Native teams to be part of a bigger whole-product engineering organisation. Supporting effective, efficient software delivery that can value onboarding and rotation around teams.
Through Paved Paths - a Team Topology adjunct view - the technical choices available to a team is greater than it has ever been. Increasing the empowerment of cloud-native teams from using what a PaaS vendor can provide to a tech stack optimised for the Org and product.
Technology change drives forward
As software eats the world, and the world-and-its-software gets online, security increased massively in importance. 99.9% of computers are networked, and many are accessible and probably vulnerable in some way. All our systems need to actively prevent illegal access. That our software is increasingly built from other people's libraries and code, makes this harder.
Almost every engineer had a smartphone in 2013. But now your nan and your neighbours' young kids all have them too (U.S. Smartphone Penetration Surpassed 80 Percent in 2016). Device-first and the swing to rich, fat front-ends (React and friends) emerged swiftly in the mid 2010s and has become the default way we build websites and frontends, whether it’s needed or not. This has somewhat distorted the skill-sets needed and often engineers become skill-biased towards frontend or backend development.
Team orientation
Dora metrics grew out of the original Continuous Delivery and Dev-ops movements. An analysis of the state of Dev-ops - how a great tech divisions got stuff done, boiled down to a set of key measurements that could help direct success.
Along with measuring delivery success with Dora metrics, a class of software has developed collecting stats on engineers and team behaviours from GitHub and delivery-planning tooling. This can be used for a range of analysis, from helping teams to focus on and manage key cycle times, to assessing engineer performance based on their tooling interactions.
Psychological Safety and Cognitive Load have given us clear and useful labels to things we already worried about. We have always known that safety and room-to-think were important for teams, and their ability to learn, but having words and studies to support what we do has really driven this forward.
Async working and remote work has always been in existence, but the last few years demolished any arguments that it was not possible. The practices and processes to incubate junior engineers have not always kept up and this is a problem we now need to solve.
Next week, I'll look at what that might mean for a tech lead.
Thinking hat went on. Job done: Tech Leads in 2024: Navigating the Evolving Landscape