7 Shared Traits of Ineffective Engineering Teams

Why is your engineering team ineffective? In this article you will learn to recognize seven bad team traits.

Ineffective engineering teams are not all the same, and the problems are not always obvious. However, there are some red flags to look for when evaluating a team. Team leaders and CEOs need to keep an eye out for the following red flags.

1. Bad hires and partnerships

Having an effective engineering team starts with hiring the right people and the right companies with whom to do business with. You need to hire people who fit into your work culture. That means hiring people who share the company values and buy into the mission. All new hires should be well-trained, courteous, hard-working, and professional. However, correct hiring practices don’t end there. What follows are some common hiring mistakes.

Prioritizing diversity over effectiveness

Diversity hiring creates a vibrant culture in which different perspectives bring new solutions to the table. However, team leaders and CEOs need to balance the need for diversity against the need to keep systems running quickly and efficiently. 

Consider the following example: If one engineer writes unique code that others on the team find difficult to read, that slows the efficiency of the team. With complicated tasks, such as APIs, other engineers may not be able to find their way through the unusual code. The engineering team wants the product or the service to be navigable by more than one engineer for optimal flexibility and efficiency.

Hiring the most brilliant candidate and not the most needed candidate

When hiring a new engineer for an established team, leaders want to hire the person whose expertise and experience fill a gap on the team. It may seem counter-intuitive, but that means hiring the person with the right competence, not the most over-all competent candidate.

A common mistake when hiring software developers: Hiring the most brilliant candidate and not the most needed one. Click To Tweet

The members of the hiring team need to know exactly what competencies are needed before advertising the position. And they should steer interviews to determine that the candidate meets the exact needs of the opening. 

For example, if the team needs a front-end engineer for developing software, the ideal candidates are those who know JavaScript, CSS, and HTML. You might meet a candidate who is a genius in machine learning. But that genius is not right for your team unless he also knows the needed technologies.

Not making the engineers part of the process when hiring a vendor

When selecting a vendor, top executives will meet multiple potential companies to determine which best meets the organization’s needs. Loop the engineers in. They should have a voice in which suppliers will vendor their work.  It is a good idea to put at least one engineer on the hiring team to ensure clear communication between the engineers and the vendor. 

Vendors who have experience working for companies similar to yours, as well as experience on analogous projects, may do a better job for you, because they talk the same language as your engineers. When engaging a vendor, also take the trouble to read reviews from previous clients.

2. No culture of excellence

Think about the most successful corporations in the world. All of them possess unique corporate cultures. 

But they have one thing in common: the drive to be excellent. To achieve excellence for the whole company, each department or team should be pursuing it.

What follows are the characteristics of teams that are not pursuing excellence.

Individual and team apathy

Every company employee and team should be passionate about their work. You will frequently hear the word “passion” from candidates interviewing for a job. They are, indeed, passionate about getting high-paying employment. Even the oldest, most reliable engineers used the word “passion” when they were interviewing.

However, there can be a decline in creativity and eager problem solving (aka “passion”) among your most experienced engineers. It is up to CEOs and top executives to cultivate passion in even the most placid employees. Studies show that the following practices improve employee engagement:

• Get rid of arrogant/bad team players fast, even if they are total rockstars. Nothing kills a team’s culture and performance faster than allowing weeds to grow internally. On a side note, remember that quite often employees leave their managers, not their companies.
• Praise good work
• Publicly acknowledge good work
• Maintain a happy, upbeat company culture
• Take an interest in employees’ lives outside the office; show compassion
• Share company success on a regular basis so that employees can be proud of where they work
• Give back to the community, and allow employees to participate in volunteer work during office hours

Doing the minimum to get by

For any company, the end goal is to succeed and grow. The engineer’s role is to help the company succeed and grow through technology and design. 

Unfortunately, some engineers are content to complete some elegant code without considering the user experience. An effective engineer will want to serve the customer. An ineffective engineer considers the customer a nuisance who just adds to his workload.

An effective engineering team cultivates customer empathy and a passion for solving problems on the user end as well as the development end. Engineers should understand the company’s big picture rather than isolating themselves from accounting, sales, and marketing. 

Lacks curiosity; dislikes learning new things

New tech tools emerge daily. Each company must carefully evaluate new tools, deploying those that add value to that particular company. An engineering team that is resistant to new ideas will make itself obsolete. Therefore, an effective engineering team should create an environment for its engineers to embrace new programming languages and tools, even new technology trends. The curiosity to continue learning is the key to a lifelong career path. Once an engineering team becomes averse to learning new things, it will lose its creative edge.

3. Communication breakdowns

George Bernard Shaw rightly said, “The single biggest problem in communication is the illusion that it has taken place.” 

It’s easy to let bad communication and communication failures slide. But everyone in your organization needs to know the facts that relate to his/her job as soon as possible.

One example of poor corporate communication occurs when developers do not get honest feedback from their peers in customer service and support. Or when developers simply ignore the feedback.

Customer service employees and developers are on the same side. If they lose sight of this fact, the results are disastrous. The support team is in trouble when developers neglect to fix a bug or develop a new feature that is badly needed to make the product succeed. Simultaneously, developers feel lost when the support team doesn’t tell them how the new product is doing on the customer end. 

When these two departments have good communication, the developers understand the bug’s context and its actions. The customer support department should not be monitoring a bug, and the developers should have enough information to know how the bug acts and how it is interfering with user experience. There should be an open and continuous feedback loop between development and customer support. 

Failing to learn end-user experience

No matter how good a technology is, it will not succeed on the market if the end-users can’t figure it out. Tech teams need to train end users when there is a product update or new feature. Tech teams should plan for this training upfront and during the development stage. 

Ideally, training will begin before the product or service hits the desktops. If an engineering team members do not have the right training to attract users, they need to be brought up to speed. User training should always match the standard training models. Training end users should always confirm that the product can be used as expected.

Failing to say “no”

Who wants to be viewed as the department that says “no”? Nobody. Yet, in choosing new projects, the engineering team can say “yes” too often.

Taking on too many new projects is irresponsible. An engineering team that is swamped with new projects will fail to update their peers in other departments. That may make the team seem aloof to the rest of the company. 

The end result of taking on too many new projects is chaos, burnout, and misunderstanding. By not managing its projects wisely, the engineering team can put stress on other company departments. 

Therefore, the engineering  team should not accept every assignment from other departments or end-users. A “no” means they are striking a balance with other demands. Before complying with a request, the engineering team must evaluate the request’s urgency, its importance to the company, and whether it is even achievable. All engineering teams must have the discretion to decline a request or new project.

4. Overusing new technology

We are in an era of rapid development and innovation. It’s crucial to stay on top of updates, particularly within the technology team. However, indiscriminately pursuing every new technology is not good for business.

It is risky to deploy cutting-edge or unproven technologies on a daily basis. Before bringing a new technology or tool on board, a company needs to be sure that the new tech will improve its product or its profitability.

You need to weigh the possible benefits of a new technology against the expense, the time it will take employees to learn the new tech, and possible disruptions to business from undisclosed bugs.

In other words, new is not necessarily always better. Sometimes it’s just new. Why would you switch to a new technology that is not yet proven? Especially if your existing tech gets the job done? The old adage, “If it ain’t broke, don’t fix it” may not apply to every aspect of business in the 21st century, but it still applies sometimes. 

There is also a right time to adopt an emerging technology. Knowing the right time to bring in a new technology can be challenging because of the sheer speed at which new tech is being developed. It’s common for an engineering team to adopt an emerging technology too early or too late. 

Adopt too early, and the team will encounter unexpected bugs, outages, and imperfect processes. Adopt too late, and the company loses the competitive edge that this new tech could have given it upon earlier adoption.

There can be no substitute for carefully evaluating all new technology for possible benefits to your specific industry and company. Take the time and energy to make sure that any new tech will repay its costs with interest.

5. Bad code review

All engineering teams need to periodically review code. But code review should occur in such a way that it fixes bugs rather than creating personal strife and office squabbles.

Let’s first look at what a bad code review looks like:

Some code was poorly designed and it is slowing development. Developers are not happy. An entry-level engineer is assigned to review the code The review seems endless and takes time away from delivering new features. 

The entry-level engineer who is reviewing code looks at the feedback and requests, then prepares his review. Each engineer who reads the review responds with his own nitpicky criticism.

Furthermore, the reviewing engineer has no tools with which to flag programming errors, bugs, stylistic errors, or suspicious constructs. And there is no consistency within the code. One of the reviewers prefers noun-verb naming, and another prefers verbNoun. All colleagues have different preferences.

During a bad code review, reviewers always argue about the format, such as tabs vs. spaces, and placing the brace in the same line or next line. They compete for the best one-liner or even more layers of abstraction and indirection. Reviewers cannot reach an agreement with variable, method, class, or package names. Reviewers ignore the industry standard norms, like SOLID principles, but require others to comply with their habits.

To prevent your code review from turning toxic:

• Clearly establish the goals for the review. Make sure the reviewers understand what needs to be improved.
• Establish protocols for fixing defects in advance.
• Make code authors annotate the source code before starting the review.
• Don’t throw new hires at code they didn’t have any part in writing.
• Don’t review more than 500 lines of code at a time.
• Don’t let an engineer spend more than an hour at a time on the review.

6. Rewriting code when refactoring is more efficient

Let’s get familiar with code rewrite and code refactor. When you rewrite code, you know the flaws of the original system and what you need to fix. Yet, this means you have to maintain two systems at the same time: the old code and the new. 

Also, since the old system has not been ideal, you still need to fix the bug or add new features in the old one while writing code for the upgrade. You have to do repetitive work for both new and old systems.

Code refactoring is a less drastic approach. When you refactor code, you work directly with the original code, replacing bad code and updating segments as needed. This more incremental approach means you can save on the time and energy involved in going all the way back to the drawing board. 

The drawback is that you can’t alter the fundamental framework or use another programming language. Engineers can’t create miracles with code refactoring, but it may still be the best option if the framework code is still fully functional.

Developers often prefer to rewrite code. And rewriting is definitely the best option if the developer can’t make sense of the original code. That’s why it is imperative to read through the original code in its entirety before choosing between refactoring and rewriting. 

While reading the code, engineers need to look for bugs. If it is possible to identify all the bugs that are hurting functionality, refactoring makes more sense. If the code all looks like Greek to a non-Greek speaker, then a rewrite is in order.

When determining whether to rewrite or refactor, also consider the following issues:

Time

It will take you much more time to rewrite the whole code, fix bugs, and even add new features. You should consider not only your own time constraints, but those of users as well. If client need is urgent, consider refactoring to avoid customer dissatisfaction.

Market Changes

The market is not going to hold steady while you are rewriting. If innovations in competing products emerge while you are rewriting code or rebuilding a software, clients will ask you to add the same innovation to your product. Now, in addition to rewriting an entire product, you are also madly keeping up with market innovations in both the new and old codes. You could get caught in a rewriting loop.

The advantage of refactoring is that you can clean up and respond to new market demands at the same time with minimum resources. Should a massive change happen in the market, you will have space to react with refactoring. 

7. Using microservices for the wrong reasons

Yet one more trait of the ineffective engineering team is using microservices for the wrong reasons.

Engineers should not deploy microservices just because they are cool. Using microservices where there is no good reason for them is worse than being uncool. It’s possible that a more straightforward approach will give you the right results. For many businesses, writing the simplest code possible and getting to market quickly is the better course of action. Engineers sometimes use microservices because they assume they will need to scale the product for more users. But here’s the problem: No one can see the future. That means you don’t know how much (and if) you will have to scale the product or how you will scale it.

Some people consider microservices optimal, but premature optimization can hold up development of minimally viable products. At an early stage in product development, engineers should focus on developing products or services that satisfy end-users’ needs rather than building stunning infrastructure. 

Microservices should not be used for theoretical improvements to functionality. You don’t know what improvements you will need to make to functionality because that’s in the future. Building microservices can take time away from vital testing and other quality control practices. 

Developers need to build infrastructure and develop products at the same time. Other departments might not understand the implications of microservices vs. quick product development, so it is crucial that engineers do not implement innovations they know will hurt the company’s productivity. Engineers may need to educate their peers in other departments about best practices. It is important that an engineering team not be railroaded into acting against its own best interests. 

Engineers who insist on microservices create overly complex code that could cause problems later for other engineers who are now having to troubleshoot bugs in the code. Before investing up front in microservices, consider how much time it will take to create such complex architecture.  

8. A bad software engineering process or the lack thereof (bonus item)

I left this as a bonus item although it’s just as important as all items listed above. From my personal experience this is actually the single most important thing that can make or break a software team.

A good software engineering process translates to quick feedback loops and lots of automation in order to catch bugs early in the process. Here are some of the core pieces present in a good process:

• A solid CI/CD tool integrated and used by all team members. These days I consider CI/CD just as important and basic as a version control system. It’s hard to work properly without this. 
• When a team member pushes code the CI/CD automatically triggers a build of your app/libraries/systems and runs your entire test suite. Some teams go the extra mile to implement Continuous Delivery and are able to ship to production multiple times a day. Continuous Delivery is an indication of how serious you are about quality. If you are onboarding a new engineer there is nothing more appealing than being able to get him up and running and perform his first production release right on the first day (or say the first few days) and with a very high confidence that it’s going to be a high quality release.
• Code Review – this is not a nice to have feature. High performing teams know how important peer reviews are and how it translates to reduced technical debt, less bugs and much better software. Code reviews should be a mandatory step before code gets pushed to production, it’s usually best to ensure each Pull Request (PR) gets reviewed to more than one team member.
• Did I mention CI/CD and automation? This also means adding more layers of automation besides the basic unit and integration tests. For instance:
  • Security tests such as static code scanners and library vulnerability checks. Some teams can also take advantage of security as code best practices.
  • Linters
  • UI tests, including screenshot comparison tests when applicable.
• Going Agile, while also understanding it’s pitfalls.

Conclusion

It’s never been a more exciting time to work in software development. Engineering teams have many challenges, but also many opportunities. By tracking the above red flags of inefficiency, companies can leverage the creativity and excitement of their engineers. Happy hacking!