I've found maximizing company value to be a pretty good end goal as an individual contributor (and it's definitely the thing I'm most excited about doing when I walk in the door in the morning). It's how you tell whether "fix this bug" or "implement this feature" is higher priority, or whether "do this thing now in our current system" or "experiment with this completely different system" is higher priority. You can do all of those at speed; the question is which to do. And getting it wrong dooms your company, because you're wasting effort.

In a well-functioning company, I don't need to make that decision myself, of course: I have management who has evaluated the cost of having the bug and the benefit of having the feature, or who's experienced and smart enough to determine whether doing the short-term thing now or investing in the longer-term thing will be likely to have better payoff. Because this process is there, if I trust my management, I don't have to spend-time second-guessing them (or worse, doing the research myself), and then I get to move quickly. But again, moving quickly isn't the point. It's a tool on the way to delivering value.

> Fast+incompetent = cowboy attitude, sure, but the problem there isn't the fast bit.

Exactly right. Frequently, in industry, I see people confuse the "slow" and "competent" bits. They think that just because a given change needs to get a bunch of sign-offs that the overall effect of the system requiring the sign-offs is a net benefit to the organization.

It's not. It's paralysis, and you won't notice how ungainly and slow you've become until a different org a tenth of your size manages to clone your entire feature set in a hundredth of the time it took you to develop it, all because your developers have to deal with bullshit all day long and your competitor's can just act.

A lot of people will claim that you need gatekeeping and approvals and such to maintain a rigorous standard of quality. You have to be brave enough to disregard their advice. You have to be able to take the gut-wrenching step of saying, "No. We're not doing that. I don't care if this change caused a SEV, we're not adding process. Moving fast is important!".

It's very easy to believe the nostrum of "no pain, no gain". But sometimes you have to realize that pain is just pain.

I've seen urgency used as an excuse for sloppy work so often that I can't ever imagine the speed of development being a good metric.