10 Ways to Tell if Your Engineering Team is Top Notch
So you’re running engineering and wondering if your team is any good. The fact that you’re thinking about this is good news.
Assuming a team can deliver even if they’ve done so in the past is probably a bad idea because teams, products and businesses evolve and change over time.
As the person in charge you might be asking:
“Is my team highly performant in the business and if not, where are the gaps?”
With that question in mind, let’s take a look at some of the hallmarks of great engineering teams.
These are 10 indicators of successful teams:
#1: Devs Care as Much About Customers as Client Services
Many engineering teams don’t think a lot about the customer — they’re often too busy writing code. For these teams, building things and solving customer problems aren’t always the same thing. It’s also somewhat rare to find engineers who think deeply with Product about the customer experience before architecting or writing code. The more successful engineering teams are constantly thinking about the customer experience and trying to understand the customers problems first.
#2: Deadlines Are Considered a Good Thing
I’ve talked to a fair amount of engineers who believe deadlines are set by clueless managers and business-types looking to make their lives miserable. This has given deadlines a negative stigma. But the best teams embrace deadlines set by themselves and the business. These teams understand that deadlines are a reality of operating a profitable enterprise, and are also a good forcing mechanism towards achieving an important goal. They also understand that most of the time deadlines are negotiable and that engineering can and should have a strong voice in setting the dates.
#3: Devs Avoid Building from Scratch
Building home-grown solutions is often the path engineering teams prefer. It’s often easier if they do it themselves rather than deciphering solutions others have implemented. Sometimes they’re right, but more often that assumption turns out to not be true. So it’s more difficult to find engineers who consistently think of leveraging pre-existing software. It’s even harder to find an entire team with this mindset. But, when you do find them, it’s usually a recipe for building great software, fast. Btw, this doesn’t ignore the success of open-source. It’s just pointing out that even with open-source, engineering teams think more highly of their own skills, than those of others.
#4: Good Estimations is a Skill the Team is Proud Of
Humans are terrible predictors of the future about most things. And when it comes to development estimations, it’s really no different. I’ve found that the best teams work on overcoming this innate deficiency, and over time become very good at the skill of estimations to the point where they can consistently (roughly 90% of the time) deliver on time. Getting estimations right has a massive effect on the rest of the organization. If you are good at it, you will build huge confidence in software delivery within the org.
#5: There are No Untouchables on the Team
The worst teams have one or more untouchable (often uncontrollable) developers who does the majority of the work, winning all the praise, with a bunch of mediocre developers who are just kind of hanging on. These teams are never as effective as a highly collaborative, high performance groups of experienced engineers without a rogue developer. That doesn’t mean that great teams don’t have rockstars. It’s just that in those teams the rockstars work under the same standards as everyone else, and work with everyone to maintain the harmony of the team.
#6: Metrics Permeate Everything
There are some teams that simply understand that metrics being run against everything they do is an awesome thing. That’s because those metrics enable them to find process bottlenecks that will drive performance optimizations. Of course, it also takes a manager who doesn’t wield metrics maliciously to create an unnecessary accountability dynamic. So, the best teams know how to use metrics to improve themselves as a group, without wielding them as leverage over specific individuals in a negative way.
#7: The Team Communicates Well Externally
I’ve found it to be an untrue stereotype that engineers are bad at communicating. That may have been true 10 or 15 years ago, but in todays environments developers can be just as influential as anyone — even in traditionally non-tech industries. The best teams usually have 1 or more developers who communicate very well and can champion the cause of the team outside of the engineering org. Weak teams have nobody in this role, and cannot make their voice heard, and thus get forced into sub-optimal situations (like a poorly set delivery date).
#8: QA is Equal in Importance to Pure Development
Are quality assurance activities, like writing test plans, developing test scripts, and so on, given equal attention as writing code? The mindset in the best engineering teams is that everyone, including the developers, product owners, and QA teams, are responsible for quality. That usually translates into a strong culture of testing across different groups. Even if the engineers are segregated from QA, they know they have a critical role to play in testing, and care about the quality of the final product.
#9: Just Enough Process
Every team has a different sweet spot for the amount of process they should have to function effectively. It usually depends on a multitude of factors including the size and makeup of the team, the type and complexity of the software being built, the organizational culture, and so on. Good teams don’t shy away from process, but neither do they create process for process’ sake. The best teams are constantly adjusting and improving development process to fit themselves better, but in a way that minimizes process overall as much as possible.
#10: The Team has an Outlet / is Able to Vent
No team can burn white-hot indefinitely. Each team has a cadence, including when it needs to turn on the release valves, and let go of some tension. For bad teams, either the release mechanism doesn’t exist, isn’t followed well, or is ineffectual. For great teams, the cadence for releasing the pent up tensions and frustrations of the group adjust to whatever the current environmental stressors are. That means, for example, that better teams know how and when to celebrate big wins, like meeting a crucial delivery date.
They are other indicators than these 10 of course, but these are based on my own experience with large and small teams. I have found them to be quite common across various successful organizations.
Finally, it’s safe to say that if there are gaps in your team around one or more of these indicators, fixing them is definitely not an overnight job.
In fact, some of the fixes might take 3, 6, or even 12 months — possibly longer, depending on the scale and organizational culture involved.
In any case, if you run a team or will be running one soon, look for these indicators as soon as possible. And if you find there are gaps, start building a plan to mitigate.
