Transformation is the new normal

If your company has been around for more than about five years you are probably doing at least one of a few things: adopting agile and/or DevOps, refactoring revenue generating applications into several smaller services, or moving to the cloud.

According to research by firms like Redgate and Puppet, upwards of 90% of organizations either already do DevOps or plan to adopt it. 92% of respondents already use cloud computing in some form or fashion and 38% of enterprises have cloud adoption as their top priority. After 17 years the Agile manifesto has changed the way that over 70% of organizations execute their work.

If you think that things will slow down now that we have containers and public cloud, think again. The rate of innovation in tools and process is accelerating. If you’re not already thinking about capabilities like serverless or deep learning, you’re going to fall behind.

The problem I see again and again is that teams who are on the hook for execution often end up in unhealthy states while these transformations are taking place. The reason is that most organizations have not figured out how to invest in and measure the skills of the people on their teams. Failing to make sure your teams keep a healthy distribution of skills will create key person dependencies that put delivery at risk. In my own research, I find that about 9 out of 10 software professionals are either on or have been on a team with this issue. As usual, there’s a people, process, and tooling aspect to this problem.


Our line managers almost always come from being a direct contributor. As an engineer they learn how to compromise between a “perfect” implementation and what they can get done realistically. They empathize with customers and develop a deep care for resolving production issues quickly. Most of their day is spent thinking about architecture, scaling, user interfaces, performance, testing, and process.

Our industry has done a poor job helping people make the transition from that thought process to one of management. As a result, our managers fail to delegate enough of that traditional type of work to make room to focus on developing their team and the people on it. They spend their days thinking about many of the same types of things they did as a coder.

This is a tremendous missed opportunity. 76% of millennials think professional development opportunities are one of the most important elements of company culture. There is a mountain of research that shows developing your people leads to more engaged employees who stay longer and provide more value. We have to start training our managers to shift their thinking and start to understand their responsibility in this area. The fact is, lots of people on a team can put out fires and think about architecture, but nobody is going to develop the skills of the people on the team if the manager isn’t driving it.

Another important consideration is how long your engineers have been with your firm. One company I worked at had an average of almost seven years. Many of the cloud based services we were pushing people to build on didn’t exist when over half of our engineers were hired with us. That means they’ve had no chance to use or learn those tools before.


This focus on evaluating and proactively training people to fill skill gaps has to be continual. As we’ve said before, the tools and best practices related to technical product development are constantly changing. That means we need to be constantly learning. Whether we’re talking about focused, straight forward change like a framework upgrade or a bigger shift like migrating an application to AWS, if you don’t actively manage it then your teams will entropy into a bad state. You’ll see one person on the team step up to learn a new tool again and again. A single point of failure means that when that person moves on it amplifies the loss because nobody else has the expertise they did. It also makes it hard to promote that person.

Make evaluating skills gaps part of your monthly or quarterly retrospective process. Create transparency on the team by showing the state to everyone. Help them understand how to think about their skill level, and make goals as a team on what you’re going to focus on improving.


You have a few options on how to facilitate the process of continuous learning. You could track skills and ratings in a spreadsheet. Your company probably has some kind of people management tool that has a module for this, but I’ll admit that I’ve looked at many of these and they are usually not great to use. Some project management tools like Jira have capabilities as well, but they are normally designed to match people to tasks based on current skills, which is actually not what you want to do if you are trying to teach people.

This is the reason I built Tekata is a free-to-use tool that allows you to define your teams, list the skills each team needs and the members of the team, and then subjectively rank members against skills. Tekata will help you see which skills are deficient. By re-ordering skills you can visualize how the workload of the team is shifting and make sure your most critical skills have enough shared expertise on the team. Tekata will also show you the history of the health of the team as it changes over time.

Transformation in our technology teams is constant. It’s time for us to adjust our approach to managing teams so we can keep them healthy and able to deliver business value reliably and at high quality. Their delivery will be more affected by those skill gaps than almost any other single factor.