[jon-wood]

I have a slightly different interpretation of this, and it comes down to the horrible manager-ese phrase "risk appetite".

As a small scrappy startup shipping is the absolute priority - get something out in front of customers, because the existential risk to the company is that you run out of money before you've got either a sustainable income or investment. Security might get some lip service paid, but ultimately who cares if your code is insecure when there's no customers who's data is at risk yet.

Over time the company will (hopefully) grow its customer base. Maybe you get some big B2B contract to fulfil. That's the point at which things like security audits land, and people start having to really care about security, because now there's half a million people in your databases, and if they get compromised you're going to be front page news.

You need different kinds of people as a company grows. The scrappy "get it shipped" engineers of the early days are going to find it increasingly difficult to function in a larger process focused organisation because its no longer just a case of sitting down over lunch to hash out a new feature before hacking something together in the afternoon. Process means that's now a multi-week process involving three different departments, followed by a month of waiting until the necessary people are available to actually build it.

I don't really have any good answers to that. I suspect small skunkworks like teams are probably a good first step to being able to retain those early engineers into the later stages of a company, but I've never had the chance to try it.

[wccrawford]

I don't disagree about the company's needs changing, but they'd already recognized that need when they hired me. But they didn't actually recognize how well I was fulfilling those needs until the audit.