I’ve been lucky enough to be involved with teams that built great products at Shutterstock the last few years (previously at Beatport and the team at Native Instruments as well.) The word “great” can be a little ambiguous, let’s refer to products that have disruptive attributes - stuff that’s ground breaking, profitable and/or deemed by it’s constituency as creative. While no one has the perfect formula for continuously delivering ground breaking work, there are a few traits of these teams which I thought worth sharing. There’s a reason this is such an important topic, especially If you are building for web or mobile: you are competing with highly iterative and risk seeking teams somewhere else in the world that have a lot less to lose. In other words, building something great is now par for the course - if you develop a half ass product, someone will build something better a few months later and put you out of business.
Keep the team small - including stakeholders
"Nothing is what happens when everyone has to agree" (Great quote from Seth Godin). Your team should be just big enough to be able to execute all the necessary tasks. This goes for stakeholders outside of the team as well - if you have 4 or 5 stakeholders who need to be notified every few days, you’ll eventually drain every ounce of creativity from the project. In product development, some of the teams I’ve seen work best are in the 6-9 team member range including dedicated development, design, QA, and product at the least. Assign roles in a way that key decisions don’t necessarily require everyone’s vote, but they have a forum to voice their opinion. The small team must be bought in to what you are doing even if they may disagree on some details.
Practice organic communication
Scheduling a meeting is not a solution to a problem. Sometimes a 5 minute chat by someone’s desk or a quick whiteboard session will get you past a difficult spot more effectively than scheduling something for next Tuesday. More “off the cuff” communication or “organic” meetings are great ways to foster teams who need to break new ground. People talk about “brainstorming” meetings to discuss ideas, but I haven’t seen that work too often. Scheduled meetings are better suited for information sharing and creating alignment; adversely, they can be a bad forum for creative problem solving. There are a few caveats to organic communication.
* Don’t annoy your team-mates, some people really need long periods of time to think - especially in technology. If you want to have an impromptu meeting with someone, be empathetic to their specific workflow.
* Hey meeting guy, If you are the type of person who finds yourself in back to back meetings all day (I put myself in this category far too often), you may not be best suited to be the creative driver of a team. Back off and let the people closest to the problem solve it.
* Places to think, talk and problem solve, Surround yourself with whiteboard paint, hang up dashboards with goals that your team wants to reach, create visual omnipresent references to the problems you are trying to solve.
* Team’s sitting together, organic communication tends to break down when your team isn’t sitting together. I can’t stress how much co-location can help create outstanding work.
Dont’ try to fit it into a schedule - there’s no start and end.
If you want to build something great, you’ll need to let go of the notion that it has a start and end point. The thing you release the first time will probably suck anyway and you’ll need to fix it, so get over the idea of a “project” within a fixed set of time and resources. Besides, “fixing it,” or iterating based on customer feedback is when the real learning starts anyway. I like to think of it as the beginning of a relationship between the build team and the customers who will use the product. During this relationship with the customer, needs will change and you’ll have to change with the by letting go of things you previously held close. This concept is difficult for companies to grasp because financial systems, RFP’s and manufacturing processes are all designed to put your development into a box or a timeline, but that’s the antithesis to creating something wonderful.
Get a team of “Do-ers”
Some of the best work I’ve ever seen came from a team of can-do personalities with the right mix of fearlessness, passion and curiosity. If we are talking about ground breaking work, I’ll take a group of scrappy production level folks who are passionate about solving customer problems over “strategy/idea” people every time. We all read books about “insert genius CEO here” and that makes for great story-telling, but I just haven’t seen that work in real life - your CEO is busy. My favorite teams are a group of cast offs with a chip on their shoulder, the ability to dig deep into a problem, a healthy dose of humility and a love for their craft. This obviously isn’t’ a black and white issue, because lots of teams have different personalities, but there’s something to the notion that when people feel like they are overachieving, the passion inside of them leads to good things. Which carries me to my next point:
Create flow by intelligently stretching teams.
Truly enjoying the work you do lies somewhere between what you are capable of and a challenge you’ve never quite met. This goes for teams as well. If the challenge is something completely out of their reach, frustration will set in because the goal seems unobtainable. However, if it’s something they’ve done over and over, they will be bored and/or not put in their best effort. If you want great work out of your team, help them set the goal just out of reach, but not in a completely different zip code. Mihaly Csikszentmihalyi has written books on flow that are great reading and I’ve seen this stretch rule act as a practical application of his research.
Create a direct line to customer empathy
One sure way to build crappy product is to remove the team’s connection to the customer. In a perfect world, the people writing the code are the same people talking to customers. I’ve seen lots of organizations add too many links in the communication chain - nobody is going to feel customer empathy by looking at bullet points in a powerpoint presentation. If you want to build something wonderful, get your developers and designers in direct contact with end users and remove the phone game. The working team has to feel the customer pain deeply to build something awesome.