tatiyants.com How Capable Is Your Technology Team?

Do you know how capable your technology team is? How do you assess its capabilities? What do you look for?

When I was asked these questions recently, my first thought was “The Joel Test of course!”. After all, it’s short, easy to understand, and it quickly gets to the root of the matter: can your team reliably ship product?

Well, The Joel Test is also 12 years old. While the principles behind his questions remain relevant, some of the specifics have evolved. The baseline for how a technology team should operate has risen, as has the state of the art.

And so, to answer the question of how to assess a technology team today, I’ve put together a few thoughts below.

So You Say You Can Ship

A technology team is only as good as its ongoing ability to ship product. What does that entail?

First, let’s talk about building software. Probably the fastest way to understand how good the team is at this is to look at their engineering practices. There are, of course, the basics:

Are all code artifacts (including database and infrastructure code) under source control?
Do they write unit/integration/functional tests for their code?
Are their builds and deploys fully automated?
Do they practice Continuous Integration?
Is all production code being reviewed, either via pairing or formalized code reviews?

Once the basics are covered, the next thing to consider is how stringent their development machinery is. In other words, are there steps embedded into the build system / delivery pipeline to keep the team honest and the code base clean? Some questions to ask:

Are they measuring code coverage? Is it measured at every layer including front end, middle tier, and database? Are they breaking builds if it falls below a threshold?
Are they running code analysis on every check-in? What build implications exist if something comes up? (i.e. does the build break if compiler warnings are found, if coding style is violated, if cyclomatic complexity of a function exceeds a threshold, etc)
Are they running performance/load/stress tests as part of the delivery pipeline? What about penetration tests?

But wait, there’s more. Note that I qualified “ability to ship” with “ongoing”. This was intentional because the team has to keep the cost of change low and constant. In other words, shipping quickly by piling on technical debt without ever addressing it is not a sustainable strategy.

Therefore, you have to look at the development culture for signs of good stewardship of the code base:

How frequently are refactorings undertaken?
Is there a visible, prioritized tech debt board?
Does the development process explicitly allow for time to deal with technical debt?

Related to this is the culture the team has around defects. In particular:

Are defects being prioritized appropriately (i.e. given as much attention / importance as new features)?
Is there a formalized root cause analysis (5 whys) that’s done on every defect?
Is there an automated defect monitoring system that proactively alerts the team?

Finally, we need to consider how the software is actually being delivered to customers.

Is the team practicing continuous delivery? continuous deployment?
Is every positive and negative system interaction being tracked?
Is there automated monitoring? What does the escalation process look like?
Is there automated self-healing (such as server re-balancing, automated rollbacks, etc) in place?

Please note that the questions above are not comprehensive. I’m certain that there are other very important things to look for. In fact, if you have other ideas, I’d love to hear them.

High Technology

Being able to consistently ship great product is crucial to every technology team. However, for some it may not be enough. Depending on the business they’re in, some technology teams may also need deep expertise in a particular area of what I’d call “high technology”.

By “high technology” I mean the type of skill not typically found in your garden variety devs (even great ones). This includes things like expert knowledge in semantics, machine learning, NLP, signal processing, and so on. Some might even put skills needed for advanced performance optimizations or extreme scalability into the same bucket.

Again, though not every team needs such expertise, some do. And for those teams, this additional capability is certainly worth highlighting.

References

http://www.joelonsoftware.com/articles/fog0000000043.html
http://radar.oreilly.com/2009/03/continuous-deployment-5-eas.html
http://www.slideshare.net/noahsussman/continuous-improvement-16013422

So You Say You Can Ship

High Technology

References

You may also like: