Notes to Self (Starting a Company)

So I've decided on a couple of things I'd do if/when I start my own [software] company:


1. Hire great people
Goes without saying, but get this right and the rest follows. Get it wrong and you're screwed before you even start.


2. Make it really easy to try stuff out
I mean really, really easy.  
This covers things like 20% time and study time, but it also covers the much-less-seen act of lowering the barrier for projects.  I have worked in telecoms, healthcare, manufacturing, banks, tech companies and others, and all but one them required you to have hardware sign-off, purchase orders and approvals before you could host (say) a web server.  That kills any kind of innovation stone dead.  
In the one that didn't require budget to start, new proposals generally take the form of working demos instead of  paperwork requesting hardware and developer time.  If the demos impress, then budget/dedicated hardware/developer time can be awarded later.


3. Make all the cool stuff you have discoverable
Did one of the guys in your burgeoning company write an awesome library for testing your new tech?  Now that you've grown a bit, do all the new guys know about the library?
You may write some excellent software that's internally useful, but unless everyone that needs to can find out about it, it's next to useless.  Note I'm not talking about API docs.  They're for when you already know it exists and just to figure out how to use it.
Even internal coolness needs to be promoted.  I've worked for companies that have tens of thousands of lines of internally-useful stuff that people only find out about because they come across it in someone else's code.  Internal talks are good for this, as well as a centralised portal, but the bigger the pool of resources gets, the less useful either approach becomes.


4. Meetings as a last resort
Meetings are more often than not a productivity killer.  That's not to say that the idea of meeting is a bad one, just that the majority have become gigantic timesucks that people hold because they feel they should.
For a developer, having long runs of uninterrupted time is crucial.  No-one produces their best work in isolated 30-minute segments.  I try to limit my meetings to a 15-minute stand-up in the morning so everyone on the team knows where they are, and calls with remote team members as and when necessary.
I say "try" as it seems the rest of the company are onto me and try to foil my plans.  My pet hate - the weekly status update meeting.  If it truly is "just so we can keep up to date with your progress", I can send you an email, or even better you can look on our issue tracking tool (or Gantt charts if your tastes run to the perverse).
Thus the strategy will be if you want to call a meeting, you have to justify it.  Defend your decision to evict people from the zone - if the meeting truly is important and can't be done another way, it shouldn't be hard.


I'll probably add some more to this, but it'll do for now.