Building any new team, takes considerable effort, thought and direction. Building a core startup team, capable of work far out reaching the number and talent of the people involved,is the holy grail, but not impossible.
*substitute as necessary.
- Create and publicise an end goal - To get the best out of any team requires direction. That direction comes from identifying an end goal. What is the team really there for? Not the small every day tasks and job description values, but what is the underlying value that the team gives above and beyond anything else they have to do to achieve that? Those goals are generally far reaching and ambitious but still succinct and easy to understand and benchmark. "It doesn't matter what it takes, but our website must always be up" etc.
- Identify the path ahead - The path ahead will be rocky. But it needs identifying for at least the next 6 - 12 months. The finer points of that journey will (and hopefully should) change. That's the flexibility of working in a new and generally small team. The route should include key milestones (either product, personnel or team related) that can be measured. If you can measure it you can alter your direction to make sure you stay on track.
- Choose the right tools to help you - This is vital. Tooling could be as simple as the making sure your hosting provider or IDE are consistent and correct for your team, or identifying the best framework to choose for tasks within a product. Selecting the correct tools allow you to focus on what your key value-add skills are. If you're a race car driver you don't want to spend time servicing your car. Spend time canvassing opinion and making informed decisions. Involve as many people as possible. It may take longer, but the end result is more robust and long standing.
|Suat Eman / FreeDigitalPhotos|
- Make things repeatable - Standard Agile coding practice is to keep your code DRY (Don't Repeat Yourself) with respect to logic, so this may seem contradictory. What I'm really referring to is simple tasks and operations in the team that can be relayed to others, new team members or even partners, oursourcers and interfacers to your team. If a process is repeatable it can be done my more than one team member (reducing risk) and that generally means it can be improved through iteration and pair analysis.
- Get people with passion - Techies love new stuff. Many know a lot about a lot of stuff - tools, languages, infrastructures, libraries and so on. How do you select the best personnel? Well, ideally that would be through your own personal network. Knowing people individually, either through direct work relationships or recommendations, is considerably better than the standard interview, show, tell and test method. Identify people with a passion in something different. An obscure language. An unheard of rock band. A blog on turtles. The content doesn't matter. If someone has passion, identify it and use that passion within the team.
- Document without being bureaucratic - Documentation is often seen as a hindrance. It's time consuming. "We'll do it later". Creating expressive code that is self explanatory, is a good habit from an Agile / XP standpoint. Use of clear variable and method names for example. But also, document certain processes. Backup steps, roll out process, recovery steps, password hooks and so on. Doesn't need to be War and Peace - a text file on a shared access point, or even a white board note. Get people to work as if they're training someone else to replace them, picking up simple processes, making them repeatable and documented.
- Have structure without restriction - Again this is more focused on simplicity rather than complexity. Basic contact hours for team members. What IM channels can you expect people to use at what times. Set a day each week where everyone is in the same place at the same time. Set a time for a virtual meeting twice a week if people work in different states or cities. Also important from an organisational perspective, is making people aware of who to go to for certain company or personnel related issues. A basic structure allows people to understand their role and what is expected from certain people and scenarios. This allows them to concentrate on what they're good at.
- Add pizza, music and beer* - Building a successful team isn't just about the product, company or 'results'. It's about building individual careers and personalities. Work is the place you spend the majority of your waking hours. Make it fun. Make it personal. Make it real life. Share interests and order a few chilli-beef pizzas and a carton of beer for Funday Friday's. It's only a job after all.
*substitute as necessary.