[banned1]

"Emphasize that the most important part of software development is moving fast."

No, that is not the case most times. The most important part of software development is, as with any other part of the company, to maximize the value of the company. That may be speed, but if you have 1m users the most important thing may be to preserve trust, to acquire new customers, to automate existing infrastructure, etc. etc. Speed of software development is not a goal in many environments. Thoughtful execution may be hindered by a cowboy attitude in development. I'm not saying that speed in development is not sometimes the goal (maybe in startups within an enterprise trying to test an idea), but often it's not the most important thing.

[inopinatus]

"Maximising company value" isn't a useful end goal you can give to anyone but the CxO team. For everyone else, it's a motherhood statement. Trotting it out as though it's some kind of engineering compass isn't helpful.

To this you've appended the hackneyed conflation between "speed" and "cowboy attitude". It's a common category error, but in truth, rapid iteration is one of the enablers of high quality and is a huge effectiveness multiplier for top shelf dev teams. Slow development merely enables lazy programmers (since it conceals their apathy) and gives us waterfall disasters. "Thoughtful execution" is possible in any context, and most thought processes are greatly enhanced by evidential techniques such as rapid prototyping / feature spiking.

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

[geofft]

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.

[quotemstr]

> 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.

[sillysaurus3]

You have to be able to take the very demanding 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!".

The moment that some minor disaster hits, which it inevitably will, whoever is in charge will find themselves no longer in charge.

I think this is one of the fatal flaws of a big company. Everyone is terrified of risk. I'm not sure it's possible to counteract this tendency unless the company was built from the ground up not to punish risky behavior (e.g. Facebook, supposedly).

[quotemstr]

Right. You have to create a culture where it's okay to fail. And it's not enough to just say that: you have to actually practice it. You have to let people make mistakes, then do nothing so that other people don't feel afraid to take risks. Hell, reward people for failing. Highlight them as exemplars of people who do things. If you don't fail once in a while, you're not moving fast enough.

[logicfiction]

Rewarding failure can have pitfalls (if we mean something like customer impacting fallout). You may then be encouraging people that create broken things over people that more quietly create well-functioning things the first time around.

Enabling people willing to act is important though and I fully support the do nothing aspect of failure, or better yet support and stabilize but not reward.

[mhink]

> Enabling people willing to act is important though

I think that's the key thing here. Rather than saying "whether you succeed or fail, you're still gonna get your $250 bonus", you're saying "if you try and succeed, you get $500- if you try and fail, you get $100, if you don't try at all, you get nothing."

[sillysaurus3]

Yeah, but this is at odds with virtually every big company. No one has the power to affect that kind of change except the CEO, and the CEO is rarely interested or involved enough to do that. Is there any way around this problem?

[sokoloff]

If your CTO or VP of engineering or VP of ops can't make this change, your company likely has other problems.

I admit to inheriting a fairly smart-risk-accepting technical culture, but also worked to extend and cement that by holding regular blame-free post-mortems on production problems and reporting them weekly to our business operations meeting. Making failure and the analysis/correction thereof a regular part of company operations makes it normal, accepted, and less scary. We would also pretty regularly respond to asteroid-type production problems with "no preventative action intended; cost of prevention exceeds expected losses". (We held a view that there is [conceptual process] green tape and red tape; make sure if you're fixing problems with process that it's actually green tape and if fixing a problem required adding red tape to the system, we were very skeptical and tended to avoid adding that process/step/gate/check.)

Couple that mindset and transparency with a metrics-supported track record of making things better overall and management will support. I'm not sure our CEO ever saw any of that sausage-making, except for the very largest or most damaging problems and even then, it was mostly a courtesy message to him. He cared about the overall pace and metrics, not how many outages or bugs we had along the way.

[tonyedgecombe]

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.

[inopinatus]

I don't conflate the two. Urgency and speed are two very different metrics. Many lumbering waterfall projects have moments of urgency or even panic.