Category: Management & Leadership

In IT, “shift-left” means integrating testing, quality checks, and feedback loops earlier in the software development lifecycle (SDLC). Instead of finding problems during final testing, when fixes are slow and expensive, teams identify and resolve them at the earliest possible stage.

Interestingly, the same idea can be transposed to management.

The management lifecycle consists of defining the mission, values, processes, and structures, and then conducting the work accordingly. It is a lifecycle because management must periodically inspect how the system performs and iterate the whole system to adjust to new realities.

Instead of fixing problems late in the lifecycle, we should try to address them in earlier stages. To prevent operational problems, improve processes and structures. To prevent processes issues, improve the mission and values. ¹

Shift-left aims at fixing root causes, not symptoms. In IT, scaling issues often lead teams to add servers or optimize queries. But if the software design wasn’t built for scale, these are temporary fixes. The real solution is to fix the architecture. In management, cross-team performance issues often lead to more meetings, stricter coordination, or additional oversight. But if the team structure creates silos, no amount of coordination will help. The real solution is to reorganize teams to match workflows. In both cases, fighting operational limits treats the symptom. Fixing the underlying design addresses the cause. And the earlier you do this, the less it costs.

In IT, you can test changes on test systems before rolling them out. In organizations, this is harder. You have only one organization, and you cannot simply “roll back” a failed culture change. However, the patterns still apply. You can run A/B tests or “canary releases” by piloting new processes in a single team before a company-wide rollout. You can also improve quality through design reviews and retrospectives.

There are many workable parallels, because IT is about engineering systems, management is about engineering organizations. Both require designing for reliability, iterating based on feedback, and fixing root causes before they propagate.

1. For instance, to prevent bugs in production, improve the testing process. To improve engagement in testing, anchor quality and testing as a value. ↩︎

We have all been faced with someone jumping to conclusions. Less obvious, but just as common, is jumping to solutions.

You jump to conclusions when you overlook facts and alternative explanations. You jump to solutions when you overlook the problem itself and the many ways it could be approached. Both come from the same impulse to move fast and feel done.

Jumping to a solution can be costly. There is the obvious opportunity cost. Are you solving the most valuable problem? Is there even a real problem there? On top of that, the solution you rushed into might be the wrong one, or a decent one that crowds out a much better option you never explored.

You also miss a lot of the fun. Exploring the problem space is often the most interesting part of the work. That is where insights appear and where you actually learn something. If you jump too fast, you skip that phase entirely and turn the work into execution only.

Finally, you risk losing buy in. When you arrive with a fully formed solution, especially if you did it alone, people rarely feel ownership. At best they disengage. At worst they push back. Most people want a voice in how problems are framed and solved.

This is a lesson I keep relearning. Bring problems, not solutions.

For many years I tried to come up with a clever system to organize my digital life.

I explored systems with folder structures, categories, labels, and nomenclature. Now, I’m convinced that the simplest and most effective approach is also the least ambitious one. Go chronological.

Forget about building complex structures that should work now and in ten years. Just store everything by year. Inside each year, create a handful of buckets using whatever grouping makes sense at the time. Taxes, pictures, projects, information, things that matter at the moment. Usually you end up with five to twenty buckets.

Life changes, and this approach deals with that naturally. You do not need a future proof system. Each year stands on its own and can use its own categories. Time provides the only stable axis.

At first, retrieval sounds inefficient. In practice it works surprisingly well. Most of the time you know the year. Once you have that, finding the right bucket is either straightforward or a matter of a few clicks. Within one year, misclassification isn’t an issue. Even if you need to check a couple of nearby years and the buckets look slightly different, it is still no big deal. The approach trades classification purity with simplicity.

Searching across many years can be less convenient, but this happens rarely. And when it does, full text search exists.

Archiving is trivial. A year is done, you close it, and you move on.

Truly long lasting projects can live outside of this structure, but they should be the exception. Recurring administrative topics do not qualify.

There is also something quietly profound in all of this. Even in a long career, you will likely end up with sixty to eighty yearly folders. That is a small enough number to manage without much effort. Your life is actually short.

With 2026 around the corner, it is time to create a new folder and start bucketing again.

The first blog in the serie “Wording matters” explored principles, practices, guidelines and values. Let’s focus now on some more management talk.

1. Vision

Definition: A vision is an aspirational and long-term statement describing the desired future state or ultimate purpose.
Example: “To create a sustainable, carbon-free society where humans live in harmony with the environment.”
The vision defines the overarching dream, painting a vivid picture of what success looks like in the long run.

2. Mission

Definition: A mission outlines the organization’s core purpose, the actions it will take, and its role in achieving the vision.
Example: “To empower communities and industries to transition to renewable energy by providing innovative solutions, education, and resources.”
The mission is more action-oriented and explains the organization’s role in contributing to the vision.

3. Strategy

Definition: A strategy is a high-level plan of action that details how the mission will be accomplished and the vision achieved.
Example: “To develop and implement scalable renewable energy technologies, advocate for policy changes, and partner with global leaders to reduce greenhouse gas emissions.”
The strategy focuses on the “how” and lays out the broader framework for achieving the mission and vision.

4. Goals

Definition: Goals are specific, measurable, achievable, relevant, and time-bound (SMART) objectives that guide progress toward implementing the strategy.
Example: “Reduce national carbon emissions by 40% by 2030, install solar panels on 10 million homes by 2025, and achieve net-zero emissions by 2050.”
Goals break the strategy into actionable steps, each with clear targets and timelines.

Key Differences:

• Vision is the ultimate destination—it describes the ideal future.
• Mission is the role or purpose that drives actions toward the vision.
• Strategy is the high-level roadmap for achieving the mission and vision.
• Goals are the specific milestones within the strategy, measuring progress along the way.

By aligning vision, mission, strategy, and goals, organizations can effectively focus their efforts and resources to achieve impactful outcomes.

I gave a talk a the yearly SBB DevDay conference. It was about SAFe’s principle #1: Take an economic view. The main idea was to compare the economics of software development with the economics of manufacturing to better understand concepts like capex, opex, maintainance, debts.

https://www.slideshare.net/slideshow/inside-safe-s-principle-1-take-an-economic-view/272378146

Each year, I try to give a talk at the internal SBB Developer Conference, called “SBB DevDay”). The previous years, I gave talks about concrete technology challenges. This year I tried something new and gave a talk about development methods and practices.

I consolidated my experience and insights of the past 6 year as lead architect into a useful framework to think about software architecture governance. This perspective mixes traditional agile concepts with concepts of choice architecture.

DevDay 2022.pptx from ErwannWernli

An interesting aspect of the SAFe framework is that it tries to combine two agile mindsets. The first mindset is the iterative mindset of methods like Scrum. It’s a cornerstone of agile development and SAFe “scales” it from the team-level to the program-level, for instance with the PI Planning.

Another mindset in SAFe is the lean mindset. The lean mindset is not about iteration, but about optimising the flow of value.

Lean came initially from manufacturing where the goal is to (1) reduce the time to produce physical good, and (2) reduce the “inventory” needed in the process, and (3) reduce the “waste” produced during manufacturing. In manufacturing, managing inventory requires warehousing and logistics, this costs money. Materials that end up as waste cost money too but do not produce value. To reduce delivery time, each step in the delivery process must be optimised and wait time be reduced to the minimum.

These ideas can be translated to the software world if we consider that features under development are “inventory” and the development process is a pipeline that can be optimised. Features under development are “inventory” since they don’t produce value but must be managed. Waste is a bit harder to map but it represents all the unnecessary work that end up not being used (think of unused design document, analysis, etc.). The development pipeline can take many forms but is always a variation of define, build, verify, and release. The quicker a feature can transition in the pipeline the faster you produce value.

Lean in itself doesn’t require iteration. Iterations are needed to manage uncertainty and course-correct the product development in the face of new information. Lean is about optimising a delivery process. But the delivery process could be about the delivery of a similar item every time, like cars in the manufacturing world.

But Lean is also a great complement to iterative approaches like Scrum. In this case, the goal of the lean mindset is in a way to optimise the iteration speed. Rather than having several features with long delivery time, focus on few features and short delivery time.

SAFe emphasises the lean mindset with concepts like the continuous delivery pipeline and value stream mapping. Besides presiding over the process, the RTE are also charged to improve the flow of value in the organisation.

The lean mindset isn’t as established as the iterative mindset. I find it interesting that SAFe integrates it and promotes it. We conducted a value stream mapping session at work, and it was very enlightening. Thinking in waiting time, inventory, waste does indeed work in the software world, too.

It’s a simple way to highlight process and organisational issues. It gives clarity to what should be optimised and not get lost in organisation design. Chances are, if you want to reduce waiting time, you will have to solve a bunch of other problems first. The lean mindset positions these problems not as end in themselves, but as bottlenecks to short delivery time. It helps you prioritize these problems. It’s a bit like Test-driven Development (TDD). Making things testable requires that you figure out a good design first. But assessing testability is easier than assessing “good design”. In the case of Lean, minimising “waiting time” requires that you figure out a good organisation first, but measuring “waiting time” is easier than measuring “good organisation”.

Few years ago, I would have described a good organization as one where everyone is on the same page. By it, I would have meant exactly on the same page. I realize now that I was wrong. You don’t need to be perfectly on the same page. Being mostly on the same page is enough, and a little bit a chaos is ok.

Engineers are very well positioned to understand why: to be on the same page you need to coordinate, and coordination is expensive. This holds for actors in a software system (threads, processes) but also actors in an organization (person, teams, units). Coordinating between actors takes time, and as such slows the system. You should first try to design your system so that the need for coordination is reduced, and then if necessary, balance coordination with consistency (being on the same page).

The analogy works surprisingly well (maybe it’s not an analogy but a property of system in general?). Take optimistic locking in software systems: it’s a tradeoff between consistency and performance. Rather than lock the resource on each change, you only check when you do the final write if you’ve been working on the most up to date information. If not, you do a retry. In this case, there’s a performance hit, but overall the system is faster this way. The equivalent in an organization would be to accept that some people somewhere have outdated information. They will work based on this outdated information until a synchronization point happens and they realized the information is outdated. Some work will have to be corrected or redone. It may be upsetting, but should happen rarely.

The art of organization design is to reduce coordination and when needed use the right synchronization points. The goal is to prevent catastrophic mistakes. Some inconsistencies here and there, if timely resolved and with small consequences, are fine. Do not synchronize on everything (it’s way too expensive) but synchronize often enough to keep the risks small. Prefer many small risks than looming, large big risks.

There are lots of patterns in software system to synchronize and coordinate actors in the system. There are also a lot of patterns to synchronize and coordinate actors in an organization: all-hand sessions, company memo, internal trainings, review boards, formal processes, team meetings, etc.

Interestingly, software systems and organizations have different profiles when it comes to the tradeoffs between consistency and speed. For software systems, relaxing consistency beyond simple techniques like optimistic locking is usually hard. Transactional systems are still a lot easier to build than systems with relaxed consistency. On the other hand, an organization will always work with relaxed consistency somehow: it’s impossible for an organization to update the “collective brain” in a transaction. It’s the nature of people to misunderstand information, forget things, or simply take vacations or be sick.

Speaking of coordination and alignment, Elon Musk put it like this:

“Every person in your company is a vector. Your progress is determined by the sum of all vectors.” – Elon Musk.

What this analogy does not consider is the time needed to align. If lots of time is lost on coordination, the vectors are smaller. You then have to choose between an expensive perfect alignment, or some inexpensive imperfect alignment. Given that organizations constantly course-correct, vectors accumulate projects after projects (or task after task) and there are plenty of opportunities to adjust the alignment, even each time in an imperfect manner. This is why in a good organization, a little bit of chaos is ok.

SAFe introduces a new role in the industry: the release train engineer (RTE). A RTE is, according to the framework:

The Release Train Engineer (RTE) is a servant leader and coach for the Agile Release Train (ART). The RTE’s major responsibilities are to facilitate the ART events and processes and assist the teams in delivering value. RTEs communicate with stakeholders, escalate impediments, help manage risk, and drive relentless improvement.

The role is designed like a scrum master at the ART level. At a minimum, a RTE ensures that the process is followed. But a good RTE helps teams improve their performance – that’s the essence of the job. A RTE doesn’t have any authority over the content in the backlog. The focus on only on improvement at the organisational level. As such, the wording “assist the teams in delivering value” leaves quite some lattitude in how impactful an RTE can be.

What do you expect from a RTE? I am wondering how this role will establish itself in the industry. Here are my personal expectations.

Level I – The Organizer. The RTE ensures that the process is followed. He/She ensures that information flows between the teams using the elements of the framework. The RTE helps resolve problems related to the work environement as they appear. Example of such problem could be: tools to communicate, organisation of the program backlog, running the ART events. He/She makes sure people can work.

Level II – The Moderator. The RTE is able to create plattforms or use existing plattforms to encourge discussions in the ART / Solution. With some moderation talent, he/she can help instill change, support improvements, or create alignment. The RTE helps resolve problems about team performance as they appear. Example of such problem could be: interpersonal issues, improving the collaboration with a specific provider, managing morale in challenging time, ensuring transparency, suggesting a feature stop to address the existing bugs first.

Level III – The Influencer. The RTE identifies systemic performance issues in the organisation and work towards resolving them by instilling change at the organisation, technical, or product management levels. Example of such issues could be: addressing systemic quality issues due to the work culture, working with the system architects/teams/system team to make the continous delivery pipeline faster, encouraging decentral decision-making (while managing risks), improving feedback loops.

The higher the level, the more interdisciplinary the RTE will have to work. While little knowledge of product management or architecture is needed to be proficient at level I, problems at level II and III will require a good understanding of how engineering works and how product management, technology and processes influence each others. On the technology front, the RTE is also a key stakeholder to support mindset like DevOps, which means he must also have some good understanding of how technology supports delivery and operations.

The RTE role ressembles that of the more established delivery manager. Both focus on similar sets of issues.

The big difference between both roles lies I think in the mindset. A RTE is a coach and as such has little formal authority in itself. He leads by helping other take the right call. A delivery manager will typically have more formal authority. For instance, a RTE has no authority over the priorisation of backlog in itself. The PM and PO have formally this responsability. The RTE coaches the PM/PO in priorizing work.

The higher the level, the more the RTE works at the level of the engineering culture. It’s easy to define values and visions that nobody follows. Culture is defined by how people effectively behaves. It’s hard to be a good RTE. Just like it’s hard to be a good scrum master. Changing how people work isn’t easy.