Exposing 5 Red Flags Lurking in Your Software Development Team

Have you ever felt like something was "off" with your software development project, but couldn’t pinpoint why? Maybe the pace of progress seemed grueling, the quality of work was disappointing, or communication with the team often left you with more questions than answers. In this article, we will unearth the root causes of these and other unsettling feelings and discuss what you can do about them. Spoiler alert: We think you should trust your gut. Here’s why.

Red Flag #1: Low Visibility

In the evening hours of July 25, 1956, an enormous cruise ship, the S.S. Andrea Doria, was speeding through a thick bank of fog off the coast of Nantucket, Massachusetts. At the same moment, a passenger liner, the Stockholm, was entering the fog bank on a course that was meant to save time, but put it directly into oncoming traffic. Both ships noticed each other on radar, but failed to make radio contact because they assumed their routes didn’t intersect. When they finally made visual contact, they realized they were on a direct collision course. Needless to say, this story ended very badly, with major damage to the vessels, 51 deaths, and lawsuits that lasted for decades afterwards.

How do two huge ships relying on modern protocols crash into each other? Low visibility. Thick fog and misinterpreted radar caused two captains to make bad decisions. They went full steam ahead—even though they didn’t really know their exact positions or where they were heading.

As the captain of your organization, you need to be able to see where you are and where you’re heading. Are you able to view the ongoing work in your software project without needing someone to show it to you? Do you have access to the source code? If the answer is no, that’s a problem. Your source code is like the cargo of your ship–something you have bought and paid for. If you sense reluctance from your development team to give you access to your own cargo, that’s a huge red flag.

What You Can Do to Gain Visibility

Ensure that your team uses issue tracking software; it’s like a GPS for your project. Even if you have just one developer, they should be using issue tracking tools and you should be able to see if your ship is on course.

Similarly, your team should be using version control software. The latest version of your source code is your precious cargo, and you should have full access to it. Don’t take no for an answer. If you can’t log in and get a copy of the latest version of your software right now, you have a problem.

This is your ship. Demand access to source code and accounts, and establish a transparent ticketing system.

Red Flag #2: Poor Communication

On January 28, 1986, the Challenger tragically exploded 73 seconds into its flight, killing all crew members. This disaster happened because the O-rings in the solid rocket boosters didn't seal properly in the cold weather.

Knowing this failure was likely, NASA engineers tried to stop the launch the night before. One of them even told his wife, “It’s going to blow up.” But instead of saying those clear and ominous words to management, the engineers used technical jargon. And management, who didn't want to hear bad news and failed to grasp the gravity of the situation, coerced the engineers to launch anyway.

This tragedy illustrates a crucial lesson: clear, open communication is essential. Let’s break down the different ways this red flag can manifest itself on your project.

Misunderstanding Technical Jargon: Managers didn’t see the impact of what the Challenger engineers were trying to tell them because it was veiled in technical jargon. This happens all the time in software development. Sometimes developers are so deep in the details of their work that they don’t think about how to communicate clearly and simply. And when non-technical leaders don’t exactly understand, they can’t make effective decisions.

Unclear Requirements: Trying to produce and deliver requirements is always an exercise in communication. A manager might give requirements they think will create the solution they’re looking for, but without feedback and communication, a developer might simply follow instructions, creating a feature that was asked for, but that misses the business goal.

Cultural and language barriers: Sometimes software engineers from other cultures believe it is wrong to challenge assumptions, so they simply do as their boss instructs. At other times, language barriers might prevent engineers from understanding exactly what their bosses are saying, but they are too scared to admit their confusion. They end up doing something–anything–to avoid admitting they don't understand.

Lack of trust: If the software engineers don't trust each other or their managers, they won’t share information with their team. A good engineer will know what skeletons are in the closet, like technical debt and potential system crashes, but they may not feel safe to share that information.

These issues matter because the success of your custom software depends on how well you communicate. Great software comes from prioritizing: first the people, then the process, then the tools. Most toxic software teams don’t have tool problems. Maybe they have some process problems. But by far, their biggest problem is the way they fail to communicate.

What You Can Do to Improve Communication

Creating psychological safety within your organization is the most important step you can take. Encouraging a culture of open, respectful, and free communication will help you build better software.

It’s not just what you say—it’s also how you say it. A team that communicates with humility and empathy doesn’t just deliver information; they help others make good decisions. Feeling free to ask questions, disagree, and point out technical flaws will enable your team to create the systems you need and avoid potential disasters. Perhaps if NASA had created an environment of psychological safety in the 1980s, we would still have those astronauts.

Peter Drucker famously said, "culture eats strategy for breakfast.” We would add that it also eats processes and tools for lunch. Your company’s communication is your culture. If you want to fix your software, you need to fix your communication. If you need to fix your communication, create a culture of honesty, respect, kindness, and transparency. This will help you build a software system that will last.

Red Flag #3: Slow Progress

In October of 2020, a brand new airport opened in Berlin: BER. But if you’re ever in Germany, don’t bring it up with the locals. This point of national pain was originally scheduled to open in October of 2011, but it was plagued with technical issues, management failures, and oversight problems. They got there in the end though, right? Wrong. In the scathing words of the New York Times, “Nine years late and $4 billion over budget, the airport is already outdated.” Ouch.

Software development is complex and time-consuming, but inexplicably slow progress is a red flag. It burns through your budget and causes missed deadlines that erode trust with your stakeholders.

If you feel that slow progress is a problem for your team, ask yourself one question: What’s causing the delays? Here are three possible answers:

“I don’t know”: After weeks of work, there’s no visible or understandable progress. Installing updates is a major task, not an automatic part of the production process.

“They’re building the wrong thing”: When you build a house, you buy many pre-made components, like door locks, windows, and appliances. Similarly, in software development, many components can be bought off-the-shelf. Is your team building everything from scratch, down to the lock tumblers and window glass?

“They’re building the right thing, but...”: Your team is working on the desired features, but it’s taking much longer than estimated. Does your team struggle to understand the true scope of a task? Do they need guidance on how to make more accurate estimates?

The answers to the question “What’s causing the delays?” will give you insight into what’s slowing down your progress and empower you to address whatever issues are uncovered.

What You Can Do to Accelerate

First of all, ask for explanations you can understand. A good engineer can explain things in a way that a non-technical person can grasp. Keep asking questions. Are they using automated deployments like CI/CD pipelines? If they are, you should be able to see their progress multiple times a week, or even daily.

If you suspect that they are building everything from scratch, remember that you don’t need to pay someone to reinvent the wheel. Ask if there are pre-made solutions available, and explore your options.

Red Flag #4: Quality Issues

The Ford Pinto, introduced in the 1970s, became infamous for a fuel tank design flaw that made it susceptible to catching fire in rear-end collisions. Investigations later found that Ford had known about the dangers but decided that the financial cost of lawsuits would be less than the cost of redesigning the fuel system. What a shameful approach to quality control!

This brings us to our fourth red flag—frequent quality issues. Everyone gets bugs, but nonstop regression bugs indicate that your engineers don’t know how to fix them properly. Similarly, a lack of automated testing can result in poor quality. If bugs reach production, they can cause downtime, damage your reputation with customers and investors, and create security risks.

What You Can Do to Improve Quality

Here’s where we can draw lessons from a positive story: Toyota’s Andon cord. In the 1970s, Toyota wanted to encourage employees to stop the production line if a problem was detected so that they could fix issues immediately. So they devised a physical cord that ran along the assembly line that any worker could pull to stop production and address a problem. This process placed quality in the hands of every worker, not just testers at the end. The result? Toyota is now a world leader in quality and efficiency!

How can we apply this to software development? First of all, you need automated testing. Human testers are necessary but insufficient if you want to have frequent releases with good quality. Automated tests will immediately inform your team when there is a defect and allow them to stop production to address it. Your entire suite of automated tests should be run automatically against your entire codebase after every change in the master code repo.

Additionally, ensure your developers are writing thorough automated tests. If your developers can’t describe the different kinds of automated tests they are writing (such as unit tests, acceptance tests, or integration tests), there is a possibility they aren’t writing them at all.

You should also implement a CI/CD pipeline, use feature flags, and have a dedicated dashboard that automatically displays critical issues. This will help you create an environment where developers feel empowered to stop their work and address issues as soon as they arise.

It may be challenging to retrofit your system if these processes aren’t already in place, but they’ll save you from becoming a blazing Ford Pinto. If you need help, this might be the time to bring in some consultants. It will be a worthy investment.

Toyota also adopted a long-term philosophy known as kaizen, which involves small, continuous improvement in operations. Toyota encourages everyone—from top management to factory floor workers—to adopt this mindset.

In the context of software development, this principle can be applied by having development teams actively refactor their code immediately upon identifying a bug. Rather than merely fixing the bug, developers should take the opportunity to examine and improve the surrounding code. And when they fix it, they should write an automated test to make sure that bug does not regress in the future.

In time, these changes will make your codebase cleaner, more efficient, and more maintainable. By adopting these principles from Toyota, along with automated testing, you will significantly reduce frequent bugs and build high-quality, reliable software.

Red Flag #5: Knowledge Silos

Imagine you’re the owner of a popular restaurant. The food is excellent thanks to your chef, who is the only one who knows the recipes. You’re booked solid. But if the chef gets sick and has to stay home one night, you’ll only be able to serve drinks and potato chips. Maybe you can survive one night, but if your chef quits and takes his recipes with him, you’ll have to close the restaurant.

This is an example of a knowledge silo. Vital company knowledge existing in only one person’s head puts your organization in an unacceptably vulnerable position. If you’re seeking answers about what’s happening on your software project and one person’s name comes up over and over again, you probably have a knowledge silo.

Another symptom is that nothing is documented, and you have to find the one and only person who knows how things work. Maybe this person is even using personal, non-company accounts for APIs and services (Google Analytics, Stripe, etc.) If they are using a company account, does anyone else know the login credentials? Are they documented somewhere? Who knows?

What You Can Do to Share Knowledge

Asking yourself “Who Knows?” will help you determine if this is a problem on your team. If it is, you need to allocate time in the budget for writing documentation. Anything vital to how the system works should be documented.

You also need to build in time for cross-training. This means having two people work on the same task for a while so that important knowledge is shared. Create an on-boarding document for new developers so they don’t have to rely on a single individual for information. Pay attention to how well things run when that key person is not around. Do things stall? Are certain tasks suddenly undoable? Test your team’s functionality when the suspected knowledge silo is away and find out where the gaps are.

Ultimately, knowledge silos put your business at risk, so make sure to document important information and share it with other trusted team members.

How to Avoid Being a Disaster Story

Ty Downing, COO of SkyNav, wasn’t getting any sleep at night. His company is his software, a product that allows aerial to ground experiences using 360 degree high definition imagery. Unfortunately, that software was in the hands of a development team that his gut told him he couldn’t trust. There was no communication, no transparency, and even some falsehoods. So he set three goals for getting his ship back on course:

Transparency: Ty wanted to see and understand what was going on with his software project.

Documentation: If someone were to leave, he wanted processes documented so that another developer could step into their place.

Organization Protection: He wanted to establish protocols that would protect his proprietary software.

With those goals in mind, Ty set out to make changes to his team. Since then, he has found developers that met his criteria, and the difference is night and day. He comments, “As business leaders…we don't want to learn code. We don't want to know Python or languages. We don't have time for that. But we do need to control our own platform…We need to lead.”

To that end, Ty has found that “a good programmer can explain [things] to somebody in my role in a way that makes them feel comfortable, and in a way that they can trust. So hire the right team…Demand answers. It’s your software.” Ty gets better sleep now, and if you see SkyNav in the press, it’s because they’re expanding, not going down in flames.

Like Ty, you too can take control and turn your project around. Listen to your instincts, look for red flags, and take decisive action. With the right team and practices in place, you’ll feel comfortable with your development team and trust them. And, most importantly, you’ll see your project progress successfully!

If you’d like to hear more about Ty’s experience and dig deeper into the 5 red flags we’ve covered here, check out our webinar.