Top challenges every developer team lead faces
Some tech companies spend so much time recruiting and identifying the top software talent, and yet their teams produce subpar results.
This problem usually points to inefficiencies in team and company management.
This article will analyze six characteristics present in ineffective engineering teams and walk you through potential improvements.
Once you learn to recognize these signs of ineffectiveness, you’ll be able to detect them in your own team and steer it in the right direction before the problem escalates.
Table of Contents
No autonomy
The inability of team members to make autonomous decisions, paired with too many rules, stifles effective work. Because of that, you should try to instill the feeling of independence and freedom into your team.
When developers have to check in with the team lead or the manager before implementing each decision, no matter how small, they soon become dependent on approvals and are unable to work independently.
The problem increases when managers themselves encourage such behavior, resulting in micromanagement, a phenomenon that makes almost 70% of employees consider leaving their job.
Some managers go a step further and call themselves nano-managers, a term popularized by Elon Musk in a Wall Street Journal interview.
In the interview, Musk admits that controlling every single aspect of his products isn’t a recipe for happiness, but he still keeps committing the mistake, proving how difficult it can be to give up control, even for the savviest of leaders.
Still, there are methods that can help you keep micromanagement practices at bay.
Mario Cervera, a software engineer, says that managers can overcome the challenge of micromanagement by granting developers more freedom and refraining from assuming that the devs don’t know what’s best for the product.
He also advises delegation, a management method we wrote about in the article about effective engineering managers.
There are software companies that base their entire mode of operation on the principles of autonomy and freedom.
For instance, Netflix has dedicated a lengthy portion of their culture memo to the freedom employees have when making decisions.
Of course, autonomy comes with responsibility. That way, the company can count on the employees to think their ideas through before implementing them.
The autonomy-based work model turned out to be so successful that the company CEO, Reed Hastings, wrote a book about it.
The book entitled No Rules Rules explores how allowing employees to make independent decisions has made Netflix as innovative and successful as it is today.
All in all, with increased autonomy in what and how tasks are done, your team will be able to tap into the creative potential that may have been previously limited by micromanagement.
Communication breakdowns
The next characteristic of ineffective engineering teams is poor communication between team members. This can jeopardize the team and its output, so make sure you create an atmosphere that facilitates communication between all levels of the team.
Communication breakdowns happen to the best of teams. In 1986, NASA’s space shuttle Challenger exploded 73 seconds after liftoff, and one of the causes of the disaster was a communication issue.
The source of the explosion was a faulty O-ring. The engineers noted the risk, but their warning never reached the managers who could have delayed the launch.
While your software development team probably doesn’t work with space shuttles, you should still train the team to communicate well. This will ensure that your projects are always on the right track and that risks and mistakes don’t go unnoticed.
Get unreal data to fix real issues in your app & web.
Developers, especially juniors, are sometimes reluctant to share their problems due to a fear of conflict. However, by encouraging team members to be open about any challenges they encounter, you can prevent small bugs from becoming dangerous problems.
This also means that their senior peers or supervisors should work on their communication skills. Here are some pieces of advice written by Jon Cairns, a software developer at Intellum.
Cairns finds that communication is often overlooked in software development. He advises practicing empathy when interacting with team members, especially in stressful situations such as code reviews.
Communication also plays a vital role in one of the characteristics of effective development teams: the ability to make realistic estimates.
Even the famous 2017 version of Scrum Guide points out that the development team should be in charge of estimates, not the management.
As the guide says, the Product Owner can offer input, “but the people who will perform the work make the final estimate.”
So, if your engineers notice that the complexity of a feature could impact the delivery date, they should feel confident enough to relay the issue to the management. In other words, they shouldn’t be afraid of the management’s reaction.
If you want your team to communicate effectively, you should teach all new team members that over-communicating is always better than withholding information.
No culture of excellence
You will only find complacency in ineffective teams. Great teams nurture a culture of excellence, ensuring they’re getting better project after project.
Some tech companies base their culture on diversity, others on innovation, but they all have one thing in common: the motivation for being excellent in what they do.
Netflix, the company whose culture we’ve just mentioned, has a no-nonsense approach to average performance. As soon as your performance drops below excellent, you’re out, as described in this excerpt from the culture memo.
“We give adequate performers a generous severance package so that we can find a star for that position.”
It’s worth noting that the company provides employees with exceptional benefits and programs, which can be divided into three categories: self-care, finances, and comfortable working arrangements. However, they also expect top-notch results in return.
Unfortunately, many tech companies struggle with developers doing the bare minimum. This may mean creating a feature that works, but not caring about the quality of code or documentation.
You can see an example of an unhappy developer who complained about one such colleague on Quora.
The developer is aware that such a careless approach harms the team and the company.
One comment shared the story of the time their software team had the same issue with unmotivated coders. They described the issue in detail and advised the original poster to react immediately.
Based on the advice from the thread, a good approach to the lack of excellence is identifying engineers settling for mediocre solutions and preventing this kind of work ethic from spreading.
Contrarily, you could act preventively and reward employees who produce excellent results.
For instance, this job ad for senior backend developers at Genesis Research makes it clear that the company rewards top performers.
Of course, a carrot and stick approach is not as good as creating an atmosphere where employees are intrinsically motivated to do their best, but it’s a start.
Once you build a core team of developers who are always striving to produce excellent work, each new dev that joins the team will have great role models to look up to.
Avoidance of accountability
Accountability in engineering means being responsible for the work you’ve been assigned to do. The lack of this trait is characteristic of ineffective teams. Luckily, there are ways your team members can increase their accountability.
Let’s say that a dev has written a buggy piece of code.
A lack of accountability would mean letting the error slide or waiting until somebody else picks it up. On the other hand, accountable engineers would own up to their mistakes and start working on the solution.
Kent Beck, a senior software engineer, finds accountability a crucial part of successful software development teams.
“While programming I offer accountability as a way of demonstrating my trustworthiness and encouraging my own best behavior.”
Here are some of the ways he makes his commitments visible to the team:
- Pair programming
- Test-first programming
- Visible weekly and quarterly cycles
- Slack
- Continuous integration
That last item, continuous integration (CI), increases accountability by enabling more people in the team to directly change the code, rather than relying on one person to push commits.
The practice automates the integration and deployment of code changes of multiple engineers in a single software project. In other words, it allows all contributions to start the release process of a new version.
You can choose between numerous CI tools. Here’s a screenshot of one of the most popular tools, CircleCI.
So, once each of your engineers can easily change the project code, they have an increased responsibility to produce the best code they can, which calls for accountability.
Since mistakes happen to everyone, it is important to be transparent about them. If a dev causes a bug, they should report the bug, create a ticket in the task manager, and share their progress in fixing it.
Just like you can automate parts of CI, you can also automate bug reporting. Our tool, Shake, streamlines the process of noting crash and bug details.
Shake can also help with accountability because it integrates with Asana, Azure DevOps, GitHub, and all other tools your team needs to communicate about the project.
All in all, avoiding accountability has detrimental consequences to the team morale and the quality of the code. To avoid that, you should encourage your engineers to own their code and its effects on the project.
High turnover
The easiest way to identify an ineffective software company is to look at the turnover rates. If team members are leaving the company in droves, it’s very likely there’s something wrong with the way the team functions. To keep yours as low as possible, you should identify the cause of dissatisfaction.
A great starting point might be to check how your company approaches technical debt.
Rewriting the same line of code in different stages of development is not only uneconomical. Technical debt is also so dull that it contributes to high turnover in tech companies.
In fact, more than half of engineers have reported leaving or considering leaving due to technical debt.
Technical debt is just one of the reasons skilled engineers leave companies, but it’s indicative of how ineffective work makes people want to quit.
However, some turnover is always expected. Here’s a table of the top tech Silicon Valley companies with their average tech employee tenures.
| Company | Average tenure in years |
|---|---|
Uber | 1.8 |
Dropbox | 2.1 |
Tesla | 2.1 |
Square | 2.3 |
As you can see, not all companies can resemble Cisco and their average employee tenure of 7.8 years.
Still, if you notice your careers page advertising a perpetual job opening, it could be worthwhile to investigate the pain points making engineers leave. The most straightforward way to do this is with exit interviews and surveys.
These tools assist you in identifying specific reasons why people leave so that you can address them in the future.
For instance, you could ask the employees about their satisfaction with coding principles, the management, and how the work is organized.
If you don’t have the time to compose surveys from scratch, you could use premade templates and customize them to fit your company. This SurveyMonkey’s exit survey template could be a starting point.
Suppose the answers reveal that engineers are leaving because of, for example, poor deadline estimating practices. In that case, you could consider directly asking your engineering team for more input rather than relying on what project managers report.
To conclude, high turnover indicates that there are ineffective elements of how teams operate, which deters new talent from applying. Identifying the issues and alleviating them will help you make your company a desirable place to work.
Lack of employee growth
When you see a team of engineers stuck in their positions for years on end, you can tell that the team isn’t organized effectively. Facilitating career growth will make your employees more satisfied, increasing the quality of your company as a whole.
A stagnant employee is rarely a happy one. There aren’t many junior software developers working in that position for years—most people want career growth.
Here’s an example of Steven Mitts, a software engineer who climbed his way up the ladder from a system developer to a team lead over five years.
His career path is typical for the software industry. As engineers grow, they usually transition from technical roles to those in management, such as team lead, technical lead, or CTO.
The following image shows a chart made by Creately illustrating the possible career paths of software developers and testers.
As you can see, there are many steps along the path of career growth. A good employer guides their employees along the way and provides the resources necessary to learn.
Still, it’s worth noting that not all engineers want to work in a management-based trajectory.
This is why Tim Johnson, CEO of the IT staffing agency Mondo, implements an employee growth strategy to recognize and direct talent.
The company implements quarterly and annual surveys where employees talk about their ideal roles within the company.
Surveys are then followed by individual face-to-face meetings. Johnson has found this approach beneficial to both employees and Mondo.
“This strategy works two-fold: It empowers our employees to speak up about what it will take to retain them and establishes our investment in them individually, along with our investment in their long-term future with the business.”
You can also help your employees grow their careers by ensuring they have plenty of learning opportunities, including the learning budget and materials.
With career path planning and enabling learning opportunities, you’ll get better engineers who can upgrade the way your software team operates. Meeting the engineers’ career requirements will also avert them from seeking career opportunities elsewhere.
Conclusion
As you can see, the ineffective team characteristics we’ve listed can be found even in the best of engineering teams.
Still, just like you’d treat a small cavity as soon as it appears to prevent toothache in the future, you should scan your team for these characteristics and act if you spot their early signs.
This will allow you to empower your entire team on an individual basis, contributing to overall company success.
