jwedgwood

Not just beta invites and email promotions, but also emails to advisors and early investors. It's more than just a reminder of what the heck you do, it's also handing them language to talk about your business to other people.

For beta users, advisors and early investors - these people are going to be your advocates. You need to give them the tools to advocate for you, and a well crafted 3 sentence elevator pitch that describes your business is a huge help.

>> Matters of face, allegiances, and frankly who's in a bad mood on what day determine outcomes as often as logic.

This is so true. Matters of face can spiral out of control easily. I think you handled this specific one with real dexterity.

One related thing from my own experience - As groups grow you tend to get moments where the community norms that everyone took for granted can't be assumed anymore.

It always starts with a single person operating outside those norms. You're faced with the question of whether you have a one-off situation, or a systemic problem (of which this one moment is just the first inkling). Knowing which approach is the right one seems like it's frequently gut feel, but then again, if you know that you are going to need process or guidelines soon, you can use see those moments as an opportunity to get things right before you get bigger problems later.

What Dave doesn't mention in this post is the mindset he brings to these meetings. Honest, open, generous, no time wasted, and he's completely direct. Regardless of how you got to the table, you end up having a super high value discussion because of how he approaches the time.

The fact that he gains so much from these later is no surprise to me. What he gets back later on is just a big karma circle finding its way back to him.

This path is open to everyone.

Well written automated tests will accrue value over time by saving you manual testing time (and increasing your confidence) with each release.

A lot depends on your situation at launch, but I think a lot of teams overestimate how much testing they should do, when in fact their bigger issue is not having enough customers, or not engaging their customers with a decent product.

If you have time, my suggestion would be to focus on a few items:

1) Notification tools to help you know when something goes wrong (e.g. email to the dev team). If you are using ruby, then http://hoptoadapp.com is a great tool, but if you can't find a tool, write your own. It's worth it.

2) Monitoring tools to know if the site is down (e.g. pingdom)

3) Figure out how to cleanly do site updates with zero downtime. This will let you fix the inevitable bugs without inconveniencing users who haven't hit the bug yet.

4) Write automated tests for the things that you think really can screw your users the most.

5) Develop a culture that, when you find bugs in production code, you write tests to reproduce them, then fix the bug, then use the test to validate the fix.

My two cents.

Yeah, we relied on hoptoad as our backstop too. We used CruiseControl.rb running on a cheap low end server with a plugin for doing deployments.

https://github.com/thoughtworks/cruisecontrol.rb https://github.com/aentos/ccrb_cap_deployer

The code is simple to understand, self contained, based around rake, and worked almost immediately for us (after some configuration). We were a two person team. I don't know if the setup we had would have worked with a larger team.

It felt like it made an impact in our ability to turn code faster. We had a solid test suite, which helped.

Great article, and fun to see what is going on inside. We used a similar strategy with great success at my last company (though we were using Passenger).

Once you've nailed the zero-downtime deployment, it's a short hop to adding a small box (or a script on your test server) to do continuous integration and then moving from there to continuous deployment. For our small team this setup was really liberating.

If you head down that path, I'd love to see updates on what your team's experience is with that transition.

I'd like to hear your thoughts on how the iPad doesn't lend itself well enough to Enterprise.

I have nothing specific in mind that disputes your assertion, but the linked article below says this, which sounds meaningful - "80% of Fortune 100 testing/deploying, 366 documented mass rollouts."

I'm also hearing that Microsoft views the iPad as a potentially disruptive force in the enterprise, though that is second hand.

http://www.zdnet.com/blog/sybase/ipad-2-will-continue-enterp...

We adopted continuous deployment at my last company, and it was a huge win for us. It resulted in less downtime, reduced the cognitive load on our developers, and let us turn changes and bug fixes faster, which just made everyone happier. Here is the approach we took --

We got continuous integration working first by setting up an automated test server. We used cerberus, which is a trivially simple ruby gem that simply polls a repo, grabs code, runs tests, and reports the result. You could install this anywhere, even an old Mac mini if you wanted. We spun up a low end server for it. We wrote great tests, got decent coverage, and made adjustments in our automated testing strategy to increase our confidence.

Then we worked on zero-downtime deployment and rollback. This was actually the hardest part for us. With regard to schema changes, if we had to hammer our database (new index on a big table) then we needed to take the site down, but otherwise our strategy was to always add to the scheme, wait for the dust to settle, and then remove things later. This worked for us, but we had a relatively simple schema.

I haven't quite figured out how an ajax-heavy site would pull this off. That seems like a hard problem since you need to detect the changes and refresh your javascript code.

We then combined these two to get automated deployment to a staging server. We could have written monitoring code at this point, but we decided to punt on that, relying on email notification for crashes and watching our performance dashboard.

And finally, we set it up to deploy to production, and it just worked, and we never looked back. It was the most productive and pleasant setup I've ever worked in.

Strongly agree (to both this and webwright). The package that felt strongest for us when hiring was to have amazing talent that other people want to work with, hand over significant responsibilities to new hires, and provide an environment that people are excited to come to work in. That doesn't mean that recruiting is easy, but it sure makes it easier once you have found the people you want.

The numbers you quote look in line with what I would expect, especially if you are getting close to a market rate salary. They are profitable and funded, which is a big milestone. It would help to know - Are they paying you a market salary? What is your past work history like? Does it include startups, and if so, in what role? How great is the rest of the team you are joining?

The Mark Suster link mentioned by brudgers is solid. My suggestion is to examine your motivations and goals, and then to be true to them. It will also help you evaluate your progress against those goals.

I'm going to presume this is your first startup, so these comments may be wildly off base if it isn't. The things I got out of my first startup were these:

(1) Money (we actually went public, though I had a very small piece of it). (2) Massive rapid skill development in circumstances where I could take on as much responsibility as I wanted and could learn from great people. (3) Connections to people that pretty much set me up for almost every job I had after that.

The value of (2) and (3) were huge. If I could give advice to my younger self it would be to focus on those two things first, then negotiate the best financial outcome that I could after maximizing those elements.