Avoiding the siren of too smart, too small for your team
One of the challenges of growing an organization in today’s technology industry is avoiding what I call being too smart, too small. It’s when a small company has a few alpha programmers and perhaps a dynamic manager who create such a tight-knit world for themselves that they lock out the rest of the company even the sales and marketing teams.
Here are five ways for avoiding the siren of too smart, too small:
1. Build a culture of openness
When you are too smart, too small, teams look inward as a matter of necessity and time. As a small team, it’s easy to Ironman through things. We all want smart people on our team but when you lose openness is when the trouble begins. Almost always, small teams don’t lose openness intentionally. Often it happens when the team is tired and understaffed. There’s never time to cross train, do proper retrospectives, and risk mitigation gets pushed off until after the next product release, and then the next release…
Build in openness from the beginning by at least trying to follow a proper Agile development process.
2. Use collaboration tools for question deflection
It’s not about choosing the right collaboration platform when you want to avoid being too smart, too small. Rather, it’s instituting a strategy to centralize product and project information, so it’s all searchable by anyone with the appropriate access privileges.
Modern SaaS collaboration platforms can serve as a repository for all the bits and bytes that project teams collect, but you need a simple question deflection strategy like this one:
- Use team scrums and retrospectives as an opportunity to encourage team members to file documents and other project artifacts into an agreed upon cloud repository
- Encourage team members to search first, question second when it comes to project questions
- Rinse, repeat
Moving to question deflection requires a cultural shift but also the commitment from the project manager, team members, and other departments in the organization to keep filing documents and project artifacts in an agreed upon location. Workers outside the project team also need to be reminded to go online for before they bother a team member with questions that have already been answered online.
3. Document systems
Major technology systems shouldn’t be a matter of oral history, you need documentation or important details that operations, sales, and marketing need to do their job remain locked away in the minds of the development team.
With small development teams, it’s nearly impossible to have programmers document their work in detail. There’s probably not even time for a technical writer to conduct substantive interviews with programmers and other subject matter experts.
Bake documentation into your processes and set expectations that documentation much like your product features will grow and evolve iteratively.
4. Record web conferences and use chat logs
Taking notes in a meeting is often a waste in the age of web conferencing. So turn on the recording features of your conferencing systems and use chat logs to ensure that any meetings and chats are archived for later reference just as a matter of record.5. Hire a technical product manager
Working with development teams in all sorts of organizations across business and government; I’m forever convinced about the value of a technical product manager and their role in product development. Without a technical product manager, you run the risk of developers, engineers, contractors, and the sales team diluting product features, roadmap, and other important product vision details.
How does your team avoid being too smart, too small?
Will Kelly is a technical writer and analyst based in the Washington, DC area. He has worked with commercial, federal, higher education, and publishing clients to develop technical and thought leadership content. His technology articles have been published by CNET TechRepublic, Government Computer News, Federal Computer Week, Toolbox.com, ZDNet.com and others. Follow Will on Twitter:@willkelly.