6 posts tagged with "Software Development"

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.

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).