what makes a team successful

I recently wrapped up a contract for the VA that I’m quite proud of. My team built a new foundation for the frontend of va.gov, laying the groundwork for rapid publishing of over twenty-seven thousand pieces of content (and counting!). As proud as I am of our work, I have even more pride for my team. It was my first experience as tech lead, full stop. Not “just” front-end lead or subject matter expert for a particular system, but as lead of the whole shebang. And I personally think it was a healthy high-functioning team, and that is what enabled us to hit our delivery despite all of the chaos that envelops the VA’s development & contracting processes.

Why was the team so successful? There are a number of reasons, but I believe what it ultimately boils down to is one word. Trust. I said “trust” a lot in a recent company spotlight interview, and I’m going to say it some more here.

The core team for this project was small, six people in total. We had a PM/DM type, me, two FE engineers, a Drupal engineer and a devops engineer. our PM was also transitioning from a fullstack engineering role. So a team of six engineers. There was additional support from contract managers, coaches, VA OCTO folks, etc., but the day-to-day core group was small and nimble. We built trust among ourselves early on in the contract with a lot of animated discussions around the proposed architecture. We were inheriting a skeleton codebase from a previous effort at the VA to solve this problem. The PM and myself were actually a part of the previous effort, so we had some familiarity with the code (though it had sat untouched for at least nine month after the initial contract ended) but still needed to brush up.

From the beginning, I did not want to act as a micro-manager for all technical decisions. I wanted us to come to consensus on the desired architectural approach and then make it happen, without being a roadblock. We also needed to determine how much of the previous effort was still relevant and how much we would need to refactor or build out entirely for ourselves. Those animated discussions were invaluable for us as a team to feel out working styles, big picture thinking, the feature roadmap, and how we’d divide and conquer. We had a number of spikes, prototypes, and more discussions. We didn’t always agree on final approach, but most decisions were determined democratically. Some were dictated a little more strictly from the VA proper, but for the most part the big picture was a truly collaborative effort. This collaboration built strong trust across the team, and folks took strong sense of ownership over the areas they did build personally. That ownership built further trust.

Another huge source of trust was from the VA itself. Our stakeholder was someone that we had worked with closely for several years, so they generally stayed “hands-off” and trusted our team to accomplish the work by the contract deadline. This gave us a little more lee-way in sprint-to-sprint planning, and took some immediate pressure off. We still delivered value each sprint, of course, but our team was a little more comfortable with having a few larger-sized tickets that spanned sprints on occasion.

As I stated in that spotlight interview, I trusted my team implicitly. I knew we had each other’s backs, no matter what came up. Early on in the contract, my grandpa died and I missed a week. Later, an ice storm hit Portland and my power was out for six days. I missed another week. In both cases, my team picked up my slack without missing a beat. They knew what we had set out to do. Other team members experienced similar events over our nine month contract like planned vacations, funerals, weddings, power outages, home appliance issues, you name it. In all cases, we rolled on as planned and trusted ourselves to get it done. Because we said we would. And had repeatedly shown one another that our word could be trusted.

Obviously, a successful team is not only dependent on trust. The competency to do the work to a certain standard must be there too. But once someone’s demonstrated that standard repeatedly, it is easy to take for granted that any additional work will also be near that level. Or if it isn’t there, that someone will speak up to ask for help. That takes a level of trust too, to ask questions without fear.