IT - what was important yesterday and what will be important tomorrow

Over the last few years, not only the way the IT industry operates has changed significantly, but also its perception by business. Today's standard was difficult to imagine a few years ago, and today's challenges are only a foretaste of what business will need in the future.

Yesterday

The operational activity of many companies took place mainly in the off-line world, where IT and software development only supported their operation, and advanced on-line technologies were not crucial to achieving an advantage on the market. Many organizations were based on monolithic IT systems developed over the years, requiring costly refactoring emerging along with the need to integrate with new business elements. This was often the reason why IT was perceived as not responding quickly enough to the new needs of the business side. With limited budgets, IT departments had to implement solutions that continued to generate technological debt (on a smaller scale, but still). Buzzwords such as Agile, AI, Big Data, BlockChain, Marketplace, Micoservices, and the Cloud began to appear, being a breath of the upcoming new approach in IT.

 

Today

Currently, we all understand that efficient IT systems are not only necessary for the proper functioning of many organizations, but also often constitute the source of their competitive advantage. Customer expectations, and thus also business expectations in this field, resulted in a significant increase in IT budgets, which translated into an increase in the demand for IT specialists, and thus their price on the labor market. Thanks to new technologies and flexibility provided by the cloud, macro-services, machine learning, and the increasingly better understood Agile methodology, IT is able to deliver business value faster and tries to catch up with the ever-growing business needs. Hybrid and remote work have become a fact, although we are increasingly seeing the threats they pose.

 

Tomorrow

In the future, we will further automate the software development process, thanks to which we will be able to deliver new stable and reusable IT solutions necessary for the expansion of our business even faster. Flexible, self-scalable and self-learning IT systems will become a natural element of the organization's development. Maintaining the coherence of hybrid / remote working teams and their commitment to the company will become a key challenge, increasing the importance of team management and thus the demand for leaders. Strong and flexible IT in an organization will become like electricity at home - obvious to everyone.

How did Agile "land" in your organization?

The word "Agile" is one of the buzz words that some time ago was spoken by everyone and in all circumstances. Many organizations "implemented" Agile and expected spectacular results that ... did not come. The great hype about this methodology is becoming more and more common, and we increasingly see that the topic is a little deeper than we thought and a bit more complicated.

How is it with Agile then? Works or not?

Yes! Properly used, it works very well. It's like a road roller - it will be the best tool for leveling the road, but you will try to swim with it ... you will sink.

Does this mean that we use Agile incorrectly?

There are many factors that favor the use of Agile methodology. There are also many environments and projects in which Agile will not help. Agile is a bit more than a methodology and goes much deeper in the way the company operates than we think.

How do we implement Agile?

Agile "implementation" often requires a change in the mindset of a significant part of the organization, which is neither easy nor quick. Therefore, usually after the initial success and a series of IT training, the organization claims that the implementation has already have been completed, even though only the first step towards agility has been done. Often, after a period of initial euphoria, there is a time of first disappointment with agility and wondering if it works properly.

Agile on the side of software suppliers

Nowadays, on the wave of a general trend, every software supplier declares that its organization is Agile. Unfortunately, in the vast majority we can come across one of several cases:

• The organization only claims to use the Agile methodology while the whole team works as usual. The customer pays for a specific amount of resources while the supplier juggles resources between projects. To find out about it, It is enough to ask for the name list of developers assigned to us with emails and telephones, and then check from time to time how often they answer questions to find out that they are now not on the subject of our project.
• The organization is divided into small teams that have kanban boards and does daily morning stand-up meetings. It's a little better here than in the previous case, but often, apart from these two elements, nothing else happens. The team often fails to deliver what has been declared in the sprint, and the project manager creatively explains to the client that this is what agility is all about and then gradually transfers the unfinished tasks to the next sprint. Over time, the supplier's PM builds large time buffers to show that his team is getting in time, but the effectiveness of such an organization is very low.
• The organization is divided into small teams that are dedicated and tailored to projects. The basic principles of Agile are followed, and tasks from each sprint are implemented in time. The problem begins to appear when we want to release a product because it turns out that quality does not quite meet our expectations, which means that SCRUM at the level of the team itself works, but at the level of project management it does not quite work.

Often, suppliers also use the word Agile as an excuse for poor management of the project itself. "Since the client pays for each day of the sprint team, he can also pay for the day of delay." Let's keep in mind that agility does not release anyone from delivering the agreed sprint scope on time.

Agile on the client's organization side

Agile "implementation" usually starts with the IT department. Project managers and engineers learn that instead of working on a requirements document, they will now be working on user stories. A tool supporting task management is being implemented, and a whiteboard with yellow stickers appear in the room. Everyone organizes daily stand-up meetings. We have enthusiasm for a while. After several months, however, it turns out that:

• Projects implemented in Agile tend to drag on forever
• Business owners behave like children in a candy store - every few minutes they are at a different shelf and want everything
• PM is pushing more and more functionalities into every sprint because the dates are running out
• After a few months from the start, it turns out that the project is not delivering the expected functionality and additional resources are needed to complete it

Why is this happening?

In a standard approach, IT is responsible for final user satisfaction. In other words - If the finished product does not suit the users - this is an IT problem. So IT has analysts, who describe what exactly is to be done. It is done at the beginning of the project, through a series of workshops with a business client and business users. The disadvantage of this solution is that it is often impossible to do it accurately enough or business conditions change over time (often also business owners changes). Sometimes, users do not know precisely what they want until they see the finished product, then it turns out that "a few" additional functionalities are still missing.

Agile meets the problems described above and reverses the situation slightly. IT is only a service provider and contractor, and a significant part of the analysis is carried out by the business. IT still helps, but the involvement of the business side is significantly higher.

And here the problems begin, because it turns out that Agile has not been fully "implemented" in business and the business side is not aware of the benefits, risks, and potential problems associated with Agile. In particular:

• The business side is not fully aware that the burden of analysis rests on it and most importantly prioritizing of what will be done through the project
• Since never before, no one asked the business side how an application should be made, and now suddenly business side can decide, it begins to decide, and generates many changes focusing mostly on non-essential additions instead of the most important elements of the new product
• Because the conditions around the business change frequently, the backlog changes often, and thus the direction of application development is altered. In moments of panic, the business owner pushes another "critical" functionality into the current sprint or even adds new features during the sprint.
• Sometimes the business prerequisites necessary to perform IT tasks in a sprint are not ready before the sprint starts and the project team gets them only a few days before the end of the sprint.
• A business owner without experience or proper training is not able to correctly set the priority list for tasks, allowing to deliver a working project on time by focusing on the essential elements only.
• The organization as a whole is not yet ready for agile projects and does not give the business owner sufficient autonomy. As a result, having no other choice, the business owner is under pressure and adopts more and more insignificant changes coming from project stakeholders.

It is clear that the business side has a difficult position here. In the case of Agile, all these activities require much more time from the business than with the traditional approach. The role of the business owner is much more important here. An organization that wants to act agile must be prepared to delegate 100% of the business owners time to the project, instead of adding the project as an additional element to current tasks.

It is one of the fundamental problems that arise in organizations that are starting to use agile methodologies because it requires changing the approach and communication of business with IT and acquiring the necessary competencies on the business side. What's more, it is often necessary to make further changes in the organization, such as developing project management competences on the business side.

If we go further and want to provide software on a continuous basis - using DevOps, Continues Integration and Continues delivery, allowing for even greater agility, the organization must change even more (this time more on the IT side). Thus, Agile initiates a whole series of far-reaching changes in the organization, which implementers are often not aware of at the beginning of the journey towards Agile.

If for some reason we stop our walk to agility halfway, we will not be able to take advantage of its benefits even though we will bear its costs. That is why Agile is more of a business philosophy that ultimately covers a significant part of the organization and goes far beyond IT. Well implemented Agile can significantly accelerate the implementation of some IT solutions. It should also be clearly emphasized that the delivery of some projects will still be more effective using standard methodologies.

Can your mobile application handle a million users?

Most organizations, sooner or later face the need to implement a mobile application. While writing the application itself is quite simple, the problem begins when the application grows and begins to have more than a few million users.

It turns out that other rules apply when creating a mobile application for 10-100K users, and different when writing an application for several million users.

Many companies dealing with mobile applications are good at projects for a small number of users and face a severe problem when the number of users increases significantly. When choosing technological solutions or a provider of such solutions, you must consider what volume of users we plan to have in 1-2 years, so as not to rewrite the entire application one year from the first release.

The small number of users

An application for a small number of users does not require much. Most are code written on a mobile device. For the application we have some CMS (bought or written), a local user login system, some simple error tracking, and basic Analytics. The back-end usually stands on only a few servers, which can be enlarged if necessary. Sometimes, frameworks are used to create applications that allow you to create a user interface faster. Sometimes, to solve the problem of writing codes on two platforms simultaneously (IOS + Android), Xamarin-like environments are used.

And it works for small scale applications.

A large number of users

Writing the application for more users, we find very painfully that:

1.       Errors

When a fatal error occurs in the mobile application, and we learn from it through the opinions of users in the Google or Appstore store, it means that:

• The error has been present for at least several days
• We have a significant number of users who are not satisfied with the application
1% of users with 10K population = 100 people
1% of users with 1M population = 10K people - the chance for negative reviews in the Google store or Appstore increases significantly.

Even if we immediately take action and fix our error - it will take 1-2 months for the new version to propagate to 80% of users' devices (time before users upgrade the application) - in the best case, with a massive marketing campaign, we'll go down to about a week. Even if the error has no financial consequences and only reputation is the problem, it will decline significantly during this period.

2.       Performance

The mobile application, especially with a large number of users, often becomes a powerful marketing tool that companies willingly use. While our servers can handle the "average daily traffic" of users, triggering a marketing campaign that causes the activity of many users at a given time, such as promotions, can overload our servers. Standard databases (even on top machines) may not be able to handle all the necessary requests in a short period.

3.       CMS - Content Management System:

After some time, we start to notice that some of our users behave similarly. Therefore, we extract groups of users in several dimensions and adjust the elements of the application to the expectations of these groups. The more groups we separate, and the more we adapt our application, the more the complexity of our CMS will grow.

We will quickly conclude that automation would be useful, and thus the connections with other systems in our company. Then there will be a moment of truth of the flexibility of our CMS system, which we chose earlier, and the costs associated with new interfaces and expansion.

4.       User Database

The decision on the user database architecture is usually made at the beginning of work on the application. Often, at this stage, we decide to create a separate database only for application users because it is a cheaper solution. As the number of users increases, we naturally begin to see the benefit of communicating with mobile application users also through other channels and also in topics not related to the application itself.

Such a change of approach can, at this stage mean expensive adaptation and unification of user database modules in several applications throughout the company. Besides, we have a whole set of GDPR requirements to be met for more than one system at a time, on different types of data.

5.       Monitoring:

In addition to the critical errors that we face in the mobile application, there will also be smaller errors that will make the use of certain functionalities troublesome for users. Some of them will not be 100% repeatable, difficult to reproduce, and thus, information about them will reach us with a long delay. The problem here is not the size of the error but its impact on users. An error that occurs only once in 1000 launches of some functions in the application, with a population of 1M users can mean several thousand dissatisfied users a day.

In this situation, it will turn out how important it is to accurately and deeply track errors in the live application code. In these cases, even error recording applications available on the market may not be sufficient.

6.       OS Actualization

Manufacturers of mobile phones update the operating systems of their devices several times a year.

Sometimes, however, it turns out that our application or library that the application uses does not work 100% under the new version of the software on a specific phone model. When this happens, we have very little time to react because a well-functioning application may stop working correctly on thousands of devices overnight.

The speed of reaction is decisive here. If we learn about the problem from users, as in previous cases, it means that a significant part of them have already encountered the issue. Simple application monitoring systems will also not help much, because such problems rarely cause application crashes. Of course, the time needed to resolve the error inside of the library used by our application is correspondingly longer.

Without proper monitoring combined with appropriate application architecture and automatic live tests, this type of problem can be severe.

7.       Different versions of one functionality

The implementation of new features in the application used by a large number of users means that each new feature is "tested" by many users. Our internal tests must, therefore, be restrictive. However, when errors appear, we must bear in mind the fact that the new version of the application will not replace all the old ones in one day and for some time we will have several versions running in parallel. If the bug fixes force changes on the server side then for some time there will have to be 2 or more parallel interfaces that need to be controlled and then deleted after some time.

8.       Integrations

During the lifetime of the application, the number of servers necessary for its proper functioning, as well as the number of external servers that supply the application with data will increase significantly. Usually, such external servers are created by different teams or different companies. So every time a single server stops working, and the whole application will suffer, the component suppliers may blame each other, claiming that the error was not on their side and their SLA have been kept.

Of course, there are many other problems, such as interruptions in WIFI, battery with GPS, map positions, other UX behavior on IOS and Android, speed and availability of data transfer from cellular networks, etc.

So what can we do to make our application deal with a large number of users and increasing complexity?

Each of the problems listed above can be addressed in several ways, depending on the priorities.

The most important are:

• Application should be written in a way that allows dynamic error tracking in a production application on the side of users at least five levels:
• Source code
• Application error monitoring
• Monitoring of source code errors (separately DEBUG separately RELEASE)
• Monitoring of connections between systems
• Monitoring of system versions and live automatic tests

This approach allows tracking the operation of the application in real-time without being surprised that something is not working properly and take corrective action as soon as the problem arises, and even before users manage to express their dissatisfaction.

• Server part should be prepared in a flexible and scalable way so that it is resistant to temporary increases in the number of users using it. If needed, our servers will be able to scale to the desired size.
• The application is modular, and we can control all modules separately, and our CMS allows a lot of flexibility to automate processes. Our UX can be easily changed.
• The user base is well thought out and works with other systems in the company.

More complex application is the more activities around it need to be taken.

Costs - the solution must also be cost-optimal. By creating a mobile application you can easily fall into several traps from which the output to a larger scale can be a bit expensive. So, each element needs to be addressed in such a way that our monthly costs are not higher than necessary.

How to be more satisfied with your IT system provider?

In today's world, the vast majority of companies use external suppliers at least in some of their IT systems. In the previous part we have described the common problems like:

• BUZZWORD
• LOW ENTRY PRICE - WATERFALL
• PAY FOR OUR PROBLEMS – AGILE
• THE RIGHT PERSON MAKES DECISIONS
• PROMISES
• “I DO NOT KNOW AND DO NOT WANT TO KNOW”
• THE CUSTOMER DOES NOT INVOLVE
• THE CUSTOMER HAS NO VISION OF ITS SYSTEMS
• SAVINGS MAXIMIZATION
• TOO MANY SYSTEMS WITH ONE SUPPLIER

and here we will propose some tips which can be used to avoid them.

"What should you do then?"

Surprisingly there are just a few rules that you must follow, at least in part, to avoid problems in the future. (Of course, the list of rules can be extended)

Sometimes compliance is not easy in some business environments, however, the more attention we pay to them, the less chance we have for future problems.

The selection of a supplier should take place with the participation of at least several equivalent bidders. 

This requirement seems obvious. However, often the supplier "enters" the client's company in a way that suggests that it is the only entity on the market offering a given service, and the buyer withdraws from the planned tender procedure. Therefore, we should keep in mind that the IT world is full of great companies ready to meet clients needs.

Too many systems with one supplier. It may happen that a client satisfied with the previous implementation entrusts the implementation of subsequent key systems in the company to the same supplier. While this is desirable on a small scale, the customer must be careful not to entrust one supplier with too many important systems. The supplier, knowing that he has a dominant position, may begin to dictate the terms of the client, manifesting in overstatement of subsequent changes or long implementation times. It can also offer the client old technologies that will allow savings on the supplier's side, as well as higher operating costs on the client's side. This phenomenon is called "Vendor locking".

People who have an idea about technology should participate in discussions with suppliers from the very beginning. 

Technical people can look at the service offered pragmatically and recommend the best solution in terms of technology and support, and thus the subsequent costs of "operating" the system. Although their voice does not have to be the most important, it avoids many wrong decisions appearing at the beginning of the process.

The client should have a vision of IT systems and environments development.

It seems crucial to understand that the development of IT systems is also part of business, even though it often affects revenues only indirectly. Therefore, the client should allocate some resources for coordinating IT development because their costs usually turn out to be lower than the savings resulting from planned architecture development.

The customer should be involved in specifying the requirements.

In the case of Agile, this means delegating a person to assume the function of  a Product Owner (PO) for the entire duration of the project. In the case of the waterfall methodology, a strong commitment to defining requirements, followed by final tests and product acceptance. Without such involvement, the project may fail despite the best intentions and the commitment of the supplier.

The customer should supervise the supplier's activities. 

The requirement seems unnecessary at first glance. However, it often turns out that the project can get stuck in a trivial place or drift in the direction that the client didn't want to go.

If we run projects in the Agile methodology, even more significant commitment and constant contact with the supplier is required because the work result is delivered in intervals and the client must continuously monitor progress, backlog, and set task priorities.

Estimation of costs and profits in the long run.

When implementing a new system, you need to think carefully about its use strategies in the long run and calculate the TCO - Total costs of ownership, e.g., for five years, taking into account additional changes introduced in this period, infrastructure, licenses, etc. Often, after such an analysis, it turns out that that incurring slightly higher expenses for initial implementation saves a lot more money at a later date.

Analysis of manufacturing processes on the supplier's side. 

Under challenging projects, it also happens to analyze software development processes on the supplier's side, to assess at the stage of its selection how the subsequent cooperation will take place. It is not a frequent phenomenon and requires excellent competence on the client's side, but it allows you to avoid many costly mistakes, especially in sensitive or expensive projects.

Of course, there are many more elements to pay attention to, such as negotiation and monitoring of SLA, impression in a traditional way or DevOps, selection of the optimal environment (server room or cloud), costs of system changes, supplier's experience in new technologies, supplier technology partnerships with large market players determining the technologies used. The selection and proper management of the supplier are therefore crucial for matching the supplier to the customer and translates into subsequent costs of system development and support.

"How much it cost ?"

Does it mean that I have to have large IT team to cover it all? NO! 

You don't need a large team to provide the minimum support. However, it should be clearly said that the level of competence of people on the client's side delegated to IT projects will have a significant impact on the result of ongoing projects. Sustainable expenditure in this area can quickly pay back and save significant amounts at a later date.

In many companies, doubts arise when we compare costs vs profits directly at spreadsheet. A hard digit representing the cost of implementation often wins in a collision with difficult to estimate costs that will appear at a later date. As a result of focusing only on the lowest implementation cost, we often get a higher total cost of the system spread over years of operation, less flexibility and the associated smaller system capabilities. Thus, the length of the time horizon considered for an IT system can have a significant impact on costs.

Are You manage your team effectively?

How do you manage your team? Is it just a group of people, or do they form an efficient team?

Team - The magic word. We all take care of the team, motivate it, invest in it, integrate it, etc. We want our team to be simply the best.

... And ... Then life comes ...

The market is "difficult", there is a shortage of employees, the budget is always too small, the client is very problematic, people have to work after hours, there is never time for integration and training, and the number of projects only increases

OK. What can we do about it?

Take the actions. Seriously! If we take small appropriate actions, and if we take them successively, after some time we will reach a magical state in which, after the project is completed, we will be able to look at our team and feel pride, not only because the project was a success but also because the team exceeded the limits of what we thought was possible.

How do you do it?

There are no miracles here. There are several elements that need to be addressed and kept an eye on. It won't be easy the first time. And ... the next time you will still have to spend some time :)

1. Recruitment & team composition

Recruitment is a critical stage in the formation of our team. If we have the chance to recruit new people, we must do it carefully.

In the current world where we try to save every 5 minutes, I believe that taking the extra moment to understand the candidates will ultimately bring us much more significant savings in the future. So let's take a few moments more to better understand the candidate's CV or ask a few additional questions during the interview, or let us invite a candidate whose resume is not entirely clear to us but he has the potential

Let us not give in to stereotypes saying that people who have been fired from work or with holes in their life or simply other than the market standard should not be taken into account. On the contrary, such people often (but not always) prove to be more valuable than the average mass.

Before we start looking for new candidates, we also need to think about precisely what kind of people we need. Not in the sense of position but the sense of place in the team. We need to think about what role individual members will play in our team, so that the team is as effective as possible

It may happen that we will have a real star in our team who will prefer large and difficult topics, we can also have people who prefer small and simple tasks. We may have those who can set standards for others and those who will comply with them. Our job is to find the right place for each team member, where he will feel best and where will be able to give the most.

2. Integration

For many managers, the recipe is simple = once in a while we gather everyone for an integration trip and sometimes go out for a beer with the team after work. Nevertheless, we won't achieve any spectacular results if we don't go further.

Integration is a team activity - thanks to it, team members work together more easily and effectively. So we have to find a way for team members to perform more tasks together.

• These can be repetitive activities that require interaction with others, which are performed periodically by someone else.
• These can be short trips to conferences (usually they are cheap, and one day outside the company without a sophisticated agenda gives you a chance to change the team's optics.)
• These can be workshop tasks in the office during which all team members will be involved and where the result will be the work of the team (e.g., the team can come up with a new process or internal procedure.) 
• These can be internal training done by team members for colleagues.

And more ...

3. Tailored Tasks

Each team member is different and has a predisposition to something different. Our goal is, therefore to find the right tasks for each individual. Tasks in which he/she will be able to prove itself 100%, e.g:

The best developer may feel great being able to solve a difficult problem or find a well-hidden error. However, if we ask him to write documentation of what he did - he may take it as the greatest punishment. We may also have team members who will not write the algorithm as quickly as others, but based on frameworks created by others, they will refine the application and make small adjustments.

So, tasks depend on the environment and predispositions of team members. Dynamic matching of these tasks is also essential so that everyone is happy to do what they do. Keep in mind that preferences can change even a few times a year, so it's a continuous process.

4. Management

Here are the basic elements:

• We do not use micromanagement,
• We give as much freedom as possible, but we firmly require a minimum of artifacts necessary for the functioning of the project.
• We check the status of work regularly, but not often
• We help! - Helping is the most crucial point here - our goal is to help our people achieve their goals because they work for us.

5. Motivating

What motivates people ...?

There is nothing new to discover ...

• VISION
• GOAL
• Participation in decision making
• Responsibility
• Teamwork
• Communication and Integration
• Manager's person - description below
• Rewards – not money based
• Money :) - Yes, there are some conditions in which this method works - but this is the last element on the list, and the situations where we should directly use money as a motivator are very rare. I invite you to my article on motivating and money.

6. Appreciation

Every employee from time to time exceed the average level and do something exceptionally well. It is important to appreciate it and to appreciate it publicly so that others also want to feel appreciated.  In this way we can significantly increase the efficiency of the entire team.

From the other side, if it happens to you that a team member did not perform as much as he should and failed, then according to the rules, instead of admonition, we talk with such person 1: 1. and check what went wrong and why, instead of showing our dissatisfaction. We need to show tips for the future and ask about the lessons learned. Constructive feedback is critical here.

7. Manager

Yes, It is no surprise that the team leader has a significant impact on his team's effectiveness.

Experienced manager:

• He knows what to do not to tire the team on a challenging project.
• Anticipate emerging problems and react before you have to put out the fire.
• He will address the problems of the project, and will correctly match the team to the given project.
• Coordinate the project's business activities with team activities to solve potential problems before they occur.
• He will take care of motivation, integration, and most importantly, team communication.
• He will address emerging problems instead of avoiding them, hoping that the team will deal with them on their own.
• When a problem occurs in a team, it will solve it instead of duplicating.

It's no secret that the effectiveness of the entire team, depending on the manager can vary by 200% or more. So the same team doing the same project can be 2x more effective (or 2x less effective) depending on who manages it.

It must be remembered that the use of the elements described above requires a certain amount of time. However, this time is more than paid back. Creating spaces for our team can be compared to creating a highway for cars (our developers). On the right track, you can develop high speeds and race against others. If the road is narrow and bumpy, we'll enjoy getting to our destination.

Are you overpaying your developers? Productivity vs. Salary

Do your developers earn adequate money for their effectiveness? Maybe you overpay for some?

It seems evident to us that those who work more and better should earn more. Sometimes, however, we have the impression that this correlation is not so clear. So what does it look like in a typical project team, and what can you do about it?

Let's consider the IT developers

Imagine a big hall full of IT developers - let's say, 100 people. For simplicity, 

let's assume that they were all employed at the same time by the same recruiter and earning precisely the same amount of money +/- 20%.

How big the difference in efficiency can be between the weakest and the best developer ...?

I can almost hear voices saying that there will be a Gauss curve... Sure, it will be a Gauss curve, but what value will it have?

Let's try to estimate how much the effectiveness of 2 developers may differ?

10%.....?......20%.....?......50%.....?......100%.....?

The Answer:

The subject was scientifically tested several times over the past several years, and the observed results ranged say the difference between the worst and the best programmer around 10 TIMES! YES! Side-by-side developers can vary in efficiency by ten times or more.

Can the difference be greater? - There is no limit. The most significant difference I have personally seen was around 100 times. Nevertheless, to simplify the further discussion, let's stick to the x10 multiplier.

Since the difference is so significant why developers earn almost the same amount of money?

An essential element here may be seniority (junior/senior) Senior earns, of course, more than junior and it can be assumed that the length of the internship may slightly affect its effectiveness, but in reality, the multiplier x10 is not expected here. A person who works for a long time does not have to be more effective than a person with relatively low seniority.

How often have you seen a developer who is five times more effective than his colleagues and earns only 20% more, and leaves after some time because he does not feel appreciated?

How often have you seen a developer who is five times less productive than his colleagues and earns almost as much as his colleagues despite working much less effectively?

What can we do?

Let's focus on three essential elements that will allow us to increase the overall effectiveness of the team.

• Appropriate recruitment

• Measuring effectiveness and developing knowledge

• Suitable team composition and adaptation

OK. Can we measure the real efficiency of developers?

At first glance, this seems simple; We can ask the developers to write the same algorithm and see who will do it faster...

Unfortunately, this is not so simple, and the more we explore the subject, the more we will understand that we are trying to compare pears to apples.

Does this mean that developers' efficiency cannot be measured?

It can be done! Should be done! The truth is, however, that we can't easily translate the number of lines of code, time spent, issues fixed or errors found into the real effectiveness of programmers. Reliable measurement must take into account several factors, preferably over a more extended period.

OK. Let's assume that we have measured the effectiveness of our developers.

Is it not enough to get rid of the few least effective, and significantly raise the salary of these top developers?

Not necessarily.!

Let's not forget about point 3 above.

Without developing the right composition of the development team (the last of the 3 points above), the other 2 points are of little value.

Throwing out less effective developers from the team is not always the best solution because they can sometimes play an essential role in the team. Similarly, a significant increase in the salary of the best developers (the measured ones) can generate more demanding attitudes.

Besides, it should be taken into account that less efficient people can perform other vital roles in the team that we are not even aware of. Removing them from the team without analyzing the composition of the team can do more harm than help.

And here we come to the point - sometimes it is not as important as the effectiveness of a single developer, but how effective is the whole team with its participation.

Moment, Does this mean that you can't do anything or you don't have to do anything?

You have to do it!
You have to measure efficiency, but... it won't be 1 KPI.
You have to pay more for the best but... not x10 and not directly to everyone.
You have to deal with people who add nothing to the team - but...
You must also take into account factors other than efficiency.

&….

The most important thing is to arrange the team, rules in the team, how to work, and to adapt roles and tasks to make the teamwork well.

Only then, treating these elements as a whole, can we say that we have a good team.