Five times now I’ve worked for a startup as it went through a growth phase (major round of funding). When it worked well, each new team member made the team stronger. When it didn’t work, the company was a revolving door. For development teams, it’s a tricky time.
Early developers enjoy high individual productivity as they work with the technology they know (or have pioneered). Adding more developers does not mean an immediate increase in productivity. More team members requires more interaction, planning, and code interfaces.
Developers are a quirky bunch. There are geniuses that come to work when they want (or not at all). There are verbally challenged code generators that turn out code faster than the team can agree what to build. Lone wolves that go off on all nighters and don’t come back with ship-able code. Work-from-homers that need to be “skyped in.” And the loyal guys that do what the boss wants today without finishing what he wanted yesterday. Not to mention the “leader” that rarely takes his headphones off.
For the people I currently work with, don’t worry – I’m not thinking about you ;-).
In this storming, forming, and norming process the team needs to set guidelines on how to work together. I’ve written before about 10x developers – a similar concept applies to productive teams. I’ve never been trained as a manager, but there are a couple things that keep coming up. It is critical to establish a team agreement centered around communication. What kills startups are the things that left unsaid, so nail down a few specifics with a “team agreement” document.
Example agile team agreement
Work on the right things for the business
Increase leverage by improving our skills and using the right tools
Ship code that works
Have unit tests and be able to ship often with confidence
Stand-up meeting at 10AM M-F: 1 minute to report on what you did the previous day, what you are doing doing, and what you are blocked on
If you can’t attend, send in your status update via email
Be available on Skype when you’re working
Sprint planning and process
A weekly sprint to complete top priority items from the backlog
Tasks recorded in Trello (or sticky notes, or whatever works)
Task complexity discussed prior to or during planning
Stick to your assigned tasks during sprint
Any time something gets brought into the sprint, notify the team and create a task to track it
There’s many other things to go into with team-building, but a couple other tangible things keep coming up.
1. Coding standards, including: why spaces are better than tabs. Make a decision as a team, convert your code once, and stick to it. This project samples Github code to determine what the standards should be.
2. Git collaboration workflow. Nailing this early will help. By all means take the time to make sure everyone understands Git as well as deploying code.
What makes your team uber-productive? Leave a comment and let me know.
Add to the list of personality types: the developer that works quietly for months then suddenly quits citing a list of concerns that he never voiced. Or, worse quits for “no reason.”
This made me lol: “the “leader” that rarely takes his headphones off.” while I was wearing headphones. My team looked at me a bit weird. This isn’t just devs, but any people manager who still has an individual contributor role.
It’s OK to have focus time, but technical leaders especially have to realize that leadership is a people-problem, not a tech problem.