2025, What a year! Though the last few have been a run; Post Covid, the software development world shifted and shifted again.

Remote shifted back to hybrid and in-office models. Changes in the cost of debt forced start-ups and scale-ups to refocus on revenue before growth. "Do more with less" became a mantra even before LLMs appeared. Engineer salaries stagnated and often fell, with layoffs occurring as frequently as we used to ship new software. In the post-agile era, modern software engineering faces the threat of being overtaken by vibe coding and LLM agents.

Predictions of large skills gaps in IT and software engineering remain, but it doesn’t feel like it on the ground. Career progress and growth occurs within jobs rather than through job changes. However, that's the least of our challenges: organisations and work methodologies are shifting bigly.

How can we best operate? Do we roll with the punches? Could we bottle this chaos and find great new ways to work? I believe these shifts create space for great work, but we will need to chart new paths to reach great outcomes.

What's a staff engineer anyway?

The role of staff-plus engineers is relatively new and remains ill-defined. With all this change, that's both a blessing and a curse. Anxiety, frustration, or disappointment can arise when new or shifting expectations surprise us. But with an awareness of the conditions in hand, we can acknowledge the situation, and switch modes. Taking notes from Cynefin, we might do well to operate by sensing, reacting and bringing what's needed, rather than working to what was needed last month and last year.

What might that mean for how we do our jobs?

Paper Planes, Not Jet Schematics

In 2025, I discovered that my work as a staff engineer was most successful when executed in shorter cycles. Unsurprisingly, a key lesson from Agile that I need to apply to my staff work. My long-term thinking often became irrelevant before usefulness due to shifting needs and priorities. If a task wasn't actively progressing and nearing completion, it was as if it didn't exist.

I needed to be more nimble, finding new collaboration points and quick paths to success, rapidly turning around results or new data. However, juggling too many tasks also diluted focus and slowed progress.

In 2026, my work needs to intersect with the organisation more frequently, delivering valuable outcomes in the shortest cycles possible. Although this approach may seem non-optimal, it ensures that results speak for themselves and can secure approval and focus for subsequent steps.

That doesn’t mean I can’t have agendas and pursuits, but they need to be mission-critical and action-oriented, or relegated to side hustles that can be called on when useful.

Let 'better' set the direction of travel for your teams.

Traditional strategy and planning often turns into multi-year plans and roadmaps. Doing that now can risk generating much waste and sorrow, leaving you high and dry when the flow shifts.

We need to use strategy to set agendas and direction, guiding us forward rather than relying on longer-term goals, plans, and expectations.

I think the teams I support will massively benefit from knowing what they are there for, and which direction 'better' product, system and architecture are in. It will help them strip the noise from the key messages that they can then use to keep focus on driving forwards. Teams need to know where they’re going, and instead of following a fixed plan, I want to equip them with tools to positively adapt to change.

This may be working with the team, building a dynamic strategy towards 'better'. It may also involve collaborations with other senior leaders to ensure that the team can get clarity of brief that will result in good software, long term. Either way, the way to build something coherent and maintainable will need my support.

Team ownership challenge accepted.

Through vibe coding, LLM saddling, or revenue-before-scale re-orientation, doing more with what we have means many teams will end up owning and operating broader sets of work. And this might well include large chunks of valuable but unpolished functionality. In 2026, there is a predicted increased demand for on staff augmentation, along with the complexities of onboarding, offboarding, and ownership that will accompany it.

For a staff engineer, this means we need to imagine, and help others realise, good management of broader portfolios. And methods to manage a portfolio that might contain a mix of legacy, imperfect and experimental work.

How can I help teams not get swamped? By finding better ways of owning and operating. I'm expecting to be spending time with teams and tech leads, finding ways to own more, and still getting things done. Toil, incidents, bugs and customer issues will need to be managed differently - can we look to better communication, automation and use LLMs to manage toil? Will a focus on self healing (not just reporting of faults) and self-informing systems provide to both the team, org and our customers? Can we add this into what we own, and build new systems with this in mind?

Architectures-of-the-future still need to be built.

We will need to build architectures that meet future needs which are hard to foresee, and do so incrementally as we scan ahead and deliver in small cycles. Post-microservice architectures that both have a strong event orientation, and high-level business domain focus are likely to be ones that allow good combinations of scale, evolutional building and Agentic operation.

It's a bet worth placing, but how do we get there with the above challenges is going to be a big mission and maybe a key driver for 2026: understanding that we need future architecture that can be built in pieces and be successful on the way is probably the most interesting and valuable problem that presents itself.

We need to try new things, but we need to talk first.

Staff engineers bring experience, practice and ways of getting stuff done, but we don't scale. In the midst of this change and challenge are all those ace engineers you are there to support and help do great things. My aim will be to help others navigate, and build great things.

In 2026 I want to have more chats, and be in less meetings. In the distributed world I live in I can't rely on a coffee room or corridor chat. These can't be typical mentor chats - these need to be 2 way streets - I need both information to steer what I prioritise and I need to assist and support the problems folk need to solve.

Change is inevitable, but suffering is not. We can be the glue that holds things together, but this glue needs information to cure. I think chats could be the 2 way street to do this. Dear reader, do you have other suggestions?

Conclusions: Throwing shapes

If you see the same patterns in 2025, here is what i plan to do to find success in 2026

1. Reduce Cycle Time and Thoughts in Progress: Focus on minimising cycle time and the number of tasks in progress. This approach allows for quicker iterations and more immediate feedback, enabling you to adapt swiftly to changes and deliver results efficiently.

2. Set Teams Up to Ride the Waves: Collaborate with your teams to clearly define their mission and set navigation buoys as guides forward. This clarity will help teams stay focused on their objectives and adapt to changes without losing sight of their goals.

3. Equip teams to handle a Broad Operational Portfolio. Point them toward building low to no maintenance products, ensure useful documentation and information flows happen, to reduce distraction and toil.

4. Iterative, Evolutionary Suiting Architecture: Emphasize the importance of developing architectures that are adaptable and can evolve over time. This approach allows teams to react to unforeseen challenges and opportunities, ensuring that systems remain relevant and effective as needs change.

5. Talk More: Encourage regular, meaningful conversations that go beyond formal meetings to share insights, address challenges, and support each other's growth. This will help build a cohesive and resilient team environment.

Cover photo by Hans-Peter Gauster on Unsplash

Here’s my talk from Agile on the Beach on engineering career development that directly impacts retention and organizational success.

In my career as an engineer, consultant, and mentor, I've found that growth isn't linear, and one approach doesn't fit all. If you match your support strategy to where engineers are in their journey, you can see both individuals and your organization thrive.

Want more?

Here’s a page with some deep-dive articles, handy screenshots and loads of useful links.

When faced with this challenge, I instead chose to build a rising tide that would encourage security by design and default.

In this article I'll be talking about the three steps we took to get our engineers able to deliver on this through education, Paved Paths and risk assessments.

Elevating Security Knowledge

To have a baseline standard of security in all our products, our engineers needed to understand security better. Through engineer self-assessments, we could see that many of our engineers had gaps in security knowledge. With this in mind, we provided both general and company specific training.

Training for all

Self-assessment data made it easy to make a case to budget to hire an external trainer to deliver training. Our selected trainer delivered two days of modules for our engineers to attend. We allowed our engineers to select what modules were right for them, by aligning the training to information from the self assessment. Almost every engineer attended the training, with some wanting to attend all modules.

Insights from within

We invited our internal experts on external risk and compliance to walk us through security and compliance risks. They first spent time with the engineering security team, teaching us through content, chat and questions. The engineering security team worked as advisors and editors, honing the material into key points that could be delivered and consumed by all teams.

Talking risk and consequences

We backed up this training with stories from the news where companies had been hacked.

We encouraged discussion and digging into how these serious issues happened. Sometimes scary stories are useful to motivate, if they are honestly told.

Key move: A Platform and Paved Path for all

Our key move was to treat security as a platform that could be provided to our engineers. And through that provide a default Paved Path, that when followed would result in good-enough security 'by default'.

A modern name for this might be an Internal Developer platform. The visible parts were a guide that gave our engineers advice, and provided, like a Highway Code, a clear set of MUSTs and SHOULDs for all our projects.

The guide was more than just words. It presented a Paved Path for teams to use to deliver. We had identified a practice to support. Some of these were industry standards, or operated from well known third party libraries. Others used internal tools or standards built by engineers or the infrastructure platform team.

This collection of technologies and practices standardised how we solved the most critical risks to our systems, paving the path to production, and providing a default way to deliver securely.

Tailored Security: Advanced Paved Paths for Complex Challenges

Some of our teams had complex data security needs. They handled and held data that demanded additional attention and security. Our default Paved Path could not serve these needs. Raising our standard expectations would require additional work from all teams. It would be an over-reaction: at best it would waste time and effort; worst case, we would lose engineers' support by over-demanding.

We chose to be selective. To present a second, more demanding Paved Path, and help teams choose a good path for their needs. Rather than raising every boat, we could build a lock to raise selected boats up to the level needed.

Again we used our security guide to provide this. In it we helped present a guide to help them grade their data and select a path; a second set of directives and more practices that provided suitable controls.

Security by design.

Our higher risk route pushed our teams to consider security careful in the design phases, running threat modelling sessions as they built their software. It also added additional constraints and expectations to data storage and 3rd party library management; as well as expecting a higher level of security as standard.

Impact

Teams made better choices, and prioritised security outcomes much better. The estate got smaller, less flabby and more secure in many ways. Old code got killed or revamped. Higher risk data was separated and held to higher standards. Sensitive data on the move though our systems was better controlled. Staff cared more about security all the way to the Board.

A quote from an engineer sums up the success:

"Everyone knows where to go and engineers are empowered to use secure by design in everyday work"

The journey to enhancing security within an organisation is about more than just policing, policies and procedures; it's about creating an environment where security is ingrained in the culture. When you want to have big impact, build a system that will support your engineers to make great decisions when you are not there.

When we build a platform that will support every engineer, we build a resilient organisation where security is a shared responsibility, and every engineer is equipped to make informed, secure decisions.

You can read more about the STAN - our Secure by default guide - in a previous blog post.

My Journey in Digital Product Security

A few years back, as a staff engineer in an Ed-tech company, I took on the challenge of raising digital product security. You can read here, how I chose to drive it using an small engineering team.

Having pitched, chartered, and formed the team, we were ready to begin. I had 6 months to prove our value. When initiatives start, it's challenging to gain traction, making it difficult to earn the trust and buy-in needed to implement real change. For the team to demonstrate its worth, we needed to find the key moves that everyone could get behind.

In the face of complex changes, even the best times can derail. I had a vision and a team, but I needed a plan that would inspire and gain everyone's support.

(The Lippitt-Knoster Model for Managing Complex Change)

Identifying Key Security Concerns

To get trust, I needed to identify what work was valuable and achievable in that time - or shorter. Even better, if I found that out in collaboration with others I could start to build community and consensus.

I identified 4 areas of focus and a key question for each with the aim of workshopping each one.

• External : What do we need to be better protected from external attacks?

• Internal: What do we need to avoid exposure of personal data and reputation damage by staff?

• Compliant: What do we need to achieve high levels of compliance with law and regulations?

• Delivery Process: What do we need to ensure our squads keep us safe whilst delivering new features?

Engaging the key contributors

I thought about who should discuss each question. Each session would focus on answering a key question, but there was deeper work than just building a list. Real security is a mix of risk identification, tradeoffs, and an understanding of what systems might do.

As well as experts, I also needed to hear from the teams involved and those impacted by security risks and the potential change: leadership and those designing, building and operating our products and platform.

I invited experts, the involved, and the impacted for each session, and began to work out how I could flow each question into the answers I needed.

Workshopping: Transforming Discussions into Actionable Priorities

There were a few outcomes I wanted from my workshops. Looking broad to understand the risk space the business was in, zooming in on what my team should tackle and to grow care and involvement in security.

With that in mind I set up each workshop to first generate a pool of issues or gaps. And then to ask the group to segment and prioritise what we had identified.

The below diagrams show the flow of each of the four workshops.

Achieving Consensus and Direction

There were weeks of preparation and hours of meetings. It was worth it. We found strong agreement, buy-in and direction

Not only did we have a strong Risk Register, we also were able to form a stakeholder-led steering-group to guide how we approached controlling the risks. We also had clearer agreement of what problems belonged to which teams and a backlog for my new team

Driving Change with a Robust Risk Register

The impact of an action is the things it makes better. A risk register is pointless unless it drives change. Looking back, I recall how the register and the stakeholders helped shape the work the Engineering Security team cared most about.

We took immediate action to get better management of Production Database credentials, and secured other access and passwords. We build tooling to provide an overview of the state of vulnerabilities in 3rd party libraries across the estate, driving updates and further care.

more longterm, It drove a long thread of work that began with an assessment of the data each team held and drove towards a guide to help the teams make good choices for their data and products. Our Risk Register kept us joined up and always looking towards fixing the biggest most critical gaps.

In today's digital age, a multitude of services are accessible online through apps, websites, and internet connected devices. Whether you're booking a holiday, arranging a flight, shopping, ordering a meal, or adjusting your home's temperature, chances are you're doing it over the internet.

Even if you pop to the shops, or make bookings over the phone, service providers are operating 'digitally'. Nearly every service provided to the public is an integration of a number of platforms, software, and services communicating over public networks. All built from a mix of custom software on a foundation of commodity libraries and supporting systems.

This provides a broad threat surface where malicious actors can look for ways to enter and exploit your systems and the data they hold, for fun and profit.

If you own or run one of these systems, you'll be dealing with these risks on a day to day basis. Odds are, there are more risks in your Risk Log than you have staff to secure them. Not only that, but you might well have a large group of engineers, building, experimenting and shipping novel ideas and new features far faster than you can keep up. All systems built out of commodity software libraries provide a constant stream of vulnerabilities.

The threat surface is always growing - evidenced by the reports of hacks, data exposures and ransom attacks that appear weekly. But you cannot police every risk or change. So what can you do: delegate, enable, or police?

A solution shape

As a Staff Engineer faced with this challenge back in the late 2010s, I pitched and formed a three person Engineering Security team to enable the Product teams to make good security decisions and actions.

We acted as an Enabling team, informing and influencing choices, bringing in new knowledge and building an Internal Developer Platform to raise the knowledge and leverage all our engineering team.

Why this shape

I was inspired to choose this shape for three reasons.

Reason 1. Don't be the brakes

How we delivered was important and I didn't want to damage that success. We had a set of autonomous product teams who experimented, operated and delivered products that our customers loved. Centralising controls, placing external gates, or reducing team ownership of the whole problem was not a recipe for success.

Reason 2: optimise for speed and success

We needed good enough security at the right time in the right places. Putting security demands where the work was, would both provide leverage (we had many engineers) and would allow decisions to be made in context.

Reason 3: a valued pattern

Coming from a software consultancy background, I was used to structuring and delivering organisational change. An enabling team was a common pattern when introducing complex change, able to work from the trenches, understanding the needs and often dog-fooding and trialing changes before scaling them out. Team Topologies has cemented this concept as one of four key team types in modern software delivery.

Beyond this, there was existing work that showed that engineers were a good place to invest in security. In 2015, Shannon Lietz, a Security leader, said that teaching a security person how SW delivery works ”takes a lot longer than teaching a developer how to understand how to make security happen and change how security gets remediated” - (GOTO 2015 • The Road To Being Rugged).

Why not Security champions?

Security Champions is a pattern that has become popular in the last 5 years and is a way of scaling out security. It focuses on having a single point of contact for security in each team. A team Security Champion operates as a communication conduit and a review point of security quality in the team, performing security code reviews and dedicating time to security initiatives.

I don't think it's a great model on its own. While it might complement other strategies, it has several failure points worth avoiding.

Silos: a problem with lone champions

Teams are the unit of software delivery. The members of a product team should have all the talent that is needed to build great products in a domain. We often support them with utility and education platforms - supporting a self service model that removes silos. Silos of knowledge and control slow down getting stuff done by gatekeeping and destroying team ownership and flow.

Just as external security control creates one of these silos, security champions distribute but don't remove the silo, leading to a risk of gatekeeping and a higher bus-factor within the team. To avoid a silo, it places the enablement effort in the champion, something they may not have the skill or drive for, as they likely signed up through an interest in security.

Security Champion alternatives

Every company and situation is different. But, if you want to raise the engineering standards of a set of teams, focus on how you can do so without generating silos and bottlenecks. Given these limitations of Security Champions, focus on enabling teams to do a better job and to be able to build good enough software. Whatever you provide, keep the barriers to entry low, make it on demand and as self service as you can.

What could an enabling team bring that would allow them to scale?

Consider a platform to raise standards

When folk use the phrase 'platform team' it often takes us immediately to a team that provides on demand compute and other operational components that deliver software to users. With the complexities of modern infrastructure, it's a clear place to manage with a platform wrapper to hide the complexity and provide utility.

Internal Developer Platforms can serve different goals, and security is a great candidate. You can read here how our Engineering Security team built a living standard that worked as part of a platform that scaled the company's security expertise. Along with that we built reporting tooling to provide calls to action and feedback and new tooling, as well as providing support and education, engaging with the challenges our teams had.

Consider Communities-of-Practice to sustain interest

Of course, we totally wanted to sustain interest in managing security, and support engineers interested in becoming knowledgeable and skilled in this area. Our Engineering Security team ensured everyone could join in and learn what they could, and that there was a space where folk interested in security could converse and contribute. We were part way to building what would now be called a Community of Practice[1] - a gathering of like-minded people where a skill or interest can be honed and improved.

Foster Collaboration and Empowerment

In wrapping up, it's clear that the digital landscape is fraught with challenges, but by fostering an environment where product teams are empowered to make informed security decisions, we can maintain the agility and creativity that drives success.

The approach of enabling rather than policing; and focusing on education and shared knowledge, ensures that security becomes a seamless part of the development process. This strategy not only mitigates risks but also enhances the overall resilience of our systems. As we continue to navigate the complexities of digital threats, let’s commit to raising the tide of knowledge and capability across all teams, ensuring a secure and thriving digital future.

Over at LeadDev you can read three part of my series that walks through how to apply different development and coaching styles to the different stages of engineer growth

• Gaining competence: 3 steps to successfully onboard junior engineers

• Gaining fluency: 4 steps to technically upskill engineers

• Gaining mastery: 4 ways to help senior engineers grow toward mastery

I needed to get some research done, to give out some numbers in my talk. Folks love numbers!

Even better, I can back them numbers up! I got links, fam!

Let's begin with a big number. The 2024 Stack overflow survey asked whole piles of professional engineers about satisfaction at work. It found only 20% of developers reported being generally happy.

Why might that be?

Well, this bit isn't based on survey data, sorry. But this fella called Frederick Herzberg (a 20th Century American psychologist) had a "Motivator-Hygiene” theory. Which basically summarises what’s important in a job, yer ken? It placed Achievement, Growth Opportunities, Advancement, and Recognition as key motivators.

Is that what's going on?

Is there data to back that up? Back to the surveys.

Robert Walters (a recruitment company) provides some data points. 91% of Millennials want rapid career progression. But, no surprise, they don't always get it. And what happens? 20% leave for better career development opportunities.

Another one of their surveys (this one from Back in 2015) found 44% of professionals cited a lack of progression as a major contributor for leaving their role.

This data indicates that many people want to grow and achieve their goals. And when they don't get that? They leave.

But it could be worse. As the saying goes: What if they stay? Stay unhappy, and stagnate.

Time to talk about retention.

They say it's much easier to grow the talent that you have than find new. I wanted to quantify that, so, yeah, I did some more googling.

The costs of replacing a skilled engineer were hard to tie down. I saw figures ranging .between 50% to 200% of an employee's salary to replace them. And that's outside the cost of actually paying your new person.
(If someone has some good data, and by data I mean links, on this, drop me a line, and I’ll update.)

Stagnation

What if they stay and we don't fix this?

Gallup (an analytics and advisory company) found only a third of U.S. employees were engaged, meaning they were highly involved and enthusiastic about their work and workplaces. However, Top-performing organisations average 70% engaged employees. That must be better than PIPs and terminations, right?

Let's close our numbers with a positive stat

The HR Digest - without a link to survey data (boo!) says that in 2022, companies that invested in employee development saw a 58% increase in employee retention and a 24% increase in productivity.

It does look like active career progression aids retention of talent and avoids staff stagnation. And it builds reputation and attracts good engineers.

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.

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

Everything has a shelf life, even software. Continuous delivery of value is hard in the long term. Swift at the start, change often slows down as delivery continues.

In my last post, I walked through how development friction often increases. And how building software gets harder the more we add. Our options often become more restricted than we would want.

I asked myself: If I can understand it better, can I communicate the challenges? And if I can do that, can I create more options to manage it better?

Three Forces of Complexity

Every project is a snowflake. Reasons are complex and different for every organisation and product. However, I’ve identified three forces that we can tackle in turn, to keep our software fresher for far longer.

1. Not every bet pays out

When we begin, we know the least about what our customers need, or how we might solve it effectively. We always need to make assumptions and decisions to move. These choices are rarely perfect. Not every feature gets traction. We measure, learn, adapt.

We bet when we pick architectures and build software too; though we don’t acknowledge it as much. We gamble on what we know, or what we think might work. We take guesses at what options we need to keep and on what technologies will solve our problems.

Bad bets leave behind tech debt and feature cruft. These can cast long shadows over our future work, distorting and forcing it into shapes that aren’t ideal.

Clearly, we need to tackle the parts of our systems that are costing us, but is there more we can do?

2. Complexity grows

We build our products and systems in small slices. We create spaces and put like code together. As we go on, those places get cramped and may creak at the seams. But they still seem like good places, it's just that little bit harder each time.

With each success comes more complexity, and that complexity needs to be navigated with every new change. Even if we are prudent (and often we are not), and refactor mercilessly, the necessary complexity can become a point of development friction.

The complexity of our systems needs to be managed in more than a slice-by-slice way. We need to let our systems breathe and hold something that our engineers can navigate with low friction.

3. Need drifts

Today's news is tomorrow's chip paper. No matter how well we do at managing debt, cruft and complexity, what we build has a lifecycle. New products come to market. Our customers and our organisations develop and what they want and need changes over time.

But we need to work with what we built, to stale needs. The past curses us again.

Technologies also lose their freshness. What looks cool, well-maintained and useful can become stale and unloved. Sometimes just a major version change can cost months of work. Perhaps we should always plan for obsolescence.

How do we get out of it?

Each of these is a rising grade of system hygiene to be tackled. If we clean and manage our bets we should reduce the accidental and unnecessary complexity.

If we are aware of where our systems are hard to navigate and change and we fix and spread that complexity, we make it easier for change to happen.

If we accept that what’s needed is going to change, we can build systems that will adapt, and align with what’s happening with our product.

Success at each level should allow us to be ready to tackle the next. There is a richness to how we can solve these, which I’ll cover in the next post, suggesting tools and practices that we already know to move us forward.

Perhaps you know the feeling? A team begins to build a new product. The technology stack is selected, and coding begins. You set up spaces where you will code and ship into. Soon you are flying. Writing good code and good features is never easy but work rolls out fine: predictable, with low friction. Changes and enhancements dropping into the spaces you’ve curated.

It feels like beginning a game of Tetris. You have lots of space and time to work out where to place your shape. There’s room for errors and corrections. You could keep doing this all day.

Things change, and not for the better

A few months later something shifts. Change is no longer easy. Things don’t fit anymore. You're walking through syrup.

The team’s time is taken up with juggling the management of what you have. Adding new things to your product in a reasonable timescale is a constant challenge. There’s always a time sync or a reason why a desired feature is much tougher than it should be.

You are no longer playing Tetris on easy; dropping in blocks and clearing the board. The Tetris game board is almost full, and it takes all your attention to find space to keep the game going.

How do we get here?

Software don’t come for free

New work appears when shifting from fresh green fields to supporting and maintaining a live product. But often the friction in additional development grows well beyond that, and optimising the product and business for the support needed for a live product is not enough (though an interesting topic for another day).

We don’t write all our own software. We use 3rd party and open-source libraries, and that helps us go fast. However, we should also acknowledge that this does not come for free. These libraries get updates, bug fixes, and security patches. Engineering teams need to stay on top of this and ensure that their software is built on good and trustable foundations. This takes time and thought.

Further development friction is the fault of the future

Those two areas are not the complete picture, not by a long shot. There are a broad range of contributors that cause development friction, but what it boils down to change. Change is hard.

What we have built is likely unsuitable to solve the next, new, problem. How could we have known where we would end up when we started?

It can be that the good code we need is surrounded by cruft. Things we don’t need that get in the way. Bets and debt - produced by time-to-market pressures and experiments. We often build more than we need, either accidentally or to discover what we need to know.

Success can bring complications. Maintenance of a growing changing system in a growing changing organisation is hard and needs commitment, focus and time. We also might not be able to see that what we own and maintain is slowing us down, maybe we need to remove more than the cruft. That conversation can be very hard to have. We often love what we have built and see sunk costs as a commitment to a route.

Ways out

In my next post, I’ll break down the friction agents into some grouping that can help us navigate our way through the drag, but there are a few broad areas we can think about before we use a model.

Predict and protect

We can certainly work to predict what’s going to happen and try to prevent its worst effects. Can we build less software when we are at the learning stages, or keep it malleable to adjustment or removal?

Communicate and collaborate

A ‘No’ often offends. After all, if everything has been going well, and then it all slows down, what’s to blame? Expectations have been set, and maybe commitments have been made?

I wonder sometimes what folks are hearing when I explain we need to go slower. They look surprised, and sometimes disappointed. Are they worrying that the engineers are getting lazy or bored? Do they now see us as a problem or a blocker rather than a team that solves things?

I think it’s important that we not only know the game we are playing but that we get ahead of the game. Stop being damned optimists and expect the levels to get more complex. We should ensure we are communicating and collaborating with our fellow decision-makers to set expectations and make choices together. We are all placing bets and adjusting as we learn. ‘No’s may have to be delivered, but it shouldn’t come as a surprise.

Modern software development is progressive, not magic

Software is flexible and malleable, but not infinitely, at reasonable costs. Sure, Agile Delivery is iterative and incremental, but at its heart, it's about reacting to what we learn in the most valuable and useful ways. we need to design and then re-design as we gain new information. And we need to keep talking about that.

Quality Bits has kindly chatted to me about the subject. Take a listen, and let me know what you think

There are several different approaches to ensuring good enough security in digital products. My go-to option is to place responsibility where the work is. Requiring the teams that own the products to own, understand and deliver securely.

That doesn't happen by magic. Teams need sufficient experience, information and support to make good choices. That's where great documentation fits in. Guidance and ease for engineers plays a big part in helping teams do security well.

In this blog post, I'll tell you why it's important and take a deep dive into an example I helped build.

Why Security Standards are important

Most engineering teams need assistance to own security - it's not their area of expertise. They need to understand security threats, and the protective solutions needed in their products. They also need a broader picture of how to operate online in this risky world and how to reason about threats.

Additionally, empowered product teams get very good at making trade-offs to get to market and find product-market fit. They need to know what's not negotiable, and when security might become more important as their product grows.

A document is no replacement for an expert, but it can scale, and be there whenever someone needs advice. It can cover the default and the quick wins, allowing experts to deal with more novel problems.

What a security standard needs to do

A Standard sets a bar. It says what needs to happen.

A good Standard presents solutions and safe ways to work: paved paths, pits of success, and guardrails. Low-friction, good defaults to avoid or solve the problems that the standard lays out.

A great Standard explains why. It enables teams to make the right choice in context and helps grow their experience. It might even ask them to contribute.

A useful Security Standard needs to do all these.

In the deep drive below you'll see a standard that does these, as well as present contact points, for when the standard isn't enough; guidance in structured thinking about risk and security, so folk are likely to make good decisions; ways to learn more about security, so that we can grow community.

Meet Stan, a Secure Engineering STANdard

It was nicknamed the STAN, after Stan Lee, the Marvel Comics' key creator. It has his phrase “With great power comes great responsibility” in large friendly letters on the cover.

This served as a reminder that empowered and autonomous teams have great freedom in their choices, but also a great responsibility to take good care of their users’ data.

The guide provided materials to help teams understand and think about the risks their products are exposed to. It also provides a structure to operate within to mitigate those risks.

How did the STAN do this?

The STAN was clear about what risks need to be managed...

The Stan presents a set of baseline risks that must always be managed. These Secure by Default Directives set up every product for security success. Every team must follow these directives when building software.

The STAN also contains a set of directives for higher-risk areas and advice on how to navigate them in a bespoke way.

...and provided solutions

Telling people the risks they need to protect against is not enough. The Stan made it easy for teams to solve these problems and manage these risks. It did this by providing a practice or solution for each directive.

The STAN guided choices through graded paths

There’s diminishing value in building more than you need. Teams should go fast when it’s safe to do so and take special care when it’s important.

The STAN contributed to this by presenting an operating model that avoids rules for rules’ sake. Simple, low-risk projects can ship swiftly with default levels of security. More complex and risky projects can be assessed and suitable security built in.

The STAN offed graded paved paths, based on the type of data being processed. If a product was assessed to be in a higher-risk category, the team was provided with a higher level of directives and practices.

The STAN helped people think about managing risk

The distribution of security experience is often uneven. The STAN helped to level this and helped everyone think about what they should be doing to manage risk.

This included sections on Threat Modeling and thinking about risk, as well as guidance for learning more about security.

The STAN was a collaborative living document

The STAN was actively developed in collaboration with product engineers and was improved by their contributions and feedback.

Good defensive practices develop over time. The Stan was delivered iteratively. We didn't want to get everything perfect before shipping. We expected practices to change and invited discussion.

It was built in markdown in GitHub, where engineers spend a lot of time. It invited engineers to review, feedback and contribute in a form they already knew.

A standard can be impactful

Supporting product teams to make good and informed decisions means that a small Security team can have a big impact.

Creating a standard enables security teams to focus on adding value in more risky areas, safe in the knowledge that the basics are there.

Cover by Hello I'm Nik from Unsplash

If we could they would not be ambitious

We do our best. But complexity often drives us to focus on too big a chunk or to make small changes that don't get us going where we need to go.

I use horizon planning to discover what we need to do. The key small steps that are likely to inform and lead toward where we want to be and the more ambitious chunks that can really move the needle.

If you have challenges identifying the right next steps to get towards your goal or want to bring focus to a complex set of moving parts and make some good decisions, read on.

Take an imaginary journey with me

Imagine starting out on a long hike in unknown territory

We know where we are.

Our destination is way over there over the horizon. Several horizons.

We cannot navigate by sight, so we get a map and make a route plan.

And what happens..?

In the doing, our plans change

On the ground, things look different. We learn about our equipment and the terrain as we go. We hit obstacles that we can’t get through. We learn about our initial choices and what the team can do. We may need to find new tools, assistance and options.

Why is this always happening?

When we start we know the least. There is a high degree of volatility and variability in our predictions. We can't know all the answers, because we have not been there.

from http://www.agilenutshell.com/cone_of_uncertainty.

I want to add value as soon as I can - providing solutions to our customers. But I know that discovering the information that will provide the confidence to commit to bigger and better steps is equally important.

Introducing Horizon Planning

Horizon planning is my way of navigating the complex - getting to where I want without knowing exactly where that is or what the path there might look like.

I break up the steps to get to my goal and segment them into three areas

1. Next: What I can do now: quick wins and information gains.

2. Future: The big chunks that get me closer to a solid solution

3. Ideal: The solution, I think I want, to reach my goal

The value of Horizons

By seeing how the first actions line up against the future and ideal state, you can check that what you do now will inform you about what you should do next - making sure it all joins up.

It also means you might find out early that big bet ain't so good, allowing swift adjustments with new key information.

Roots

‘McKinsey's Three Horizons of Growth’ was documented in 1999. Harvard Business Review championed the thing in the 2000s and called The Three Horizons: 'A foundation of innovation strategy.'

For them, it was all about big planning in three phases:

1. Short-term operation (and innovation) - maximizing value on what you hold.

2. Extend the business model to new places.

3. Create new things in response to challenge and change - highly uncertain work.

I've seen it also adopted as a way to encourage growth conversations. Examining the challenges in our present, our aspirations for the future and the innovations we might need to address both.

From the Toyota Production System

The Toyota Production System offers a similar pattern. That getting to a goal requires a series of experiments through an experimental path of targets to where you need to go. Quickly informing on if and when you need to steer your course and change your plan.

I combine the two, allowing me to plan forwards and backwards to gain confidence in what I need to do next.

How does that work?

Ask: what might we do

For my usages, It has operated as simply as presenting a Current State on the left, the Goal on the right, and asking:

what's going to help us get from here and now to the goal?

With these ideas, I lay them out against three horizons:

Ask: what should we do?

I then work through questions like

What's going to have to change for us to get there?
What are we going to need to know?
What feels risky enough, we need to experiment first?
What early work will lead to the bigger steps later?

When we ask these questions, we need to remember that it's okay, well, actually great, to think in steps or stages of delivery, learning and change. With this in mind, I add and remove items from my plan.

I've found it often useful to think of what value and information you'll gain at each step. It can be well worth checking in you're doing both.

Putting the plan into action

This can provide clarity of the work to do next and how it will lead us forward. Work that:

1. Aligns with the big goals

2. Solves a problem right now

3. Provides information on the bigger next steps

As we play this work we will be learning about reality. And so we will need to adjust, and change what we do as we look to ship value and gain information.

Be ready to adapt and seek the next hill

As you operate in horizon 1, it will be informing you about the reality of your predictions about Horizon 2.

You might adust in-flight, allowing your mapping to work as an adapting plan.

As you get close to the end of Horizon 1, if your world still appears too complex: iterate. Take what you know into your current situation and convert all or part of Horizon 2 as your new 'next things to do', de-risked and informed.

Are you ready to be certain about uncertainty?

I use this model in different ways.

I've used it internally, when I own a roadmap, chunking out sections of work that will inform the group about the next phases of the roadmap.
I've used it as an explainer, helping consultants on the ground see the complexity ahead and how we can approach change.
I've also used it as a facilitation tool, allowing a group to discover and clarify the right work and pathways to the goal.

I'd love to hear your solutions to navigating uncertainty.

So what do we do? Have a go? Sometimes fail?

This simple approach is not unreasonable. Your solution could well be different to the previously tried ones. And if you fail fast and cheaply, you are likely to have gained new information.

Sometimes that's not enough. If your problem has to scale, if it needs to live beyond you, and critically, if you need to take folks with you on the journey, you might need to think like a consultant.

Here I offer four lenses of consultant thinking that can help move the unmoveable.

Stop and engage with the problem

"Rarely do we find [people] who willingly engage in hard, solid thinking. There is an almost universal quest for easy answers and half-baked solutions. Nothing pains some people more than having to think."

Martin Luther King, Jr.

If you don't know what the problem is or you aren't helping move towards a solution, something is likely to be wrong.

Many big problems come with distractions. Even as you are asked to solve a problem, you maybe be also passed a whole pile of associated issues, complexity, demands. The best consultants are the ones who look past these and can stare the real problem in the eye.

The key to your challenge might be getting to the heart of the problem, stopping the urgent wanting to outweigh the important, and avoiding analysis paralysis.

Be sure to take a little time to hone in on the root problem. Find some folks who can tell you about it and listen. Then think past that and seek a north star that can drive the solving forward.

Make the invisible visible

"Artmaking is making the invisible, visible."

Marcel Duchamp

Knowing the problem is not enough. We don't work in a vacuum. We likely need to take people with us, so that they can share the vision and journey ahead.

This can be done by showing folks something that hasn't been seen clearly before. Even if it's confirming something suspected, folk need to join us in the same conclusions, or at minimum, trust us that we really grok the problem.

Show your thinking. Highlight the roots of the problem, the data we have gathered, or the mechanisms we've used to highlight the troubles. It doesn't have to be rocket science. It might be just sticking pins on a board, collating conversations, or the evidence of repeating anti-patterns.

We can bring our experience to bear here. the show-and-tell can software. Hacked, scraped, just about running. Sometimes there's nothing more compelling than something that feels like the beginning of a solution.

Enable new thinking

"We can't solve problems by using the same kind of thinking we used when we created them."

Albert Einstein

To solve a gnarly problem we have to challenge the current ways of doing and thinking.

People under pressure do what they can; limited budgets and fixed cultures can result in Hill Climbing to local maxima. To truly solve someone's problem we need to shift the ways of thinking and habits so the problem does not respawn.

This might concern how priorities get set and who owns what. It's getting down to the root cause, and the root cause is always people, behaviors, culture, and attitude and sometimes it's the last thing they want to talk about.

Talk about the future, and change. Looking past, rather than at, past misdemeanors, and showing a path forward can be what's needed to release folk from the traps they find themselves in.

Empathy for change

"Empathy is really the opposite of spiritual meanness. It's the capacity to understand that every war is both won and lost. And that someone else's pain is as meaningful as your own."

Barbara Kingsolver

Empathy is the secret of a great consultant. Without empathy, you won't engage with the problem effectively or with the people whose lives revolve around it. You won't listen and people won't talk. You'll be disconnected from the real problem space.

Empathy is also needed for those honest but fierce conversations that need to happen to drive toward change. Because change is hard. We need to connect with them, and them with us, to bring trust and then honesty, and to find a way forward together.

If you boil everything down, you always get soup

"Almost every wise saying has an opposite one, no less wise, to balance it."

George Santayana

There is a natural tension between solving the problem and empathy for the pain the client might feel in the change that must happen. The plaster has to come off; do we rip it off fast or slow?

There is also a tension between collecting data (to report on what we see) and moving forward with something new. Move too fast, without a complete set of solid facts, or move too slowly and be perceived to be doing nothing to help.

Are there any easy answers to solving hard problems? Of course not.

Gerald Wienberg, the original Super-Consultant, suggests the best starting position is asking people to try something different. And then listen, learn, and iterate.

Turning a supertanker takes much time, and much must cost, the secret is getting to the right place to start quickly enough, so the turn happens in time and safely. The next best time is now.

Engineer learning and development is a big ol’ topic. In this post, I’ll focus on a few patterns, tools and techniques that help one-on-one mentoring.

One size does not fit all

Let’s begin with a little broad general advice: Personal development and skill acquisition is a spectrum.

Beginners need structure and direction. They don’t know what they don’t know.

Experts need choice, freedom and feedback. They often know what good looks like and likely have developed some acquisition techniques. They will have gaps and blind spots - that's where you come in.

Those that fall in between need enough structure to not get lost, sometimes leaning into the meta-skills of learning and generalizing. They also need to develop the ability to be self-directed.

My first recommendation is to know where folks are and act accordingly.

• Beginners/ juniors should have a clear paved path to follow.

• Journey-folks should have several paths to choose from and guidance and checks in place to help them pick well, steer and achieve.

• As people develop towards Expert, they should be able to choose and steer. Mentoring can operate more like partnering or peer-to-peer chats. Guidance, structure and checks become important again when they become stretched or are working in new areas.

Building Objectives

Progression Frameworks and Career Ladders

Skills ladders and progression frameworks are a great way to have a scaled-up impact on Engineer progression. Many companies have something like them and they can be very useful for levelling, career advancement and goal planning. I've found these can be great tools to help folk identify key goals and next steps.

If a progression framework is not the right thing, consider matching role breakdowns that call out key skills and behaviours.

Recommendation: use these in conversation, to guide your mentee to examine and increase their expertise, where it is low.

Role modelling

Some folks focus on people, not skills. They can see someone who is good, who they want to be like. This can be used in conversation and processes to identify traits and skills that can be acquired

Consider using these questions to build awareness and some goals

1. Who do you want to be like and why?

2. What makes them ace?

3. What aspects are important to the role they do well?

4. How could you get there?

Recommendation: use this in conversation when someone knows who, not what they want to be.

Taking on a new challenge

When a mentee is taking on a new challenge. A good goal-growth conversation could be one like the following

1. To achieve this, what would good need to look like?

2. What skills do you have? And how do you know this?

3. What skills do you need? And which do you need first?

4. How will you know you are winning?

Recommendation: use this with people who have awareness of what they can and have done.
Consider a more feedback-based approach if they lack key awareness or have found themselves caught by overconfidence.

Identifying goals that get done

All the above options can generate goals and at least the initial steps to achieve them.

Seeking Opportunity

Once you have found some potential objectives, your mentee needs to have the opportunity to see, to act and to learn. Together you should look for what goals align with the opportunities available, or talk about where those might be found.

Goal-oriented planning

Once you both have a clear idea of the right goals, you are going to want to plan, delegate and iterate. Using your mentor conversations to check-in, learn, adjust and replan.

I've found that selecting 3-4 key goals and collaborating on the info in the sheet below helped ownership and focused the conversation in the right places as we kept meeting.

Recommendation: put the goals into a format that your mentee can own and update; and one you both can talk around.

Needs + Opportunity + Motivation

Needs + opportunity + motivation = Useful, actionable objectives

Working with your mentees to find what they need to do and how they might practice gets you most of the way there. the mentee's alignment and ownership, together with your chats and expertise can bring together the will and way power needed to motivate your mentee even in the trickiest areas.

Mentoring centers around an extended conversation: regular, focused one-on-one chats with the person you are mentoring.

Mentoring can vary a lot; often the key duties are:

• 👂 Be a person to speak to and listen

• 👐 Offer organizational support and comfort

• 🧭 Help people navigate the organization

• 🏋🏻‍♀️ Help people grow their capability

• 🎆 Celebrate success!

These conversations can range from a free-style catch-up or follow a questioning structure. Often these chats need a little structure to help with connection, learning, listening and growth.

The Conversation Contract

At the heart of a successful mentoring conversation, there are a set of agreements.

1. It's all about the growth and success of the mentee. It's rarely the place for reporting up or collecting status updates. They should be done elsewhere.

2. The mentor should offer options and conversation areas, the mentee should say what they want.

3. If there is a timeline, or window for these chats, it should be clear.

4. The conversation starts from a point of trust, but if either party is dissatisfied it should be in the open.

Often these are not spoken about or checked in on. I very much think they should be discussed and clear.

Mentoring Conversation Formats

Without chat there would be no mentoring - it all starts here.

There are a couple of formats I've found useful to lean on to get a chat going and to build shared knowledge and rapport.

Catch up style

Catch-ups are great to keep remote and timezone-distributed people in the loop. It's perhaps the MVP of mentoring. It's not about reporting to each other. Rather, you both get a slice of what's going on and what you don't know. It's a great way of syncing and learning about each other.

• 🎁 Share what’s going on in your world/team.

• 🐢 See where the conversation takes you.

• 👂 Keep listening.

Ask 4 Questions

The 4 Questions structure is great to help a mentor step into the mentee's perspective and talk things through. It's my go-to choice to get into what's going on in the mentee's world, once we have trust.

• ⚕️ 1. How are you?

• 👍 2. What’s good?

• 👎 3. What’s not so good?

• 🧩 4. Is there something we have not talked about that we should?

A focus on growth and skills acquisition

Mentoring is all about growth, and growth conversations are best if supported with goals, direction or even a plan. If your mentee has a clear direction they want advice and support on, your conversations can center around that. If not, you can build one together.

With this in mind. growth-focused conversations often take this shape:

• 🗺️ Check-in on progression and acquisition

• 🛣️ Ask them about how to progress a step

• 🚧 Discuss blockers

• 🎊 Throw in a good challenge

I've found this style also works well for onboarding and assisting new joiners learn about their role and how things function.

Whatever style you use, listen and adapt

Mentor chats should be dynamic and adaptive. Mentors may choose a format to suit the situation and the mentee's needs, but they should also be listening to check if it's working for their mentee. Be ready to stop and reassess if you don't have the right format for the conversation.

Bring the warm blanket of trust and care, as well as the water-pistol of truth.

A key to helping someone grow at work is helping them feel safe and happy. No one learns much for long without these. Mentoring conversations should start by helping someone into this position.

Beyond that, you, as a mentor need to build rapport and trust, so you can be told and tell critical information that might otherwise go unsaid.

Active Listening is a great way to do this, as well as a way to learn and guide without dominating a conversation.

There is a lot of depth in the ways you can use conversations to support guide and grow. Hopefully, these patterns will get you re-started if you stall.

Security threats in the online world are only increasing. Organisations need their engineers to be a line of defence against threats and vulnerabilities by releasing solid and secure code.

If you are part of a security team or an engineering leader, trying to gate-keep code is near impossibility - you’ll never find that bad line of code before it ships, or even long after. Worst still, even the best analysing tools cannot spot whole classes of security coding issues.

Requiring your engineers sit though 'funny' training videos and multi-choice quizzes will neither win hearts and minds or make your products more secure. You need a different approach to bringing good 🔥.

Engage to empower

Your engineers are the folks who live in the code that runs your products and services. Engage with them and turn your risk into an asset. Let them know they are a line of defence, and what needs to be defended against. Tell them who and what the threats are (sadly, real news stories are easy to supply).

Education, Education, Education

A key challenge is that engineers are not always security aware, but as Specialising Generalists, most engineers love learning by doing. Help them think like the hackers you want to defend against and they will take better precautions.

I’ve harnessed this in literal hack-days - where groups of engineers have teamed up to try their hand at hacking challenges - seeing who can complete the most challenges in an hour.

Game-days such as these often produce delightful side-effects. A few times, post hack-training, engineers have spotted a similar avenue of attack in production code, and have fixed it up, a true reward indeed.

Where to start

Here are a few of the sites I have liked and used.

1. Google’s XSS game focuses on a single class of problem. Offering puzzles in injecting JS into pages in increasingly complex ways. Its single focus might not be a thing for everyone - but it's a great way to get the party started and its a totally common issue.

2. Game of Hacks challenges engineers to spot problems and vulnerabilities in code snippets. It supports many languages but can feel a little dry. Short bursts or on a shared / big screen could bring the energy.

3. Over the Wire host several war-games that start simple and get more and more difficult. Natas presents increasingly difficult challenges over HTTP. Bandit looks like a fun introduction at OS level hacking.

4. The world keeps changing - hackthebox.com, tryhackme.com and cybergamesuk.com look like great newer replacements for the EoL-ed Game of Hacks.

Ready to scale up? Time for a CTF?

Want to run something a little more complex for your teams? Capture the Flag events are great competitive challenges that help bring teams’ security knowledge to the fore.

I’ve not run one of these (yet) but OWASP’s Juice Shop supports CTF and offers great advice for hosting CTFs

Here's a product team game (and process) to help teams identify and avoid the disasters that might befall their product.

If you want to help your team gain a shared perspective and vocabulary on what’s important, and to build plans to make their software more resilient, keep reading!

Before I present the game, let me tell you why it's so useful.

When we make software, we forget the important

When building software we think in specifics: the things it should do for a user; the problem it solves. Great software needs to be more than that.

It needs to work night and day. Scale to support many, many users, whilst protecting secrets and assets. And when some disaster looms, it needs to be resilient enough to not crumble.

This does not always happen. Many are the tales of software failing. Breaking under load. Oversharing secrets. Data loss.

We can do better

Teams deliver better when they think and talk about disasters to be avoided. A shared understanding and vocabulary of the operational challenges leads to better designs, prioritisation and software.

In addition, this allows teams to take greater ownership often leading to learning and a more rugged (and less risky) system in production.

The Game

The aim of this game is to capture the biggest risks to your product. You’ll do this by working through a list of‘what if’ disaster cards and wildcard challenges. You’ll quickly talk about which ones apply and rate them by how disastrous they could be.

You’ll then rank your cards to find the key disasters your team needs to guard against. These then can contribute to your backlog of work or your risk action plans.

What you’ll need

You’ll need the deck of what-if cards, your Product team and a space to play - either real life or remote works, though the set up is slightly different

In real life: you’ll need the cards printed out, some sharpies and blu tack, a table to work on and a white board to rank and display your disasters on.

To play remotely you’ll need to set up a remote whiteboard with the set of cards, a play area and a place to rank and display your disasters - here’s an example Mural board.

Somewhere in your space you’ll need to draw out a big graph with ‘Impact’ and ‘Likelihood’ as the two axes

You should discard the Delivery and Scaling Challenges card for your first game. they are to be used for extended games - details at the end.

How to play

Step 1: Get everyone on the same page

Before the game can properly start everyone in the group needs clarity of what the group is de-risking. Clarify the product or feature and how it delivers value by answering three questions:

1. Who are its users?
2. How do the users get value?
3. How is it funded?

Step 2: Find your key disasters

The group should pick three cards and for each one ask: ‘What if?’

After a brief discussion (writing notes on the cards can be helpful) the group should gauge the risk of this disaster to their product. Note that financial, repetitional, exposure, loss, or health + safety are all valid risks - this is not just about technical disasters!

Ask:

1. What's the likelihood and impact?
2. What controls and mitigations would help

Once the three cards are reviewed the team should place them on the likelihood and impact graph - deciding which of them looks most disastrous.

Repeat swiftly

You should be able to work through all your cards in sets of 3, building a map of your quantified risks.

You may come across cards where you already have preventions in place - my tip here is to record that but rate the card as if it was not defended. This will allow you to see how important that defence and maintaining it is.

Step 3: Review learning

Once out of cards, the team should review their ranked disasters.

Are there surprises? Questions? Worries?

Build an action plan

Pick out the critical disasters to be avoided. Ask what can be done to manage, mitigate or control them.

You have your disasters. What then?

I’ve found two good places for managing and progressing software and product operational risks.

Risk Registers

Risk registers are a place to record and manage key dangers - those that are important to understand monitor, mitigate and control

Risk registers are super useful to share risks outside of a delivery team - they give the wider business a heads up of both the most tricksy risks the team needs to detail with, as well as risks that go beyond the team's ability to control or guard against.

Operational Requirements (and Service Levels)

If the team can manage, control or mitigate the risk through technology, infrastructure and software it should become a requirement that can be built and measured.

Not all risks can be managed by building a feature. Your risks might guide you to put in place infrastructure, SLOs and production monitoring. You might find cross-cutting concerns that can be managed through scanners, linters or checklists.

And that’s it?

Not quite. This is just the start. Most software gets built in interactive and incremental ways. Risk avoidance needs to work the same way - threaded through delivery.

With the team now thinking about the disasters that might happen to their product, the conversation should continue as work is done. The team might want to put checkpoints in place to review their decisions as they learn more, or use production measurements, reports and monitoring to indicate upcoming problems or successful controls.

Many teams have regular learning and review sessions where discussions might fit well. If not, why not try it?

Appendix 1: Running bigger games and extensions

The ‘What If?’ card deck also includes a set of ‘Delivery and Scaling Challenges’. These can be used for an extended Game of Disasters that also looks at challenges to your delivery plan.

Playing the Delivery and Scaling extension

To play this version you will need to add in extra time for the group to think more beyond the operational risks and think about the delivery commitments and work.

As well as describing the product, the team playing needs to have a shared vision of the delivery. You can do this by drawing out a future timeline on a large whiteboard.

Build a reference for discussion. Have the whole team help, by adding future team happenings, external events, commitments and expectations.

Once drawn out and discussed, play the game as usual, using the delivery risk and wildcards.

Playing with the full set of cards

It’s possible to use the full deck of cards to look for operational and delivery risks at the same time. Expect this to take a few hours - plan for snacks and breaks!

Appendix 2: Resources, further reading and research

Resources

• What if cards
• mural template for remote game playing

Further reading

This game is similar to a few other risk discovery 'games'.

• It borrows a lot from the Futurespective process - an open ended examination of a future state and the journey there.
• Threat Modelling is used to discover how your system presents Security Risks. I like the method presented at Martin Fowler's site where there's a set of seed cards for risk.

Building in ruggedness and observability builds you a safer space to ship fast and often. Here's a real-life demonstration showing the value of that investment.

We join a team that manages User Access

Users were getting stuff done on the site they helped manage. Engineers were building and shipping.

The team that looks after User Log-in received an alert in their chat room.

Something was up with the Authentication service. A fault on the log-in page.

Question one: Who's affected?

The first question to ask in the event of a live incident is: 'How is this issue affecting our users?'

Every issue has a different impact. The hope is, that with luck, the damage to users will be small. The good news was that in this case, it wasn’t was not big. They were lucky.

That Luck was self-generated. They'd built it into their systems.

How did they build this luck?

Engineers had built resilience into these systems. When a mistake was coded and shipped, the system failed well for users.

Authentication systems (like log-in) protect products. Not only does it need to be consistent in keeping people out, it also needs to be consistent and available in letting people in.

Building web frontends can be tricky. Correctly supporting every combination of every browser is an almost impossible task. Rather than expecting every change to be 100% correct for 100% of users, these engineers had bet on occasional mistakes making it to their users and built the system accordingly.

The log-in page was built to degrade gracefully. If the Javascript failed to run, the plain HTML page would continue to function.

If it doesn't break... how do you know it's broken?

The risk of having a system that handles failure well is that coding mistakes can go unseen and grow. You can end up with a bundle of bad code. A great way around this was to ensure systems will tell us when they fail, even when users couldn't see it.

The system emitted different data depending on how the user logged in. This allowed monitoring systems to keep an eye on the level of degradation. If it saw a large rise, it would let the team know, leading to this story's alert.

Jumping back to the key question: 'who's affected?'

In this incident, users were still being able to log in and access the products, so it was not a 🔥. The engineering team were the most affected - they still needed to investigate and fix. And that's the second key question I ask.

Question 2: What's the cause (and what’s the fix?)

Once the impact has been understood and control has been taken, focus can be placed on finding the cause.

The team had instrumentation output - logs and metrics. From this, they could see that the start of the issue coincided with a software release.

As the team practiced small and frequent software releases, it was a simple step to go from break ➜ release ➜ code change. It may not yet have been clear what was causing the problem, but there was a small changeset that was the likely cause.

Observing the situation

Knowing the location of the problem was not enough quite to solve it. The team needed to observe what was going on in their services and in their users' browsers to understand the problem. Detailed data about the users and operations happening on the system.

Browser fingerprints were part of the record for every successful log-in. Filtering for just the degraded logons quickly revealed a pattern in the user agent. From that, it was a small step to reproduce the broken state on the right browser and get a fix.

Build your own luck to move fast

You can build your own luck by building in ruggedness and observability. These features allow you to accept a varying level of quality without high impact and to quickly solve problems. Allowing your system to fail well.

Use these and you can keep fixing your problems as you go, shipping in small batches, which makes fault location easy.

More importantly, in combination, these support your teams to move and ship fast, getting new features to your users

Credits

Ice Cream Photo by Sarah Kilian

Design Photo by Brett Jordan