Requirements in software engineering are a living thing. As we develop the software or as the software is used in day to day business, new perspectives are revealed that require us to adjust the original requirements. As the requirements change, so does the planning of the software and this often causes friction between the stakeholders and the engineers, therefore, we must develop our coping mechanisms to accommodate this constant change to minimize this friction. Let us discuss the reasons behind the change and how can engineers do requirements negotiation.

Why do requirements change?

As the business circumstances change or new facts emerge, so do the requirements for the software. While this change of requirements is something mainly disliked, at the same time it is something that in most cases cannot be avoided or prevented. The very thing we need to do when requirements change is to get a clear understanding on all sides about the why. Why do we need to change the requirements. It is not easy to list all possible change categories, but most often you will see one of these root causes:

• New information has emerged about a previous assumption
• Management has decided to pivot the project direction
• There has been a change in the market (e.g. competition, new customer requirement, etc.)
• New legal requirement has come up

No matter the change reason, it is very important to understand the background so you know the importance of the change. When you know the why, chances are higher that you will empathize with the requestor, rather than thinking they did not do their job properly when writing them. This sets a better baseline on both sides when trying to find the best solution how to move forward.

What can we do when the requirements change?

As engineers, when we analyze a change request, we try to think it through all the perspectives that we can imagine. We think what do we need to do to implement a certain requirement, what can go wrong and how can we prevent it, what kind of quality measures we need to put in place, etc. This is a complex process with a lot of, usually unspoken, variables in it.

As an outcome of this process, we propose a solution and give a delivery estimation. Usually, this estimation is taken into calculation of the implementation timeline and is announced to stakeholders, turning it into a commitment for engineers. This is exactly where the problem arises. If the requirements change, the implementation needs to be re-planned, maybe re-worked if the work is in progress and chances of delivering on previously promised date start to decline, a fact very often dismissed by the business stakeholders. Often, change of the deadline is highly opposed and it becomes a blame game. From my experience, I have learned that:

Change of requirements is not the problem, the problem is the inadequate communication of the cost of the change

To escape this blame game, we need to do a fact based discussion laying all the cards on the table, show the viable options we have in front of us and guide the stakeholders into choosing the next step. This way we make sure that everyone is aware of the cost of the change and no one is blamed for not delivering on the promise.

The triangle of change

Before we discuss how the change of requirements can be negotiated, let us first understand the dimensions of change, which I like to call the triangle of change. When the requirements are estimated, engineers usually think of what needs to be done (the scope), the quality of the solution (automated testing) and come up with an estimation on how long will it take to implement the change. But, when the requirements change, there comes the triangle of change in play.

The triangle of change shows that one can hold at max to two of the points and has to sacrifice the third. Meaning, one can choose to:

• Hold on to scope and quality (green vertex) -> sacrifice deadline
• Hold on to scope and deadline (yellow vertex) -> sacrifice quality
• Hold on to deadline and quality (blue vertex) -> sacrifice scope

Once this is understood by all parties, then the negotiation can begin.

How to negotiate the requirements

It is also often the case that change is requested while holding the expectation to the same estimation, scope and quality standards. How can engineers address this situation constructively? This is the framework that I generally use:

1. Listen to understand the motivation behind! You need to understand, why are the requirements changing now and how pressing this is.
2. Ask if we can de-scope something else or extend the deadline. Out of the three dimensions of the triangle, you want to avoid lowering quality at any cost (this will haunt you back), so adjusting the scope or postponing the deadline is the most desired outcome.
3. If you should hold onto the deadline, then see all the options you have to adjust the scope. Offer the requester a couple of alternatives together with the associated cost. Make it transparent, what decision leads to what outcome. Agree together!
4. Communicate the “new agreement” openly to all stakeholders.

To illustrate this better, I will go through two scenarios to demonstrate the use of the framework:

Scenario 1: The engineer is working on integrating an online payments provider’s checkout process into an application. This work is estimated at 10 work days. The work is in progress at about 50% and will be finished in 5 days. And… here comes the product manager with a new announcement. The CEO has negotiated a better deal with another provider and you need to integrate this new one. How would I go from here?

1. I would first asks questions to understand what exactly does this change mean. Do we need to drop the previous integration or do we need to complete it plus add the new integration. Ideally, I would also try to understand the rationale behind. When knowing the why, it is a lot easier to accept the change positively.
2. I would ask for some time to analyze the integration process of the new provider. I would estimate what parts of the already done work needs to be dropped and what can be reused, thus estimating how much more time I would need to complete the integration of the new provider with the same quality and same scope. I calculate the delta and explain to the product manager what is the cost of this pivot.
3. As implementing payments’ integration is a crucial feature for the product, I go ahead and analyze quickly if we can also do a feature breakdown and see if can deliver it in chunks, meaning still hitting the initial deadline with a smaller scope and then complete the rest of the work after the first release. So I come up with two alternative paths we may walk and their associated cost and outcome.
4. Having gathered all these facts, I would have a talk with the product manager and present them all the options we have.
   1. Adjusting the scope and go live with a minimal version
   2. Extending the deadline to accommodate the new requirements
   3. Lowering the quality (I TRY TO AVOID THIS AT ALL COST)
5. Try to agree together on one of the options, or if we cannot, then ask for further input from other stakeholders
6. Communicate the decision in the team transparently so everyone is a ware what is happening.

Conclusion

Change is the only constant. During the development of a software, requirements change very often and getting comfortable living with the change will make your life easier as an engineer. Using the above mentioned negotiation framework can help you deal with those situations better and smoother agreement with your business stakeholders on changes and consequences with less stress and frustration.

Software Engineering teams usually have a very special evolutionary dynamics. Often they start small and stay like that for a while, or better to say, until the solution gains traction and the feature requests start to overflow the team’s capacity.

It is usually this late stage when companies start adding people, but hiring takes time and the teams have to survive. Trying to cope with the load and push for the speed, usually teams start to allocate similar tasks to same people. Of course people working on the same parts of the software are faster than the rest who seldomly contribute on those areas. Speed is a factor of convenience on many perspectives, therefore usually the evolution of these knowledge siloes is tolerated, until it becomes a problem. An engineer goes on vacation, every change on their silo-part slows down, or halts altogether. Or even worse, an engineer leaves and the whole team falls in chaos as no-one knows the “black box” of the other.

In my two decades in software engineering, I have very often encountered situations of knowledge siloes, in small as well as large companies. Almost always, the intention behind was benign but at the end in one way or another it caused annoyance to everyone.

Knowledge siloes are bad for both individuals and the team. They can be fixed, but it requires a systematic approach and discipline

The role of Engineering Manager in fixing knowledge siloes

Engineering Managers (or Team Leads) are often pushed to focus on delivery as this is their primary responsibility. Very often, the pressure to deliver faster comes from multiple directions. From the desire to achieve the team targets, to business objectives and all sorts of other circumstantial requirements. However, knowledge siloes are a sort of technical debt that haunts the team (and the company) later, therefore needs to be addressed systematically.

As the responsible person for the team, Engineering Manager is also responsible to make sure to create and facilitate the culture of knowledge sharing. Engineers should have the time for knowledge sharing and it is the Engineering Manager who has to make that possible. The team should be enabled and supported to do so. Knowledge sharing should be part of the process and not a handover task, therefore it should be incorporated in the regular delivery flow of the software.

Effective Strategies for Knowledge Sharing

What are the strategies that you as an Engineering Manager can follow to effectively address the challenge of knowledge sharing? Here are some that have proven to work well:

• Writing comprehensive documentation
• Conducting thorough PR reviews
• Holding team presentations for major updates

Writing Comprehensive Documentation

Writing documentation (e.g. on Confluence, Notion, etc.) could be a remedy for saving the knowledge from people’s brains onto a shareable space. Especially if you need to document large concepts such as architecture, complex business decisions etc. Documenting on such central tools also helps with organizing knowledge and long retention. The main drawback about this strategy is that after some time documentation tends to be outdated. Unless a rigorous discipline for updating is applied, this effort can go waisted very quickly. Stale documentation is not trustworthy, therefore no one will read it.

Actionable advice:

• Document only long living concepts (e.g. high level architecture, business decisions, legal requirements, processes, etc.)
• Book time in your planning to update the documentation. If something changed that should be updated in the documentation, this should be a written task done following the implementation of the change (do not put somewhere down into your backlog :))

Conducting Thorough PR Reviews

If done properly, I would consider the reviews as one of the most effective ways to share knowledge. It is the live documentation of what the code does. At the same time, the reviewer understands the transition from how it was to how it will be after merging. The disadvantage, if in a hurry (which often is the case) people tend to do the review superficially, not paying too much attention to understand it properly.

Actionable advice:

• Make it a rule, every change should be PR reviewed
• Push for small PRs. Human brains cannot cope with too many variables at the same time. It’s difficult to review a PR with 10+ files
• Let the team feel the responsibility jointly. The reviewer is as responsible of the change as the implementer

Holding Team Presentations for Major Updates

This is one of my favorites, especially if major changes are introduced. Sometimes things cannot get documented so quickly, also not everyone can be involved on every part and every review, therefore you have knowledge leakage. Such team presentations are intended to bring everyone on the same page by presenting the latest developments and changes introduced. At the same time, giving everyone a chance to ask questions and gain more understanding. The downside of this is that it is time-expensive therefore not feasible to do too often.

Actionable advice:

• Every major change should be followed with a team presentation
• Even if you have no major updates, make such a presentation at least once a quarter. It serves as a refresher for the team as well as make everyone aware how much you have achieved in that quarter.

My favorite strategy for know-how sharing

All of the above mentioned strategies work well and have their benefits. At the same time, they have a common weak point: human laziness. Humans are lazy by nature (I guess this is a good thing, we need to preserve energy), therefore these practices have a tendency to degrade over time.

The documentation gets outdated as people don’t find time to update it. PR reviews start to get done fast because people start to pay less attention or are in a hurry. Tickets get written fast and in less details. If we can skip a step because we are in a hurry, then we will do it. But, there is this one thing that we cannot skip is, and it is the code that goes to production.

Therefore, my favorite long term strategy has two rules:

• Code is the documentation
• Everyone works on all parts of the codebase that they can

Let me get a little deeper on these two concepts.

Code is documentation

The only documentation that does not get outdated is the code that is running on production. The only exception to this would be complex business logic and agreements which can be documented somewhere else and usually they don’t change often therefore less risk of getting outdated.

The code should be written clearly and tested reasonably well. Test scenarios serve also as specifications/requirements documentation. In test cases one sees what the code should do and what should not. From them, most of the code should be explainable. If the team holds on to this principle with discipline and hones the craft of writing well tested code, the knowledge sits in the code base and not only in the brains of individuals.

This kind of documentation, will not only make it easy for people to touch most parts of the codebase, but it will also make the onboarding of new engineers a lot faster and efficient.

Everyone works on all parts of the codebase that they can

The key to spreading knowledge is the necessity for having it. Yes, we can encourage people to learn more and we can support them to do, but our brains are mostly wired to hold the information we deem as absolutely necessary, the rest tends to slip away. If people have to touch different parts of the application, their contextual memory of those parts will be fresh and it will be easier for them to jump from one part to another. Also, this will lead to a more concise implementation style across the application.

I hear you asking, but how can everyone work on every part of the application. The key is in the part “that they can”. Of course we would not expect a frontend engineer work on backend tasks and vice versa (unless you have full stack teams), but they work on all parts of the codebase that falls inside the limits of their specialization. In other words, every backend engineer work on every part of the backend codebase.

Short term vs. Long term

Your actual situation will decisively influence which strategy you will and can follow. As for everything, there is no silver bullet to this problem, but the above mentioned strategies certainly help to achieve knowledge sharing in engineering teams.

If the need is for short term, I would recommend go for quick documentations, reviews and know-how sharing sessions. If you want to play long term, I have seen that my strategy works quite well, but it requires the team to work together at least 3+ months to start seeing any tangible benefits. It requires patience and a lot of stakeholder explanations. At the beginning it will slow down the team, but long term you will go far with this.