As the head of engineering at Atlassian, I’m part of a lot of interview panels (Like, a lot). I know I’ve got an above-average candidate sitting across from me when they start asking questions about the team they’d be joining. Some ask about the team’s culture. Others want to hear specifics on software development practices or the tech stack.

In essence, what they really want to know is this: is the team effective? 

It’s a question every developer should be asking any time they interview – and that every engineering leader should be able to give a clear answer to. Heck: leaders should be asking themselves this questions every week. Seems simple enough on the surface, but there’s a catch.

There’s no magic metric for gauging effectiveness.

For years, our industry has focused on measuring efficiency, using dubious metrics like number of bugs created vs. resolved, rate of passing builds, story point velocity and others. While it’s helpful to know how fast your team is moving, those numbers won’t tell you whether the features you shipped this week were the right features, or whether your builds are running the right tests.

Signs of effective software practices
Until that magic metric for software team efficacy comes along, we’ll have to make do with looking for a few key indicators. Use this list whenever you’re considering moving to a new team (even inside the same company), or whenever you simply could do with a dose of self-reflection (which, honestly, should happen on a regular basis).

  • Quality of releases over time – Are releases consistently high quality? How often are deploys being rolled back? How often are progressive rollouts aborted?
  • Coding standards – Do they exist? Are code analysis tools used to avoid wasting valuable code review time?
  • High-quality tests – Are the tests fast and dependable? Do they run automatically run on a branch before any code reviews occur? Do they cover a large portion of the code, including the stuff outside of the happy path?
  • Continuous development – Can everyone on the team get changes into the dog-fooding environment and production easily?
  • Code review throughput – What is the average time a pull request (or code review) waits for the required number of reviewers to review it?
  • Code review participation – How well are the code review responsibilities distributed amongst team members?
  • Technical debt – How much technical debt is there? How much does this overhead drag down the team’s velocity?
  • Architecture – Is the architecture sound and how well does it scale? Are there patterns in place to protect customers’ security and privacy?

In addition to all that, the hiring process should be transparent, with clear standards the team expects any candidate to meet. Standards should be both high and inclusive of people from traditionally underrepresented groups. For example, relatively few women contribute to open-source projects, so requiring contributions to open source effectively shuts out a huge group of highly qualified candidates your team could have benefited from.

It’s unlikely you’d have a chance to talk through this entire list in an interview. But if the hiring manager hits several of these points, that’s a sign they’ve got solid experience and know what they’re doing. Remember: being a great engineering leader requires a whole different skill set than being a great developer. Kevin Scott, former SVP of Engineering at LinkedIn and current CTO at Microsoft, sums it up nicely:

“Calling all engineering leaders: please start spending a disproportionate amount of your management time thinking about culture as a design process.”

Signs of effective teamwork practices
You can’t get the full story unless you spend time talking to members of the team about how they work together, and how they work with other teams.

At a minimum, verify that the team has visibility into the larger goals of the business and aligns their team-level goals with them. That signals not only a basic level of transparency throughout the organization, but shows that engineers trust leadership to set the right direction. It also indicates that engineering leaders actually have time to think strategically and aren’t just reacting to one problem after another.

Pay attention to feedback loops as well – both the technical kind (builds, tests, etc.) and the human kind. Frequent, helpful feedback from peers and managers is crucial for career growth and healthy teamwork. Each person on the team should have a clear understanding of the roles they play, what’s expected of them in those roles, and whether they’re meeting those expectations.

What if the signs are inauspicious?
As a developer, there are lots of things you could optimize for when looking for a new job: a culture that suits you, a tech stack you’re excited about, a product you’d feel proud to help make. In my experience, none of these can compensate for the frustrations of being on a team that isn’t effective. If a software team has good answers to many of the questions above, they are probably doing well and are worth joining (or, if you’re the hiring manager, worth bragging about).

It’s rare for a team to be so far gone that there’s no hope of becoming effective. My go-to method for building effective collaboration is the Team Health Monitor – an eight-point self-assessment for teams we developed at Atlassian.

How healthy is your team? An intro to the Team Health Montior

The Health Monitor is a great tool for engineering leaders who want to make sure their teams are attractive to the most talented developers out there. And while I don’t recommend developers join a struggling team in the hopes of rescuing them, the Health Monitor is worth trying with the team you’re on now. Maybe you won’t feel so antsy to land a new job after all.

Mike Melnicki is a life-long developer and currently head of engineering for developer tools at Atlassian.