📜 Pre-Manifesto Era 123​

For instance, many believe the manifesto led to the creation of the various Agile methodologies we are all familiar with. Actually, the opposite is true: Scrum, Extreme Programming, and others mostly predate the manifesto.

In fact, the manifesto was born out of the necessity of putting order into all these similar-but-different disciplines.

Why am I telling all of this? Because it seems to me today we are in a similar pre-manifesto era. Many people struggle at defining what Agile really means, while successful subcultures like DevOps, Continuous Delivery, and Lean, each cover only some parts of the original Agile scope, with overlapping principles.

So a few days ago I went back to the original manifesto — kind of how you go back to the Scripture — to draw some inspiration from it.

🔢 The Four Values​

Reading the 12 principles today, they still feel very relevant. This is already an incredible feat in such a fast moving industry.

But we also learned a lot in these 20 years, and we can probably reframe these principles today in the light of such learnings.

The original Agile manifesto, with my annotations

So I started annotating the principles and extracted a few major themes from them. I chose the ones that were both the most recurrent in the manifesto, and I believe are the most important today.

Here they are:

1. 👥 Work closely with stakeholders

2. 🚚 Work in small batches & deliver incremental value

3. 🏅 Give teams agency

4. 🎨 Promote simplicity and good design

Let's explore each one and why I believe they are the key takeaways from the Agile manifesto in 2021.

👥 Work closely with stakeholders​

Good communication with stakeholders is a primary factor in any project's success, and Agile has long preached about keeping customers in the loop and welcoming requirements' changes.

This feels as relevant today as ever.

Startups move at super high speed and need to work closely with users to find product-market-fit. Larger businesses need to stay lean and react fast to market changes.

How do you know if you are doing it right? You can ask yourself these questions:

• 🔍 Are customers able to regularly review new features? Have you set up an effective feedback loop for your work?

• 📣 Are customers able to suggest new features? Are you in touch with what customers really want?

• 🏆 Do you know what success looks like? Have you set KPIs and targets for product success?

🚚 Work in small batches & deliver incremental value​

Splitting work in small deliverables is key to the health of your development process.

Small batches lead to frequent releases, which in turn make the feedback loop faster and reduce risk.

This virtuous cycle means that, counterintuitively, there is no trade-off between speed and stability in software. Higher speed brings higher stability, because it also brings faster recovery from failures.

How do you know if you are doing it right? Ask yourself these questions:

• ⚡ How fast can you release? High performing teams deploy to production in 10 minutes, and do it 10+ times a day.

• 🏃 Do you iterate on features? After a first version is delivered, do you leave room for iteration? Not doing it leads to half-assed features and turns the process from agile into a series of mini-waterfalls.

🏅 Give teams agency​

A simple way to sort high-performing from low-performing teams is based on their agency:

• Bad teams are given solutions to implement.

• Good teams are given problems to solve.

• Great teams are given the agency to find problems and provide solutions.

The best results I have witnessed in software have always been delivered by diverse, cross-functional teams who had the skills and trust to independently iterate over a product.

The manifesto got this exactly right, also highlighting the key elements to make it happen:

• 🤝 Trust (point 5) — teams should have the agency to find both problems and solutions on their own.

• 🔄 Self-organization (point 11) — teams should be able to work independently and include all the skills needed to evolve the product.

• 🧘‍♂️ Reflection (point 12) — improvement is obtained through regular retrospective within the team.

🎨 Promote simplicity and good design​

Out of 12 principles, it may seem weird that only two (9 and 10) talk explicitly about software design, but I actually think they tell everything you need to know.

Good design means minimizing the work to be done, both right now and in the future, and this mostly comes from good communication.

In fact, technical excellence comes from good understanding, as much as technical debt comes from the lack of it.

A few directions to get this right:

• ✍️ Invest in good design — this means, of course, engineering analysis, but also a lot of talking with stakeholders. Make sure you discuss both the here and now and the future evolution of the project, to be able to produce a design that stands the test of time.

• 🙅🏻‍♀️ Avoid premature abstractions — when you have limited understanding and/or limited context into the future, stick with simple solutions that are easy to refactor once requirements consolidate. Wrong abstractions are hard to remove and are the #1 source of tech debt. Even duplicating code is often better than a bad abstraction.

• 🧩 Buy instead of make — as stacks and platforms consolidate, there are less and less use cases where it makes sense to write custom, expensive code. Building something with code should be your last resort, instead of your default solution. Take advantage of frameworks, no-code and low-code tools to reduce the tech footprint of your product.

📚 Resources​

I wouldn't have been able to create this article without the several ones I wrote in the past about the same topics!

Writing them allowed me to reflect on what I believe in, and provided most of the ideas that ended up into this one.

Here are a few, organized by the four themes:

👥 Work closely with stakeholders​

• 📑 ****The Pyramid of Stakeholders** — this article explores the relationship we have with the different types of stakeholders and provides advice on how we can communicate well with them.

• 📑 ****How to Design a Communication Architecture** — in 2012, Ben Horowitz wrote that a CEO's most important duty is "to design a communication architecture for their company". This article provides a step-by-step approach based on responsibilities.

🚚 Work in small batches​

• 📑 The Four Measures of Software Delivery Performance — this article explores how delivery metrics reliably predict wider business performance and benefit your company goals.

• 📑 How Shipping Fast Changes Your Life — shipping fast is truly one of the major areas that separate elite engineering teams from average and poor ones. Here is what happens to your team when you ship fast (or slow).

🏅 Give teams agency​

• 📑 Feature Teams vs Durable Teams — a reflection on various teams configurations through the lens of ownership, resource allocation and decision making.

• 📑 The Pyramid of Engagement — in over 80 years, Gallup defined a model for workers' engagement which is based on twelve needs across four categories. Here I discuss them and provide a small framework to support them as leaders.

🎨 Promote simplicity and good design​

• 📑 The True Meaning of Technical Debt — this article dives into the origins of this widely used metaphor, why it is often misunderstood, and provides some battle-tested advice about how to deal with it in real-world situations.

Within each company, there are groups of people who are more likely to work together than others.

This is usually because of one of two reasons (or both):

1. They have similar skills: they check their respective work, find solutions and develop practices.
2. They work on the same project: they do different things, but they all contribute to a same output, so they need to coordinate.

Creating teams means defining processes that make it easier for these people to interact on a regular basis. So you want to create teams around people that work together the most often.

There exists a large body of literature on how to organize teams — based on skills (functions), projects (squads, cross-functional teams) and everything in between (matrices of various kinds).

One angle that is less frequently discussed, though, is time.

How long is the life of a team? How long are these people going to work together?

Based on this coordinate, two main configurations exist:

• 🎯 Feature Teams — teams assembled to deliver a specific initiative. Will be dismantled afterwards.
• 🎽 Durable Teams — teams accountable for a long-lived product / business area.

Choosing to go with one or the other (or anything in between) is an important decision to get right — as it has a cascading impact on almost every process: leadership role, reporting structures, career progressions, and so on.

It’s also not trivial as it depends on the stage of your company, its size, and how the business works.

I had the chance of working in both situations and each approach has its own merits, so I will add my own perspective.

Let's compare the two methods by the three coordinates that I believe are the most important:

• 🍱 Resource Allocation — Flexible vs Fixed
• 👁️ Strategy & Decision Making — External vs Internal
• 👑 Ownership — Weak vs Strong

🍱 Resource Allocation​

Flexible vs Fixed

Feature teams have flexible resource allocation. They can be scoped based on the project they have to tackle and the velocity we want to achieve.

Durable Teams, in contrast, have fixed (or slow-changing) allocation.

Upsides of flexibility are obvious: they allow you to allocate resources precisely for your goals. This is especially crucial in small companies, where people often wear many hats and projects have overlapping resources.

This is also good in fast-moving environments, such as startups, where it's tricky to identify stable areas of allocation.

The downside of such flexibility is it requires more work and negotiation for the allocation itself. If every initiative requires a roundtable for deciding how resources should be organized, it may become a big tax on management time.

👁️ Strategy & Decision Making​

External vs Internal

Feature teams don't live long enough to be able to take on strategic responsibilities, therefore strategic decisions are usually taken outside of the team. Feature teams tend to work at execution level, after a direction has been defined at leadership level.

Durable teams, on the contrary, allow for full strategic thinking within the team itself. This usually works better in the long run, for two reasons:

• Whenever possible, decisions should be taken by people with direct information about the matter. This is akin to the Information Expert pattern in software development.
• The team becomes fully accountable for the project, making people more empowered and engaged.

👑 Ownership​

Weak vs Strong

Feature teams, being temporary, cannot retain ownership of their project. Such knowledge is eventually retained by individuals, or transferred to other teams.

For this reason, developing a long-lived initiative with a feature team always poses the question of how to manage maintenance, changes and any future evolution efficiently.

Durable teams, instead, retain strong ownership of their domain, and stay accountable for it from top to bottom.

⚖️ Choosing between Feature and Durable teams​

It's easy to see how durable teams lead to strong ownership, efficient decision making and hassle-free resource allocation.

However, their viability depends on two major conditions:

1. You are able to define permanent business / product areas and these can be served with a predictable amount of resources.
2. Your company has enough headcount to comfortably distribute people into multiple, independent teams.

These are no small feats.

Small companies and fast-moving environments — such as startups — have a hard time at being productive with durable teams. They more often stick with feature teams until the conditions above are met.

Mixed solutions also exist: you might be able to identify a few durable teams and leave the rest of the headcount to feature teams.

📌 Takeaways​

Here are the main takeaways from the article:

1. 🔍 Choosing between feature teams and durable teams is a crucial task that has a cascading effect on most of your processes. Do your best to get it right.
2. 🎽 Durable Teams are arguably better for your company — as long as you can define long-lived areas and you have enough people to distribute across such teams.
3. 🎯 Feature Teams provide the flexibility needed by small companies and startups, but pose ownership and decision making problems.

As an Engineer with an individual contributor role, chances are your job is quite clear. You may work on a product, write new features, maintain existing ones, and overall advance the tech assets of the company.

When you step into a management role such things change, because—as they say—your product becomes the team.

Your job becomes to make sure your teammates are successful at what they do. And for that, you want them to be engaged.

Engagement​

Engagement is an all-encompassing metric that has risen in popularity in the last decade.

It refers to the feeling when you are not just happy of your work — you actually get a sense of belonging and fulfilment from it.

Engaged employees are happier and more productive. But what makes them engaged in the first place?

The Four Categories of Needs​

Gallup is one of the oldest U.S. firms studying management and workplace dynamics.

By surveying more than 35 million people, in about 80 years of activity, it came to develop a model of their needs, called The 12 Elements of Engagement.

Such elements belong to four categories:

1. Basic Needs
2. Individual Needs
3. Teamwork Needs
4. Growth Needs

These categories form a hierarchy, which is somehow akin to the Maslow's pyramid of needs. This means that each category can be properly addressed only if the lower ones have already been met.

Let's have a look at the categories and the 12 elements.

🚶‍♂️ Basic Needs​

Basic Needs represent the baseline for any kind of performance. People can't work properly without having them met.

• 1 – I know what is expected of me at work
• 2 – I have the materials and equipment I need to do my work right

🏃‍♂️ Individual Needs​

Needs about yourself and your individual contribution.

• 3 – I have the opportunity to do what I do best every day
• 4 – In the last seven days, I have received recognition or praise for doing good work
• 5 – My supervisor seems to care about me
• 6 – There is someone who encourages my growth

🤼‍♀️ Teamwork Needs​

As human beings, we want to develop a sense of belonging to a larger group of peers. In this case, it's our team — and our company.

• 7 – My opinions seem to count
• 8 – Mission / Purpose of my company makes me feel my job is important
• 9 – Fellow employees are committed to quality work
• 10 – I have a best friend at work

🧗‍♀️ Growth Needs​

Finally, people want to reach their full potential, and feel their job makes them grow personally and professionally.

• 11 – In the last six months, someone at work has discussed my growth with me
• 12 – In the last year I have had opportunities to learn and grow

---

In the most recent Gallup survey, only 1/3 of respondents resulted actively engaged at work. About half are neutral, while 16% are actually disengaged, or completely detached from their work.

The problem with disengaged people is that they also bring down others. A small percentage of unhappy people is enough to jeopardize engagement in everyone.

How can you support these needs as a leader?​

The 12 elements make for a great start to reflect on the status of your team. Just put yourself in the shoes of your people and ask yourself the same 12 questions. The first time I tried, I was embarrassed I hadn't great answers for many of them.

I believe there are four fundamental behaviours you can apply to address these needs, on a regular basis:

1. 🚡 Remove obstacles — do people have everything they need? Are they stuck with something? Clearing the way—even on simple things—is one of the most straightforward ways you can contribute. Sometimes just showing up and asking if there's something you can help with goes a long way.
2. 🤝 Delegate — provide input at the beginning and feedback at the end. In the middle, encourage autonomy. Autonomy creates ownership, which in turn nurtures motivation and growth.
3. 🤗 Coach and support — Show up, listen actively, give feedback and praise. Use your 1:1s to build a connection with individual team members.
4. 🗺 Provide context and processes — they foster teamwork and make people feel they belong to something bigger than themselves. As a leader, provide clear direction and have transparent reviews and retrospectives with your team.

❓ Why Technical Debt Happens?​

If you search for "Technical Debt" on Google and look at excerpts from the first page, you will find some kind of consensus.

a few Google results for “Technical Debt”

It looks like it is something that accumulates because of some nasty, dirty practices. If true, it should follow that by writing clean code from the start (and documentation, and tests, etc.), debt never piles up, or it does in a negligible quantity.

Of course, if you have any experience working in an engineering team, you know this is false.

Technical debt creeps in even when you work with the best intentions, and follow the very best practices.

But why?

🔍 Technical Debt as disagreement​

Enter this short video by Ward Cunnigham.

Ward is the original inventor of the "Technical Debt" term, and it's revealing to hear the sentence in which this metaphor was used the first time (emphases are mine):

If we fail to make the program aligned with what we understand to be the proper way to think about our [...] objects, then we are going to continuously stumble into disagreement, and that would slow us down like paying interest on a loan.

Ward describes debt as the natural result of writing code about something we don't have a proper understanding of.

He doesn't talk of poor code — which he says accounts for a very minor share of debt.

He talks of disagreement between business needs and how the software has been written.

But how do we land to such disagreement? In my experience, there are two offenders:

• 🎨 Wrong Design — what we built was wrong from the start!
• 🏃 Rapid Evolution — we built the right thing, but the landscape changed quickly and made it obsolete.

Let's see both more in detail 👇

🎨 Wrong Design​

It may happen that the team designs a solution that doesn't properly fit business requirements, in a non-obvious way.

Requirements may still be met on the surface, but something is wrong under the hood — an abstraction that doesn't fit, some duplication, scalability issues, and so on.

Of course, such things may happen because of poor development skills. But in my experience, most of the times it's because developers didn't fully understand what had to be done.

How to improve? 💡​

If this happens regularly, a natural response is to invest more in the design phase. This means, of course, more engineering analysis, but also more talking with stakeholders. You should discuss both the here and now, and the future evolution of the project.

Tech Debt vs Design Effort — you should find the sweet spot

Increasing Design effort brings diminishing results after a while, so it's up to you to find the sweet spot, based on how solid is your company planning vs how much change you can expect in the future.

🏃 Rapid Evolution​

The second scenario is when things change so rapidly, that today's requirements cannot really be trusted.

That is: even if we build the right thing, it risks becoming obsolete fast, because of the ever-changing business landscape.

How to improve? 💡​

A thorough Design phase provides limited protection against future changes, so a leaner cycle might work better:

1. 🏃 Rush — the code out of the door
2. 🔍 Learn — more things about your business reality
3. 🔨 Refactor — put that learning back into the software

Basically, we take a piece of the Design effort and move it forward, in a Refactoring phase that happens every time a few pieces have consolidated and are ready to be secured.

In this scenario, we are accepting the creation of debt, trusting our ability to repay it in the short term

This ability comes down to three elements:

• Writing code that is clean to refactor — which is very different from clean. Such code is similar to those sailor knots who should be strong enough to hold for a while, but easy to dismantle when not needed anymore.
• Actually learning along the way — analyze, with the help of stakeholders, what still fits and what is going to become debt.
• Spending regular time on refactoring — reorganize the code periodically to reflect your updated understanding. This is easy to dismiss, letting the debt pile up until it’s too late and you need a big rewrite. Taking baby steps every time is more sustainable both for your business, and your development team.

📌 Takeaways​

As always, I try to summarize the main points of the article in this final section.

This should be useful for the reader, but it is also a reality check for me to understand if what I have written makes sense from top to bottom 😅

So, if you are in a hurry, that's what you should remember:

1. Technical debt is caused by a lack of understanding — it stems from disagreement between business needs and how the software has been written.
2. You can limit such disagreement... — by spending more effort on the design phase, and by properly discussing requirements with stakeholders.
3. ...or you can embrace it — by explicitly planning for lean releases and following rework. This is a better choice when the future is uncertain and might bring radical changes.

🏯 Communication Architecture GGGHH123​

What is a Communication Architecture? It is a system that defines how stakeholders of a process exchange information.

It is a heated topic today, because people know this needs to improve. Common advice you find focuses on two axes:

• ✍️ Written over Verbal communication — create more documentation and share it with stakeholders instead of transferring information in meetings.

• ⏳ Async over Sync communication — prefer async exchanges that do not block everyone's time, and structure your work in a way that you don't need instant feedback from anyone.

This is actually great advice, and you will find several instances of this approach led by successful companies — from radical ones like Doist and GitLab, to Amazon's culture of written memos, and more.

The only problem is that, in most cases, this is just tactical advice. It can improve your communication, but it is not going to fix it if it's broken.

Replacing a meeting with a shared document can be great, but what if it was the wrong meeting from the start?

So let's try to think at communication on a strategic level. For any given process we want to analyze, let's consider four elements:

• 🔍 Scope – inputs, outputs and goals of the process.

• 🏃‍♂️ Activities – the steps required to take inputs and transform them into outputs.

• 👥 Stakeholders – people involved and their role in the process.

• 🧱 Artifacts – given all the above, documents, tools and rituals we can setup to make communication happen properly.

Let's see them one by one 👇

🔍 Scope​

You are not going to fix communication for the whole company at once. More realistically, you can take a single process and make it better.

Your company is made of multiple processes. They have overlaps and each feeds into the other, but you can also think at them in isolation, as pieces of a pipeline. A few examples might be the quarterly OKR planning, the bi-weekly development sprint, or bug reporting.

Let's take the development sprint as an example. What are its inputs and outputs? Simplifying a bit we have:

• ➡️ Input: ideas about new features

• ⬅️ Output: working software available to users

The process is successful if:

• Things we develop actually work and are good for users

• We are able to sustain a good pace over time

Now that we have inputs, outputs and goals, let's make a step forward and check individual activities.

🏃 Activities​

Activities are the steps required to transform inputs into outputs. For a dev sprint the following happens, more or less:

• Analysis – Data and ideas are collected. Things get prioritized and scheduled to be done.

• Requirements – Specs are produced about each feature.

• Design – Tech and UI design is created. This is the a plan of what needs to be done.

• Development – Actual code is written against the specs.

• Review – Code is reviewed and features are QAed.

• Release – Features are released to users.

This is what needs to be done, which is largely an independent problem from who has to do it.

Being able to decouple these at a conceptual level allows you to think more clearly about responsibilities, scaling and automation.

👥 Stakeholders​

I use stakeholders as a loose term to include any person involved in the process in some way. For each stakeholder, their involvement also changes based on the activity you consider.

In my opinion, the holy grail for good communication in a project is being able to map each stakeholder onto each activity, and define their role for it. If you do this right, then it's all downhill from there.

But this is also the hardest part, because it requires setting boundaries.

Sometimes, even if a person has the skills to help with something, it doesn't mean it should. You should always strive to define clear roles in order to set people's expectations correctly and create ownership.

One useful tool to reason about this is the RACI Matrix. This framework considers four major types of responsibilities for a given task:

• 🔨 Responsible – those who actually do the job. There must be at least one responsible person for each task.

• 👑 Accountable – those who ultimately sign off the job and are answerable for it. They typically provide requirements and do the final review. There is at most one accountable person for each task.

• 🤝 Consulted – those whose opinions are sought but do not work directly on the job. They might be domain experts or customers of the product.

• 📣 Informed – those who are kept up-to-date on the status of the job. Communication with them is one-way, and might happen only at the completion of the task.

A sample RACI matrix for a product dev team

For each step of the process you should be able to fill all the RACI roles. And ideally, each role should be played by a separate person.

The latter is not always possible, especially in small teams, and that's ok. But doing this exercise is important as a reality check on the health of the process. In fact, for any missing or overlapping role you can ask yourself specific questions:

• 🚫 🔨 No Responsible – who is going to do the job?

• 🚫 👑 No Accountable – who is going to review the job?

• 🚫 🤝 No Consulted – do we really have all the info we need?

• 🚫 📣 No Informed – who cares about this?

🧱 Artifacts​

Once you have a clear picture of the activities and stakeholders involved, you will have an easier time at setting up the building blocks to make things happen, like meetings, documents and tools.

This is a broad topic that would require a whole post by itself (👀), so this is some advice to start with:

• Use meetings only for 1) urgent, 2) complex or 3) personal matters — in other words, make sure the high "bandwidth" that meetings guarantee is put to good use. Most other uses like Status Updates, Reviews, or Announcements can easily happen via documents and async communication.

• Be aggressive in involving only the relevant people — based on their role in the activity. People should join meetings not only to receive information, but also to contribute to it. Those who are only Informed can be kept in the loop in other ways that do not block their time.

• Don't be afraid of using multiple tools — as long as boundaries are clear, this is rarely an issue. For example, it's totally acceptable to have a project mgmt tool focused on the dev experience (e.g. Jira), and another which is more high level (e.g. Trello, or a Google Doc) to display a recap for non-technical stakeholders.

• Display only information that is relevant to stakeholders — that is, tailor how to present things based on who will see them.

A few weeks ago I run into this great list by Camille Fournier. It is about soft skills every senior engineer needs, and I joked it was so good I had to turn each item into a newsletter article.

It turns out it was no joke — this week I wrote about #13, that is how to communicate project status to stakeholders.

I love this topic because keeping stakeholders in the loop is probably the single most important factor for any project's success. And it is often overlooked, as many people are more comfortable working head-down until results are supposedly delivered.

Or are they?

Communicating with stakeholders often and effectively makes sure we stay on the course and are able to adjust when we drift away from it.

So let's start with the basics — what is really a stakeholder? 👇

Behold, the Stakeholders! 📢​

Stakeholder is one of the most abused words in product and engineering. It is a very generic term that refers to any person who has an interest in the project — at any title.

The abuse comes from the fact that these interests can be so different, that there are very few situations where it makes sense to group them together and use stakeholder as an actionable word.

The same mistake is often made in communication: by considering stakeholders as a cohesive group, we are tempted to keep everyone in the loop in the same way. This is bound to fail, for two main reasons:

• 🔍 Different interests — people are interested in different kinds of status updates.
• 🗣️ Different languages — people have a different level of understanding of what's going on.

Good communication entirely depends on your capability of tailoring the right message to the right interlocutor, which in turn depends on your understanding of:

1. What they want to hear from you (interest)
2. How you can say that effectively (language)

To get both right, let's split stakeholders into a few categories, and give to each their own 👇

The Pyramid of Stakeholders 🔺​

In my experience, there are three major categories of stakeholders for a product:

• 🎽 Team Members — people who develop the product.
• 👤 Users — people who use the product.
• 💼 Business Stakeholders — people who want the product's success.

These categories are interested in radically different things, and communication should adjust accordingly.

They form a sort of pyramid that goes from the lowest, operational level, where the most interaction is needed (team members), to the highest, strategic one, where sparse and concise updates are enough (business).

Let's have a look at each category 👇

🎽 Team Members​

Team Members are those involved in product development. They include, for instance, Engineers, Designers and Product Managers.

These people need to stay in the loop of development activities, down to the details of what needs to be done.

Communication should be structured around some kind of production cycle (e.g. a weekly or bi-weekly sprint) where features are planned, developed and reviewed.

This is the lowest level of granularity for communication — as people need to coordinate every day about things to do.

👤 Users​

Users are those interested in using the product — they benefit from its value proposition.

Communication with them is about getting feedback on what has been developed and ideas on what to develop next.

How do you get feedback from users? Here are the two effective ways:

• 🔍 Involve them in demos and reviews — have a few representative users participate in periodic meetings (e.g. Sprint Review if you do Scrum) where you present them new product features, and let them give you detailed feedback. Make sure you do this regularly, as a ceremony. Here is an example of how to run these sessions online.
• 🤗 Create a community around your product — build a dedicated Slack/Discord space for users of your product where they can suggest features, report bugs, and comment new releases. Several companies do this today — I particularly like the Obsidian approach, that puts community front and center on the product website 👇

It is also crucial how you communicate such features in a way that is comprehensible. If you track your work on a development tool (e.g. Jira, Clubhouse) chances are tasks there have a lower granularity than what Users need to know.

Users are only interested in the headlines, not the implementation details or how you split the work with your teammates.

To keep communication clear and separate from what you do in the trenches, consider these approaches:

• 🗺️ Setup a dedicated space for displaying your roadmap — this might be as simple as a Trello board, or something that allows for user interaction, like Canny. It should contain the high level items of what you are going to release, written in a way that is understandable by non-technical users.
• 📬 Deliver periodic release notes — deliver release notes for each relevant update. You can do this via email, on a dedicated page, and even with notifications inside the product itself. There are several tools that help you with this, like ReleaseNotes, or Canny itself.
• 📣 Leverage the community — if you went for the community route, you can announce new features there in a dedicated channel. This is my favorite option — it gives you more feedback and keeps engagement high. Check out below another example from Obsidian itself.

💼 Business Stakeholders​

Business Stakeholders are mostly interested in the business outcome of product usage. They don't necessarily care about single features, but keep the pulse of high level KPIs.

To keep them updated properly, and make sure their expectations are met, you should get two things right:

• 🎯 KPIs + Targets — make sure you have a definition of success everyone agrees with. This includes what metrics to track and what targets should be met.
• ⏱️ Cadence to review KPIs — schedule periodic moments to review KPIs, get feedback and discuss the status of the project. A common mistake is to set goals and then let months pass without anyone knowing how things are going.

Last week I discovered that the "10x Engineer" idea had officially become a meme.

I also learned it was originally born out of real findings from a 1968 paper, titled "Exploratory experimental studies comparing online and offline programming performance". The authors showed that the performance ratio between the worst and best programmers was ~10.

I have never been a great fan of this idea. Not only I don't find it particularly useful as a mental model, but it is dangerous too. It easily leads to justifying toxic behaviour, and to creating ridiculous interpretations of the engineering work.

My modest proposal is to shift our focus from 10x engineers to 10x teams.

Great teams make great engineers, while viceversa is not guaranteed.

Everyone who has been in the industry for some time has an intuitive understanding of what separates high performing from low performing teams. If you happened to join a few in both categories, you may have noticed what things look like:

• ⬆️ High performing teams spend their time delivering features and moving the business forward.
• ⬇️ Low performing teams spend their time fixing things, waiting for things (code reviews, deploys, each other) and fighting with things (infrastructure, their tools, each other).

Sounds familiar?

So, how do you create a high performing team? 👇

⚡ Ship fast and often​

I am not going to say “that’s it” — but we are pretty close!

After surveying 2000+ companies between 2013 and 2017, Nicole Forsgren, Jez Humble and Gene Kim proved that what separates elite engineering teams from average and poor ones, is mostly how fast and often they ship.

Now you might argue that correlation is not causation and maybe speed is just the natural byproduct of other things that actually make a team a great team. But I am going to take a stance here and say that no, shipping fast and often is really what you should optimize for, and this alone over time lifts you at a whole another level from those who don't.

❤️ Shipping is your company heartbeat​

In 2013, Intercom wrote that shipping is your company's heartbeat. This is a great metaphor and it stood well the test of time. I believe for two reasons:

1. Just like with heartbeat, if you don't ship you die.
2. Shipping should be just as regular and unremarkable as a heartbeat.

What is less intuitive, though, is how your team's behaviour changes based on how fast or slow you are able to release things in production.

A simple thought experiment 👇

⏱️ Release takes 1 minute​

• Feedback loop is instant, no context switch.
• Shipping is continuous — natural extension of development work
• Time to recover is low, few outages
• Confidence is high

⏲️ Release takes 10 minutes​

• Feedback loop is good, multiple releases are made every day
• Some context switch happens during/after deploy
• Higher QA investment is justified

⏳ Release takes 1 hour​

• Multiple features are batched and released together for convenience
• Failures increase because of batching
• Recovery is slower because of 1) slow deploy and 2) context switch
• More time is spent on QA and tests beforehand to avoid disaster
• "Only in the morning" releases

🗓️ Release takes 1 day​

• Deploying becomes a formal process that needs approval
• Only "at start of week"
• Dedicated engineering work is needed to maintain the deployment pipeline
• Frequent outages, pressure on SREs
• Development vs Infrastructure feud arises, teams hate each other, morale plummets

💸 Being slow costs real money​

A slow release process costs real money because it makes you need more people.

You will need more QA because diffs are bigger and reviews are longer, you will need an SRE team to manage outages, you will need DevOps to build tools for these manual deploys, and you need will Managers to run this all.

So how do you prevent this? How do you ship fast? 👇

🚚 Automate all the things​

Remove as much human intervention from the deployment process as you can, by investing in a solid CI / CD pipeline. That is:

• Continuous Integration — automate the integration of changes into the main software project. This includes running tests and creating artifacts.
• Continuous Deployment — automate the deployment of software changes on a production environment, without the need of any human intervention.

The whole point of doing CI is to being able to do CD. That is the final goal. So:

• ⚡ Keep working on speed — with modern stacks, it is often the case you can literally deploy in 1 minute. But whatever technology you use, do not settle with anything more than 10-15 minutes.
• 🤖 Remove manual checks — or vastly reduce them. When deployment is fast and each release is small, risk and time to recover are so low that most times it is better to release and (possibly) recover than waiting for further checks beforehand.

Also, to help you with this:

• Do not batch releases together. Deploy one changeset at a time to 1) deploy more often, 2) reduce risk and 3) improve ownership.
• Use Feature Flags — decouple deploy from release by using feature flags. They remove bottlenecks and let you deploy without waiting for — e.g. — manual QA.

Nicole Forsgren, Jez Humble and Gene Kim surveyed more than 2000 tech companies between 2013 and 2017.

They focused on software delivery, to understand which practices accelerate development, and in turn bring the most value to companies.

Their work had to validate two major theses:

1. Software delivery performance can be measured in a meaningful way.
2. Good software delivery performance predicts wider organizational performance — that is, it actually brings value to companies.

They succeeded in both and wrote their findings in a book, called Accelerate.

Accelerate is a cornerstone work for software engineering, as it backs decades of theories with real, indisputable data.

It contains several insights, the most important of which is about speed.

⚡ Focus on Speed​

One of the core ideas of the Agile manifesto is that we should break functionality into smaller and smaller items, so we can deliver value faster, and create a better feedback loop.

This principle pre-dates software development, and was actually made popular by the Toyota Production System, or Lean Manufacturing, in the seventies.

Quick delivery proved to be crucial in the automotive industry, and did the same for software — especially in the last decade, with cloud computing and modern toolchains only accelerating the trend.

Most Agile frameworks, however, grew to focus more on the managerial aspects of work (Scrum, Kanban), leaving aside most practical guidance for software delivery.

Accelerate purposely focuses on the latter.

It defines four major metrics for measuring software delivery performance:

1. ⏱️ Delivery Lead Time
2. 🚀 Release Frequency
3. 🔨 Mean Time To Restore
4. 🔥 Change Failure Rate

These are not the only possible metrics to be considered — but are the ones that have been found to be most correlated with wider, organizational success.

Let's see them in detail, together with target values from high, medium and low performers.

⏱️ Delivery Lead Time (DLT)​

Delivery Lead Time, for a given feature or initiative, is the amount of time that goes from the commit to the release in production. It is a subset of the overall Lead Time, which instead covers the whole cycle from ideation to release.

Why measuring one instead of the other?

Lead Time includes analysis and design phases, whose duration can vary a lot based on the breadth of the initiative.

However, once the initiative itself has been broken down in multiple deliverables, the delivery process should move in short and predictable cycles, which are more useful to measure.

Target values:

• High performers: less than one hour
• Medium performers: between one week and one month
• Low performers: between one month and six months

🚀 Release Frequency​

Release frequency is how often the organization deploys code for their primary service / application.

It is a good proxy for batch size — that is the average amount of work that gets released in a single time. Reducing batch sizes was one of the key insights provided by the Toyota production system, and we will see that it has a similar role in software development too.

Target values:

• High performers: multiple times per day (on demand)
• Medium performers: between once a week and once per month
• Low performers: between once per month and once every six months

🔨 Mean Time To Restore (MTTR)​

MTTR stands for how much time is needed to recover from downtime / issues introduced with the latest release.

Target values:

• High performers: less than one hour
• Medium performers: less than one day
• Low performers: less than one week

🔥 Change Failure Rate​

Change Failure Rate stands for the percentage of releases that result in downtime / severe issues.

Target values:

• High performers: 0-15%
• Medium performers: 16-30%
• Low performers: 31-45%

🔍 Analysis Outcome​

Analyzing these numbers, and matching them with other organizational indicators (profitability, productivity, market share), researchers got to three key outcomes:

1. Software delivery performance matters — high performers in software delivery are twice as likely to exceed organizational goals as low performers. They also have 50% higher market cap growth, over three years, compared to low performers.
2. There is no trade-off between speed and stability — high performers do better at all measures. Actually, delivery speed brings stability, by means of faster recovery from failures.
3. The gap between high and low performers is incredible — often being 100x on a single measure. You have companies that deploy once every few months, and others of similar size, with comparable tech assets, who do it multiple times a day. That says how early we still are in adopting efficient tech practices.

The overall conclusion is that improving these measures has a crucial impact on both speed and quality of software delivery, and health of the overall business.

How efficient Engineering delivery enables the creation of better products, faster.

Frequent releases enable delivering value faster (speed), which in turn allows for faster feedback from customers, which enables faster improvements on the product (quality).