> When Pablo Picasso was an old man, he was sitting in a café in Spain, doodling on a used napkin. He was nonchalant about the whole thing, drawing whatever amused him in that moment—kind of the same way teenage boys draw penises on bathroom stalls—except this was Picasso, so his bathroom-stall penises were more like cubist/ impressionist awesomeness laced on top of faint coffee stains. Anyway, some woman sitting near him was looking on in awe.

> When Pablo Picasso was an old man, he was sitting in a café in Spain, doodling on a used napkin. He was nonchalant about the whole thing, drawing whatever amused him in that moment—kind of the same way teenage boys draw penises on bathroom stalls—except this was Picasso, so his bathroom-stall penises were more like cubist/ impressionist awesomeness laced on top of faint coffee stains. Anyway, some woman sitting near him was looking on in awe.

> The reason that Kubernetes is successful is because people look at it and they don’t understand why they need it until they see it do stuff. Then they say “Oh my God, I need that!”I can’t say how many talks and presentations I’ve done in front of skeptical audiences where they don’t understand what it’s for. Just by showing short and simple features like “let’s do a rolling update” I watch what happens.

> The reason that Kubernetes is successful is because people look at it and they don’t understand why they need it until they see it do stuff. Then they say “Oh my God, I need that!”I can’t say how many talks and presentations I’ve done in front of skeptical audiences where they don’t understand what it’s for. Just by showing short and simple features like “let’s do a rolling update” I watch what happens.

> The project/product distinction is an important one for many reasons, so let’s touch on that here for a moment so we don’t conflate or confuse the two, especially since one is more productive than the other. Projects are delivered as one big monolithic thing, meaning that coordinating all the activities within a big release is difficult and slow. Projects create big batches of work that are handed off to others at the end of the project to deliver and maintain.

> The project/product distinction is an important one for many reasons, so let’s touch on that here for a moment so we don’t conflate or confuse the two, especially since one is more productive than the other. Projects are delivered as one big monolithic thing, meaning that coordinating all the activities within a big release is difficult and slow. Projects create big batches of work that are handed off to others at the end of the project to deliver and maintain.

As a DevOpsDays sponsor you’re often given the chance to give a one minute pitch to the entire audience. Back stage at DevOps Rex, this week, I was talking with a first timer. One minute seems like such a small amount of time: how could you say anything consequential in 60 seconds? You’re presenting in front of the full audience, anywhere between 150 to 500 people. They probably also loath vendors, or, at least are bored by them.

Coffee is for coders. Whether you’re doing waterfall, DevOps, PRINCE, SAFe, PMBOK, ITIL, or whatever process and certification-scheme you like, chances are you’re not using your time wisely. I’d estimate that most of the immediate, short-term benefit organizations get from switching to cloud native is simply because they’re now actually, truly following a process which both focuses your efforts on creating customer value (useful software that helps customers out, making them keep paying or pay you more) and managing your time wisely.

“We have already slashed the time needed to implement new ideas by 70 percent while avoiding hundreds of millions of dollars in costs.” M. Wes Haga, Chief of Mission Applications and Infrastructure Programs for Air Force Research Lab Slowly but surely, the US government is improving how they do software. Working at Pivotal, I’m lucky to see some of this change and talk with the people who’ve actually done it.

Most companies don’t realize the amount of work required to fully transform their approach to creating and caring for software. Scaling up the improvements learned and put into place by your initial teams relies on building trust and understanding in the overall organization. For whatever reason, most people in large organizations are resistant to change and, what with the frequent introduction of process improvement programs, skeptical of the flavor of the week of the syndrome.