Last week, I wrote about the importance of building an internal developer community on the back of a talk at DeveloperWeek NYC about developers deserving better communication tools. I shared my thoughts with current customers and those evaluating Stack Overflow Enterprise, and a consistent theme in feedback that I received was that it comes down to the type of engineering culture a company has in place. This led me to dig back into my notes from other talks at DeveloperWeek. One that was particularly interesting and topical was Hamid Shojaee’s talk about common traits that successful Agile development teams possess. He broke it down by rightfully arguing that there are two types of development teams: those that say, “We can do anything!” and those that say “Well, we’ve never done that before…”. After spending the last five years talking to CTOs, CIOs, and engineering leaders focused on transforming their culture, the “We can do anything!” teams have similar characteristics: They have a “do” instead of “ask” mentality They are consciously and actively putting practices in place to fix problems within. Engineering teams that have a “do” mentality are generally smart and eager to get things done instead of asking others to handle the job for them. They are willing to fail Engineers on these teams take a calculated approach to risk but, most importantly, they are willing to fail and will stick their neck out to make a change in their organization when needed. As doers, they look at the positive and transformational change that they can make in a project/product or in their team. They're collaborative We’ve written a lot about how pair programming can make for a better programmer, how engineering managers can improve communication between technical and non-technical teams and how engineering managers can effectively manage a remote team of developers. The key theme? Collaboration! Engineers on the “We can do anything!” teams are consistently communicating & collaborating with one another in an effort to learn from their colleagues. They're metrics-driven When it comes to improving the collaboration between teams, for instance, engineering leaders that believe they can do anything don’t just rely on the accepted fact that it needs to be improved. Rather, they proactively poll their engineering teams about how long it takes them to get a peer-validated, objectively accurate answer to a question, how many tools they need to go through to find that answer, the number of steps involved, etc. They prefer fewer, more useful tools Engineers are most productive when they’re in a distraction-free flow state and writing high-quality code. Companies that give their engineering teams every tool under the sun are actually preventing them from getting into this state. “We can do anything!” teams understand that there are only a few mission-critical tools that their engineers need to get their jobs done; all the rest are a hindrance to individual and team productivity. There’s a clear cultural divide between the two types of teams: what type of team are you a part of?
There are Two Types of Engineering Teams. Which Are You On?
