While waiting for a program to finish, decided it was time to finish a blog post I had started but never finished – about a month ago, during the same week, I had come across 2 excellent articles about software development and teams (probably thanks to Jason Haley’s blog http://jasonhaley.com/blog/ which I have a RSS feed into – I think I have mentioned him before – but his blog is an awesome aggregator of software/career/business-related content as well as links at the bottom to other aggregated blogs – if I could only have one RSS feed for software-related news – his would be it – again great job Jason)
Coming across these articles around the same time really seemed to crystalize my thinking on this topic and it really rings true since it rhymes with what I have experienced as well having been on a number of teams.
The first article I had come across a while back was titled Focus on building 10X teams not hiring 10X developers – which I thought did a great job explaining how to build a well-rounded team, and how you need people of the varying types (Leaders, Hustlers, Teachers, Engines, etc) and how a balanced team is far more effective in the long run. The article concludes that since software is complex and since you need teams to execute, that the effort to put together a team that functions great together is far more important that finding a single crazy-talented individual. I love their picture here.
But then this article from Harvard Business Review really started to round out my thinking. Published this last April, it was named The New Science of Building Great Teams – You see, a team from MIT wanted to measure “what exactly” it is about high performing teams that could be identified so they started with a call center for a bank, outfitted all of the teams with electronic badges around their neck that could measure their communication with others – it could measure tone of voice, body language, whom they talked to and how much, and even body position relative to others—whether people face each other and how they stand in a group.
They learned that the very best predictor of a teams productivity were a team’s energy and inter-team-communication OUTSIDE of of formal work meetings. The team could predict with high success which of a manager’s teams were the highest performing simply by comparing the data gathered by the electronic badges regarding which teams had the highest interaction with each other – which is pretty surprising in a call center, you would expect the opposite. So in this call center to help prove their hypothesis, they asked the manager to allow the people more time to socialize with their teammates away from their workstations, and had the teammates schedule their breaks all at the same time – and their efficiency at work improved by 20% among the lowest performing teams and 8% companywide with this small change. They went on to study this at a number of other companies and industries and came up with the same conclusions.
Check out this statement from their article
We’ve been able to foretell, for example, which teams will win a business plan contest, solely on the basis of data collected from team members wearing badges at a cocktail reception. We’ve predicted the financial results that teams making investments would achieve, just on the basis of data collected during their negotiations. We can see in the data when team members will report that they’ve had a “productive” or “creative” day.
The data also reveal, at a higher level, that successful teams share several defining characteristics:
1. Everyone on the team talks and listens in roughly equal measure, keeping contributions short and sweet.
2. Members face one another, and their conversations and gestures are energetic.
3. Members connect directly with one another—not just with the team leader.
4. Members carry on back-channel or side conversations within the team.
5. Members periodically break, go exploring outside the team, and bring information back.
The data also establish another surprising fact: Individual reasoning and talent contribute far less to team success than one might expect. The best way to build a great team is not to select individuals for their smarts or accomplishments but to learn how they communicate and to shape and guide the team so that it follows successful communication patterns.
A lot of common sense in this article but some real surprises too and it was amazing how applicable across so many industries that their scientific data bore this out. The fact that electronically managers could be able to measure inter-team energy and be able to correlate that to a teams productivity was amazing and as the article concluded…”it will change how organizations work.”
And finally, I had come across an oldie-but-a-goodie – this blog was posted way back in 2009, can’t remember how I stumbled across it again recently, but it was some of the comments that really rang true for me
During the discussion in the Comments of whether software development is actually software engineering following very specific patterns, etc, these 2 comments at the bottom really made me nod – especially the portions I highlighted below
It saddens me that thisis the case, but in my experience it’s also true. I have never seen engineering principles carry even a moderately complex project through to success in the absence of genuinely passionate developers. Yet I’ve seen passion create amazing software without a heavy engineering process time and time again. I firmly believe that skilled, passionate devs will naturally create and follow an effective engineering process without intervention simply from a desire to create. Deadweight devs, on the other hand, will never create profitable software no matter how much process you throw at them.
Greg D on July 19, 2009 6:15 AM
I have maintained for years (and nothing has changed my mind yet) that software development is all about the people. If you have good people around you, people who care, who have courage and integrity you will succeed no matter what.
I think that is what the spirit of agile is all about, it’s not pair programming or refactoring (those are just a means to an end) it’s about the people, the environment and how they interact, it’s about getting everyone just a little bit personally invested in the success of the project. That doesn’t sound like any sort of engineering I’ve ever heard of.
Alan Skorkin on July 19, 2009 6:21 AM
Both comments were well stated and ring true with me as well – you see, on my wall in my office hangs the Agile Manifesto with a single line highlighted similar to the below picture
Have a great Memorial Day Weekend