Reposted from George K’s blog: http://gkontopidis.com/blog/2011/building-high-performance-teams-a-lifetime-experience/
This subject has been the theme of many books and recent meetings. Most recently I attended the Mass Technology Leadership Summit on Rapid Development and Deployment; this meeting was one of the MassTLC Software as a Service & Cloud Software Cluster. Details about the promising world of SaaS, PaaS and IaaS can be found in David Skok’s presentation – as a keynote speaker he walked through the explosion of mobile applications and correlated it with the PaaS model. His presentation can be found in this link.
But beyond the analysts reports and VC community do and don’ts, the part that I enjoyed most was the panel discussion on High-Performance Teams by:
- Julia Austin (VMWare)
- Peter Wiley-Cordone (GSN)
- Eric Malafeew (Harmonix)
- Sanjay Vakil, (TripAdvisor)
- Greg Kunkel (Next Jump)
Their discussion motivated me to write the twelve bullets below summarizing my 20+ year experience on this matter:
- High performance teams require clear business objectives, goals and priorities
- do not assign tasks per person
- understand the dependencies
- provide visibility of impact to the revenue
- Innovation cannot be dictated; you can only develop an environment that encourages innovation
- must invest to create such environment
- requires perpetual effort
- To attract talent,
- do not interview for a project, interview for smart and flexible developers
- test for cultural fit – this assume that you already have decided on the culture you would like to have in your company!
- value higher individuals with passion and humility
- ask for specific examples of teams they liked and why
- ask for heroic work they did vs. group achievements
- check references or other colleagues by asking the question what memorable thing have they done.
- Smart people like to work with other smart people; the productivity of an exceptional designer is 30:1 to the “average” – and you only pay them just a factor of two more than the average!
- To increase cohesiveness, seed teams with members that excel at creating a community. Identify the nucleus of these communities by:
- finding the poles of the informal networks
- identifying the magnets of discussion in water fountains, ping-pong tables or coffee corners
- finding who invites colleagues for a beer after work or a golf tournament or a game
- Give the most challenging problems to the best engineers
- it is OK to give a maintenance or support project to an excellent engineer, but upon successful completion you must give him a very challenging goal – aka ping-pong theory from the Soul of the New Machine.
- Distinguish between Architects and Prototypers – you need both!
- Require openness, no black boxes, total transparency; motivating developers to do peer reviews. having incumbents “mentor” new employees. the whole team participate in code reviews after the daily “standups”.
- Celebrate successes and learn from failures
- successes to be justified by external (customer) feedback or revenue impact
- maintenance or support tasks must also be recognized because of the inherent value internally or externally
- because the failures of startups are more than the successes
- extract value from the failure
- focus on lessons learned
- Technical managers are hard to hire or grow internally
- do not force great engineers into management as professional evolution
- do not cap managers from technical involvement
- recognize individual contributors in parallel with the managers
- equivalence of salary and perks
- pay attention to titles and org charts
- To motivate teams to do less glamorous projects let developers fix it the way they way want it, earn the opportunity to do more interesting projects, or bask in users’ appreciation of a problem fixed and a job well done.
- High performance team cannot be distributed at the beginning – in general, remote developers work on tasks not on team goals.
After the meeting, as I was walking with Brough in the Kendal Square T-station, I was bubbling the thoughts above; then he noted:but didn’t we apply the above when we were building the NMS team?
Are you an engineer who like the above? Call me to hire you at once!
Are you a manager who embraces the above? Call me to grub a coffee to chat!