IT development has been around for more than 60 years and it has undergone radical transformations from the emergence of the first programming languages and OS development to the internet boom and the current AI era. Although programming tools and approaches are constantly changing, one thing remains constant: Only those developers who can adapt and master new knowledge and skills survive.
I’m the chief software officer of a 70-strong team that designs a predictive maintenance system (PdM): A solution based on the Industrial Internet of Things (IIoT) and AI. Without continuous growth, our developers cannot remain competitive. The same is true in nearly every industry; when individuals stop working on their skills, a company can lose its edge.
Here’s a look at how we have created a system where professional development is an integral part of the work and how we help developers avoid and overcome stagnation.
MUST EVERYONE GROW?
Every team has specialists who prefer routine work, and to some extent teams need those people who do well in a position that does not require growth.
But for a project to develop steadily, I believe such experts should not exceed 20% of the team. If their share is higher, other developers will eventually start to emulate their passive colleagues. Optimally, the majority—about 80%—should be actively developing and improving their expertise.
Not everyone in the 80% needs to generate new ideas. The driver-to-performer ratio depends on the company’s development stage. A start-up needs 80% drivers because they’re the ones who forge ahead. Conversely, in mature companies, sustainable quality leads require constant hard-skill honing rather than a fountain of ideas.
DEVELOPMENT THROUGH SMALL ACTIONS
Encouraging developers to advance their skills can start small. For example, one underrated tool is having a person write tests to check their code, which is mandatory for everyone on our team, including senior specialists. Many teams use code reviews more often than writing tests. But when a developer writes a test, they may find that their method or function is too cumbersome, with many exceptions and dependencies, and it’s almost impossible to test it entirely. As a result, they begin redesigning their code and look for solutions to improve its logic. They study additional materials, such as technical blogs and best-practice guides, and consult with colleagues to deepen their expertise.
However, tests have limitations. Once a person learns patterns, writes tests quickly and confidently, growth stops and routine begins. This tempts developers to automate their work.
CASE-BY-CASE APPROACH
There are many reasons why professionals pause in their development. They may be satisfied with their position/skills, bored, or facing challenging external circumstances. For example, most of our developers are Ukrainian, and our work has been affected by Russia’s full-scale invasion of Ukraine, which has been a great stress to everyone.
Team members have responded differently—approximately 30% lost their motivation to do anything, and another 30% have taken a deep dive into their development. One strong junior immersed himself so deeply in his studies that in just six months, he mastered senior level theory. The rest simply adapted and returned to their usual pace.
After 10+ years in tech management, I realized that everyone has different motivations for advancing their skills. Your task is not to pressure them but to understand what is holding them back and what incentivizes them. Some practices that I’ve found helpful when developers stagnate are:
- Provide new context. Offer the developer an opportunity to work on another project or change domains. A new environment presents new challenges, requires adaptation, and learning.
- Present challenges. Give the developer a task that requires creative thinking and independent research. Don’t provide an answer. This will let them take initiative and responsibility for the result.
- Encourage learning. If a person seeks development opportunities provide them with resources. For example, compensate for conference or workshop participation.
- Adjust expectations. Sometimes a person is satisfied with their expertise. In this case, it’s important to agree: If the developer doesn’t want growth, they don’t seek promotion.
Each specialist must have their own development plan. We draw it up twice a year, based on in-depth assessment. We set goals that meet the company’s expectations and the developer’s interests.
THE COMPANY’S SYSTEMATIC APPROACH
In my experience, developers often stop focusing on advancing their skills when they are overloaded. After intense work, they no longer have the energy to learn. Learning by working is our main principle. We believe developers can improve their skills through hands-on experience, so we integrate this approach into employee development plans.
- Daily: Giving them a short technical digest and work with code through tests and reviews.
- Two-week sprints: Each sprint includes two to three days when a developer can try a new approach, technology, etc.
- Once a month: Internal clubs— sessions in each department lasting one hour to 90 minutes where they can share experiences, run practical workshops, and exchange best practices.
- Once every three to six months: Three-hour sessions with external speakers, advanced training.
FINAL THOUGHTS
I’m convinced that development begins with dialogue. You should understand what motivates a person. I also believe that there are no wrong decisions—only different points of view. Developers shouldn’t be afraid to disagree because critical thinking and constructive discussion always help team growth.
Illia Smoliienko is the chief software officer for Waites.