The most valuable developer in the team is …

… the one who increases the productivity of their team members.

You don’t have to be a team/tech lead or an architect to do things that boost the team`s performance. Even a middle-level developer can cause the impact.

Motivation

Why should you care about colleagues’ performance? Because making things that improve the team performance saves money for the business. The team can do more for less time. The ability to make such improvements makes you valuable for the business. For the current and future employers. It’s a win-win situation, good for the business, and good for you.

• it can facilitate your promotion
• it looks great in your CV
• it highlights your professionalism in the job interviews

Here are some ideas, on what to do to boost your team.

Metrics

I added some hints concerning metrics of how the impact can be measured. The metrics are super important. I believe that everything should be estimated in numbers. Numbers mean more than words. With figures at our disposal, we can effectively compare the impact of the different approaches. Moreover, we can track progress over time, enabling us to contrast our current situation with that of a year ago.

Metrics play a crucial role when communicating with non-technical managers. People from the business side don't care about code and tech stuff. They care about money. And all the number metrics can be calculated into money one way or another. It’s a good way to highlight your impact on the project's success.

I think the suggested metrics are the weakest part of the article, though. Please, post a comment if you have better ideas to estimate a developer's impact on a team’s performance.

Documentation

In my job, I follow the Rule of Two (invented by me 😄). It says

“If a colleague asks me a technical question about our project, and later another person asks me the same question, it makes sense to add an article/post in the project documentation with the answer, because most likely I will be asked about it again.”

The idea is that the next time someone has the same question, they will quickly find the answer in the project documentation. It saves their time and my time as well. Saved time = more money for business.

What things are worth documenting?

• various guides. How to set up the local environment. Checklist for a good code review. How to perform typical product-related tasks. For instance, how to update the prices in your e-commerce product to test various corner cases. How to create a new user in the CRM.
• code conventions and coding practices established on the project
• details of your development process. DOD and DOR. The current approach for task estimation. Branching and releasing strategy
• diagrams and graphs explaining dependencies between parts of the app
• contact information of the important persons on the project and counterparts

What if my project has no documentation at all?

Well, you might be that guy who introduces it. As a pioneer, you will be even more valuable to the business.

Promote the documentation

It’s very important not only to write useful articles but also to let your colleagues know what you have done. After each documentation update write messages in the team chats and highlight them in daily meetings

• it will make you visible to the project management and a team lead as a valuable contributor
• your colleagues will remember that this piece of info exists in the documentation
• searching in the chat history will give your colleagues a hint. Useful in situations like “I know that we have the answer, but I don’t recall where exactly”
• it will encourage your colleagues to contribute to the documentation as well

Metrics

It’s difficult to come up with a general metric for the quality and usefulness of the project documentation. The number of articles and the views count don’t say anything. But in some cases, there are some figures to calculate

• concerning a guide for the start-up of the local environment, we can measure how much time it takes for a newcomer to prepare the local machine and pick up the first task. We can compare the time taken for the old/new guide
• documentation quality affects the time taken for the grooming and estimation of new features since the new things are connected to the old ones one way or another. We could measure the dynamics
• regularly ask colleagues to estimate documentation quality from 1 to 10 (for instance every month or every quarter). The average can be considered as a satisfaction level

Choosing the right architecture, framework, and libraries

One of the most important topics. Let’s consider some cases from the team’s performance standpoint.

• you are responsible for choosing the framework/library among several alternatives. You weigh the benefits and drawbacks of the things that are available and choose the one that will allow the team to write the code smoothly. The features and ecosystem of the chosen item allow the team to write less code relying on the out-of-the-box functionality
• you choose the framework/library/design which is aligned with the team's skills and maturity level. It makes sense to prefer a simpler solution if the team's average level is low. But for the more skillful team, we can choose the more advanced approaches
• apply the right design pattern in the right place to simplify code maintenance in the long run
• you can introduce a library to simplify boilerplate tasks or reduce duplicate code. For instance, introducing tanstack query in a React app allows the team to use handy API to make network calls rather than write cumbersome and repetitive code for that
• when working on the design, a skillful developer makes good assumptions about how the system might be extended in the future. Reasonable extension points can be added to the design. As a result, adding new features in the future will require small changes in the existing codebase
• the system should be split into independent and isolated parts which know as little as possible about other parts of the app. Low coupling makes code changes more predictable and reduces the number of bugs

This topic can take the whole article, so I stop here. I think you got the point. The solid design and the right tools make the team very efficient.

Metrics

• Scrum Velocity, or an average amount of work delivered in a month/quarter

Improve development experience

Introduce and propagate tools that make code writing and debugging easier and faster

• IDE plugins for code highlighting, autocomplete, formatters, etc. In VScode the set of chosen plugins can be defined as a .json file located in the project repo to share with colleagues
• scripts to automate routine tasks. For instance, in the JS world, we can introduce git hooks to automatically run linter checks before push rather than executing checks manually. Scripts to start multiple services at once are another good example
• AI tools. Even a basic understanding of how to utilize the capabilities of AI tools like Ghat GPT or Claude positively impacts a developer’s performance. Figure out how to use it and teach your colleagues
• Postman collections and Swagger can simplify API-related tasks. What arguments do that endpoints accept? No need to search through the codebase, it’s much easier to check Swagger instead

Metrics

• we can calculate the average time a task stays in “In Progress”. Using the right tools will decrease the number
• an average amount of work (story points, T-Shirt sizes, whatever) delivered in a month or quarter. Scrum Velocity.

Unit-testing culture

Plenty of bugs can be discovered in the early stage by unit tests. Organizing proper testing processes saves a lot of time and money in the long run.

I agree, it’s not applicable to some kinds of projects. Startups, prototypes, or projects with constantly changing requirements will not benefit from tests. But for all other projects, I would recommend introducing unit tests.

• if the project has no unit tests at all, the adopter (you) will have to choose the technology/framework and write first 100 tests as an example and a starting point for the colleagues
• in some cases, it’s more efficient to write tests only for the most important and fragile logic leaving the rest of the app untested. I have an idea of how to prioritize code for testing. Will share in another post
• providing the mocks might require a lot of cumbersome code in some cases. It makes sense to use extra tools to simplify it. For instance, ng-mocks for Angular
• you may write documentation and conduct some team-level master classes to share the knowledge and facilitate the testing adoption in the project

Metrics

• an average number of bugs discovered in a sprint, month, or quarter
• an average amount of work (story points, T-Shirt sizes, whatever) delivered in a month or quarter. Scrum Velocity.

Knowledge sharing

You can organize a call, master class, or regular meetings to share valuable project-related information with the team. It can be a screen sharing with the presentation or online coding. Whatever is suitable to efficiently share important ideas with colleagues.

Avoid speaking about general topics. Focus on things that your colleagues can apply to the project right now.

• nonobvious but important things about domain logic or business processes. Sometimes developers focus on writing code but have limited knowledge of how the business works. The lack of knowledge of this kind might lead to bugs. It makes sense to shed some light on the business that stands behind the app to make the development mode aware and conscious.
• tricky things about the tech stack you are using on the project. Especially if you implement some things in a nonstandard way or if the implementation differs from what the framework/libraries documentation suggest
• any unclear topics highlighted on the retro or daily meetings are a good thing to clarify and share
• encourage colleagues to participate in discussions and share information as well
• make the knowledge-sharing sessions on schedule, say, once a week

Metrics

The regular knowledge-sharing sessions are supposed to boost the professional level of the team so we can estimate the dynamics in the development speed. Scrum Velocity, or an average amount of work delivered in a month/quarter

Other

It’s already too much for a post. So I briefly share other ideas on how to impact the team’s performance

• mentoring. Take care of the less experienced developers in the team. Communicate with them directly to make them more efficient. Pair programming and code review have proved to be very efficient
• right task distribution among the team members. A team lead should consider many factors when choosing a developer for a task
• improving the code review culture. Sometimes people consider code review as a useless formality. That’s wrong since the code review is one of the essential quality gates