How to make small teams not suck
(credit to someone on the Rendezvous network for the title)
Another SXSW Panel: How to make big things happen with small teams
Reducing mass
Making things manageable
Lowering cost of change
Staying out of debt
When you write bad code, make bad decisions, you’re building up debt that you’re going to have to pay off later (one way or another)
Advantages of small teams:
- Close to customer
- Less distortion when passing information between different organizational layers
- Change is easier
Important thing isn’t having more people, but the right people
Build half a product, not a half-ass product.
- Say “no” by default – whenever someone requests a feature (including yourself), say no. If they (or you) keep asking, then consider it.
- Listen to the product
- Every decision is temporary
- Ignore details early on
- Ignore features
Build less software
- Lower cost of change
- Less room for error
- Less support required
- Encourage human solutions
Give people just enough to solve their own problems their own way. Build general, rather than specific, and get out of their way.
Sunk costs: Just because you spent money on something doesn’t mean that you need to use it. The money/time’s already spent.
Feel the hurt: people who design software should have to do tech support for it. By sharing the annoyance, you’ll fix the most urgent problems first.
- Chefs become waiters
Release:
- “Feature food”: little features that everyone wants to eat, pass on and talk about. (Essentially, appeal to vocal minorities)
- Promote through education
- 30-day major upgrade: hold back a few key upgrades, upgrade in 30 days. Makes you look on the ball and continually upgrading.
- Transparency = Trust
- Bloggle: Google + Blogs = lots of new traffic
“Code Smells”: when you write something and think “I never want to touch that again.” BAD!