DPP's Blog

Team Mind Melds… Very Important March 18, 2013

Back in the day, I ran a small spreadsheet company, Athena Design that took on the big spreadsheet companies (Lotus, Informix) and won.

I had a spectacularly stellar team. At the time I just thought the folks working at Athena were bright… but in retrospect it's amazing what a collection of talent with had.

What we had that was much, much more important was a mind meld. We were able to exchange very complex ideas, very important "stuff" related to customer needs and future goals very easily. We all spoke the same shorthand and could make amazing things happen. I also admit the company was pretty dysfunctional and there were a lot of things that could have been improved… but our ability to deliver excellent software, quickly, and zero in on what our customers wanted was a testament to just how well we worked together.

Life in Lift-land

The Lift committers are an amazing group of folks who have built an amazing piece of software, written some darned good books about it, and support thousands of people each year on the Lift mailing list.

Most of the Lift committers are exceptional and shine in their respective organizations.

But it took nearly 3 years for the Lift committers to really get into the communications groove that we're in now.

It takes time...

It takes time for a team to develop a mind meld. It takes time for team members to understand the subtleties of each others' communications. And even the very best developers communicate differently. Allowing time for the communications to normalize is important, especially when assembling folks who have been excellent in their own right… each of these people has different patterns and different ways of working.

But there are shortcuts...

And those shortcuts are generally memorialized in Agile.

So, how can a team learn to work together more effectively?

  • Discrete successes. Nothing breads excitement and willingness to bend to another person's style than group success. Having periodic (weekly, bi-weekly) deliverables, nailing the deliverables and moving to the next cycle/sprint/thingy is key in showing a team that they can work together.
  • Lots of small, digestible communications. Stand-up meetings, wikis, group chats, Markdown documents in the repo, pictures of whiteboard sessions, etc. are all very important ways for a team to share information and get to know each others' shorthand.
  • Open communication. All communication should be open… and if two people have a meeting over lunch, they should document it someplace where everyone can see. One of the best things about Apache software projects is there's firm rule that if it doesn't happen on the mailing list, it never happened. That's critical for teams… that all decisions, information exchanges, etc. are done in a public place, in the light of day, in a way that new team members can easily assimilate.

  • Exploration. It's almost impossible to get an implementation right on the first try and it's difficult to get a basic design right on the first try. Fostering an ethos of exploration, trying, and feedback is very important to foster excellent team communication. This includes:

    • Allowing people bounded time to test ideas.
    • Failures with a good post-mortem are often more valuable to initial successes and should be celebrated as such.
    • Exploring from the user-back rather than the technology stack forward.
  • Users. Know your users. Give them names. Build things for them. Generate excitement around "Sam the data entry guy" and "Sally the executive dashboard queen" and the other pseudo users you bring into your projects. Different developers will advocate for different pseudo users and when someone is advocating, they'll work a lot harder because they are on a mission. Missions breed missions just as success breeds success.
  • Know the different between a user story, an implementation, and a technology stack. Focus on the user first, the simplest implementation second, and the technology dead last.

It's up to you

As you assemble a team for the next killer app/disruptive mumble-mumble/change the world thingy, keep in mind that the communications patterns you lay down early will shape the team and shape the product and shape the user satisfaction level of what you're building. Focusing the team on communicating with each other will allow them to listen to the users and build something amazing. Having a team of very excellent people will allow you to achieve very excellent things if you can get the communications cycles rocking so the delivery cycles rock.