I might be biased because I’ve worked in such small companies, but it seems to me the best evidence of a high-performing team is when nobody cares about boundaries.

The developer and operations engineering roles have been separated for far too long. Andrew Shafer blogged about the need for a “joining of the tribes” back in July 2008, and that post stuck with me ever since. I’ve been guilty of perpetuating that separation myself, trying to partition responsibilites clearly, and becoming defensive when a brilliant developer stepped into “my” database and systems “realms,” but I’ve begun to see the light. We (I) felt the need for control, especially in a high-pressure environment where there was no upside to IT performance, only questions about why and when the problems would be fixed.

An even greater “interface layer” exists between engineers–whether systems, network, database or software–and managers/business people. Today, I was reading Hal Pomeranz’s “The Blame Game” about how IT leaders need to get past finger-pointing and get working on resolving a problem, and it struck me how these are two sides of the same coin. We all talk about teamwork, but too often, we tend to think of our team ending where our competence ends; then we can become defensive and develop clever ideas like a management metric dubbed the Mean Time To Innocence, a measure of how long it takes a group to absolve itself of responsibility.

There’s less room for that kind of thinking in a startup and no tolerance for it among younger workers who are more used to working collaboratively. But the actual practice of becoming agile can be painful. Failure as a teaching and teambuilding exercise is a hard sell. But learning how to solve problems requires experimentation. The key is to choose battles well–read the manual when you can, but work hard to build a culture of trust where motives are not questioned and good intent is assumed.