Introduction
After decades of advancement, software applications have become an essential part of the world’s economic fabric. Nearly every company now relies on software to run some aspect of its business.
By increasing efficiency, optimizing collaboration, and reducing operation costs, software has taken over every vertical, from retail to banking to manufacturing. Retail stores use software to track inventory, set up their online presence, and perform their market analysis. Banks maintain and develop customer-facing software and critical internal systems to keep everyone’s money secure. Manufacturing relies on software to run its operations, track inventory, deliver, and ensure regulatory compliance.
While many SMBs can get by using off-the-shelf software-as-a-service (SaaS) products, this might not cover all of their needs. Internally-developed software can be a key competitive advantage, as enterprises provide what their competitors lack.
More than half of the world’s software engineers are already working outside the tech industry, and that percentage continues to grow. A McKinsey report identifies high developer velocity as a critical part of high-performing businesses across every sector, inside and outside the tech industry.
We now know how vital developer velocity is to business performance, but how do your organization’s non-technical aspects impact developer velocity? Many executives lament that software development seems like a “black box.” Let’s peek inside this box to see how you can influence developer velocity as executives and managers.
We’ll define what developer velocity is, then examine what typically slows it down. Finally, we’ll explore what you can do to maximize developer velocity, and in turn, improve your business performance.
Defining Developer Velocity
Simply put, developer velocity is the speed at which an organization’s software developers deliver business transformation and business value. The McKinsey study concluded the four most prominent factors in developer velocity are tools, culture, product management, and talent management.
The only factor a technical team influences are the choice of tools. Therefore, an organization has a greater power over developer velocity than do the technical groups. Your development teams need organizational support to succeed.
Consider these influences:
- Proper planning and project management
- Developer happiness
- Availability of tools
Proper Planning and Project Management
Velocity is speed with a direction. For a development team to move forward, they need direction — not just speed.
Even with the most talented development team, if what they build doesn’t serve your organizational goal, they achieve nothing but wasted time. Therefore, your developers need to clearly understand what they are building, why they are making it, and when to deliver it.
More importantly, they need to be able to recognize when they deviate from the goal and have resources to correct the course.
Developer Happiness
Developer happiness is a direct result of your talent management practices. Several talent management factors affect developer velocity:
Turnover rate: Unfortunately, the technology industry has the highest turnover rate — 13.2 percent, according to LinkedIn. On average, losing a technical or senior employee costs employers 125 percent of their annual salary. This cost makes sense because it takes time for a new hire to replace someone familiar with your organization, has industry domain knowledge, and can already work comfortably with your existing team. Therefore, minimizing turnover is critical in maintaining your developer velocity. A clear career path helps.
Burnout: Burnout can affect your developer’s mental and physical health, directly influencing productivity. Many studies have shown that working long hours reduces a worker’s productivity, which often goes undetected. However, we can take measures to mitigate the risk imposed by burnout by establishing a reasonable workload. Also, give developers clear goals and key performance indicators (KPIs).
Regular performance feedback and work recognition: Regular and honest performance feedback helps your developers improve their craft, resolve challenges they may be facing, and gain a sense of meaning within your organization. This feedback and recognition help developers focus on their day-to-day work.
Excellent Tools
A good tool-set is a developer’s best friend. As an analogy, a carpenter can build a house much faster using a set of power tools than using a saw and hammer.
Developers require a variety of specialty tools:
- Fast, powerful hardware for building and validating their ideas.
- The correct technical stack. Even though your talented developers can learn a new stack, they will build the same product faster with higher quality using familiar tools. When developers use familiar stacks, there are fewer unknowns, reducing the risk of delivery date delays.
- Planning and collaboration tools to keep them organized.
- Integrated development environments (IDEs) and their favorite editors for writing code in a familiar environment
- Build, packaging, and deployment tools such as containers, scalable cloud infrastructures, and so on.
- Continuous integration and automated testing frameworks.
When we think about a developer, we often think of a person sitting in front of a computer, continuously writing code. However, this rarely reflects a developer’s entire day. In addition to their core development tasks, developers are often responsible for packing and distributing their software to the appropriate users, and that, too, takes time.
Using a combination of build tools and deployment processes, we can automate this deployment and shorten the build cycle, enabling developers to focus on the craft they practice every day. Having the right set of tools for your development team strongly correlates with higher developer velocity.
Impediments to Developer Velocity
We have discussed the three areas of an organization that impact developer velocity. Let’s look at how organizations unintentionally impede developer velocity.
Insufficient Planning
When a development team doesn’t clearly understand their goal, they’ll struggle to get to where you want them.
Software projects are constantly evolving, and sometimes goals need to change. Without plans for handling inevitable surprises, the company will not receive the projected business value from the project promptly.
On top of delaying the project, the developers are left confused, frustrated, and stressed as they work overtime to deliver what the business needs.
Insufficient planning and understanding of short to long-term objectives and failure to communicate business value to the development team result in unclear goals.
In fact, managers often feed development teams tasks one agile sprint at a time without explaining the overall objectives. This lack of clarity has only three possible outcomes:
- Miraculously, the development team delivers exactly what the project set out to do.
- The development team spends time discussing their implementation, over-engineering to anticipate changes because they cannot predict what managers will require in the future.
- The development team delivers features that fail to provide the expected business value, wasting development time and effort.
Executives lament that software development seems like a black box: developers focus on the development and rarely think about the business needs. However, leaders need to communicate their business goals to the development teams. This communication enables them to make technical decisions that align with those business goals.
Poor Management and Culture
Management style and culture directly impact every team member, including the developers, designers, analysts, and everyone else involved with the project’s day-to-day operations. Poor management and cultural practices impede developer velocity.
For example, there may be unclear or even nonexistent measurement of the team and individual success. Lack of clear success measurement often leaves employees wondering what they should be doing instead of focusing on their work. A precise measure of success helps your developers set goals and motivate themselves to get there.
Imperfect success measurements are just as bad. For example, using story points per sprint without the necessary context of real progress encourages members to optimize the story points instead of work quality.
As well, a culture of overtime and overwork causes developer burnout and decreased velocity. A Gallup study identified the five leading causes of burnout: unfair treatment, unmanageable workload, lack of role clarity, lack of communication and support, and excessive time pressure. An organization has direct control over all these factors that impact velocity.
Additionally, partially implementing an Agile process reaps none of its benefits but burdens the development team with all the ceremonies. Some companies find it challenging to give up their waterfall tendencies in their transition to Agile, breaking development cycles into two-week sprints without breaking down the features. Instead of gaining agility and accommodating for changes, the development team is now burdened with additional meetings in the form of agile ceremonies.
Similar to insufficient planning, unclear success measurement, and unnecessary policy changes leave developers confused, frustrated, and stressed, negatively impacting developer velocity.
Inadequate Tools
Inadequate developer tools could be:
- Slow hardware
- Outdated IDEs
- Slow, clunky collaboration tools
Having inadequate tools not only impacts individual developers’ productivity but also collectively impacts the overall velocity.
Good IDEs make it easier for developers to perform their tasks. These IDEs can also guide developer improvement by recommending code changes, analyzing code complexity, and gradually improving developer velocity.
In a world where remote working is becoming more prevalent, slow, clunky collaboration tools can significantly detract developer velocity. Slow hardware and outdated IDEs usually only impact the one developer interacting with them. When combined with slow collaboration tools, everyone involved is stuck watching one person struggling with their instruments.
Inadequate team tools could be:
- Lack of container or cloud platforms
- Ancient continuous integration and continuous deployment (CI/CD) process, or worse yet, no CI/CD process
In a perfect world, new team members should set up their development environment on their own and start making changes right away. In a team without a mature infrastructure setup, such as containers or CI/CD processes, it’s a cycle of unnecessary frustration.
A developer gets a new laptop, checks out the code, tries to run the application, and the application fails. They spend hours troubleshooting, only to find out the computer has a newer version of the compiler installed.
It can even happen to your veteran developers. For example, they make a change and push the code for testing. An hour later, quality assurance (QA) reports that the fix isn’t working. The veteran developers recheck their code and test it locally. Everything still works. So, they check the deployment, only to realize the deployed environment is configured differently from their local environment.
Unfortunately, when such situations arise, usually a senior team member needs to take the time to investigate.
Without a reliable CI/CD process, every deployment risks failure because all manual work can lead to mistakes. Developers may spend significant time troubleshooting errors that are entirely preventable through modern CI/CD tools.
Maximizing Developer Velocity
So far, we discussed what developer velocity is and how an organization can unintentionally impede developer velocity. Let’s explore how we can improve developer velocity using the tools at our disposal:
- Engage with developers
- Empower developers and treat them well
- Give developers the tools they need to succeed
Engage with Developers
Engaging with your developers can clarify the project, minimizing the first impediment to developer velocity: insufficient planning. Some organizations treat developers like isolated entities because developers have a reputation for being poor users.
However, this stereotype isn’t true. According to a 2020 Stack Overflow survey, close to 70 percent of professional developers are under 35. They grew up with the Internet and used all kinds of digital products most of their lives. Out of all professional developers who responded to the Stack Overflow Survey, 90 percent have had some college or university education.
Developers are smart and savvy. Explain to them how their work fits into the organization’s overall goals and strategy, and they will reward you with velocity.
These well-informed developers might suggest more effective ways to achieve your goal. They can also point out technical risks early, giving the organization the data it needs to make informed decisions without impacting the delivery date.
When they understand the overall objective, your developers can better evaluate their progress and make technical decisions aligned with the organizational goals. Engaging with your developers keeps them happy, and it gives them the resources they need to maintain their velocity.
Empower Developers and Treat Them Well
The second impediment to development velocity we looked at was developer unhappiness. To improve velocity, you need happy developers.
When your development team knows what the objectives are, they know how to get there and when they need help.
Developers are smart. Give them the freedom to self-organize and let them decide the policies that work for the team. Don’t micromanage. It only increases frustration.
This freedom, of course, requires you to trust your development teams. It is foolish to trust your teams blindly, which is why it is so important to be an Agile company.
In a non-Agile company, your developer teams operate in a black box. The rest of the organization does not know what they build until the development team finishes. The organization has no chance to evaluate the developers’ work until it’s complete.
When the developers operate in a black box for so long, it’s hard to trust them. What are they doing? Does what they build fulfill our needs? Can they deliver on time? In contrast, when the company is Agile, the entire company can see the development team’s incremental changes as they release them in a tight cycle (usually every two weeks).
Adopting an agile mindset improves everyone’s velocity. Marketing can build marketing material sooner. Your sales team can start preparing demo scripts sooner. Also, you can make any strategic adjustments needed to ensure the product’s timely delivery.
Some executives like to push Scrum across the organization because they have had a good experience with it. They even hire consultants to train the teams to be Agile.
Scrum can be a successful strategy if your team has an aptitude for Agile. However, what works for one team may not work for another group simply because every team comprises developers with different experiences and personalities.
While some developers are perfectly comfortable with short sprints and small features, some prefer to work with a rigid set of requirements. Some have had success with Scrum, and others have had poor experiences. There is no silver bullet that works with every team. Let your team learn and adapt.
Be aware that developers tend to be optimistic in their estimates, so be prepared for delays in the work. Your developers are constantly working on something that did not previously exist. Therefore, they cannot always foresee or accurately estimate risks.
Any developer who cares about their work will try to meet commitments no matter what. The organization needs to give developers some flexibility. Sometimes, the developers themselves don’t even realize when they burn out and need outside help. Be realistic and adjust deadlines or grow teams as required.
Give Developers the Tools They Need to Succeed
The McKinsey study shows that “best-in-class tools are the top contributor to business success, and only 5 percent of executives recognized this link and ranked tools among their top three software enablers.” Recognizing this link gives you an advantage over other executives.
Two types of tools are relevant for developers:
- Dev tools for individual developers
- Infrastructure for the development teams
Development tools include the technical stack they will be using and productivity tools. For example, some tools can detect common mistakes, some devices can ensure all developers follow a specific style, and some software straight up enables developers to write code faster.
Some of these tools are so popular, many developers have grown accustomed to them. The fact your developers wish to use such tools is an indication of their competency.
Similarly, developers always appreciate powerful hardware. Give them a budget adequate to purchase the hardware they need for the job. Give them familiar tools and let 100 percent of their expertise work.
Then there are infrastructures. Investing in good infrastructure keeps the developers focused on the product.
For example, using DevOps tools like infrastructure-as-code (IaC), dev and ops teams can quickly spin up the infrastructure they need for deployment with full traceability. They can try different configurations, roll back if required, and apply the same configuration everywhere.
Containerization is another developer tool to remove variability between different environments, ensuring applications run the same in production as they do during development and testing. This containerization saves your developers from the headache of troubleshooting between different environments.
You can also adopt cloud platforms so teams can choose the best application format for the task at hand. These cloud tools could be serverless, Kubernetes, or platform-as-a-service (PaaS) like Heroku, Google App Engine, or Azure App Service.
Reducing the cycle time between development and deployment can significantly impact developer velocity and organizational agility. Slow or difficult deployment is one of the biggest impediments to developer velocity. Cycle time becomes an even bigger problem as you scale and have more services, and some services may depend on another service.
Fortunately, many mature and fully-featured CI/CD tools help facilitate everything from deployment to release. With CD in place, teams can quickly deploy several times a day and ensure the release quality. For example, a solid CI/CD process helps LinkedIn make mobile releases three times a day.
Good CI/CD drives many of the other tools we’ve discussed. When build and deployment are easy, development teams are empowered to choose whatever tools are best for the job at hand, knowing that they can easily build, test, and deploy any type of application to any cloud provider.
Conclusion
Investment in software development doesn’t have to be a black box. As a manager or executive, you directly influence how successful your development teams can be. For example, you can maximize developer velocity by engaging with your developers, providing support, and giving them the tools they need to succeed.
Of course, not every organization has the resources to pay for the best tools, hire the best developers, or purchase the best hardware. Assess the situation and find the sweet spot that works for your organization. Want to know if you need a CI/CD tool? Begin by asking your developers how long it will take them to make a release.
Sometimes, an investment isn’t a purchase. Your development team can spend time evaluating these tools or automating and improving their existing process. Even something as simple as keeping your developers informed helps improve velocity as they work toward the organization’s goal.
As the McKinsey study indicates, increased developer velocity positively impacts your business performance. You can make this happen.
If you’re interested in developing expert technical content that performs, let’s have a conversation today.
