Beyond the accidental platform

Recording of a recent talk: No matter what, you end up with a platform - the collection of tools, practices, and services you use end-to-end to develop, deploy, and run your application. Many people aren't conscious of this fact and end up with an 'accidental platform. All I'd like to accomplish with this talk is convince you that you should definitely be conscious of the platform you're building and make sure it's not just an accidental one.

The Software Nihilist - Software Defined Talk #41

The Software Nihilist - Software Defined Talk #41

After finally settling an important RescueBots debate, we discuss keeping optimistic in the tech industry. And there's much to be (potentially) cynical about: bad work conditions at Amazon and the tech industry as whole, inscrutable restructuring at Google, and rumored fire-sales in the APM space. With a trust, detailed taxonomy of nihilism, somehow, we manage to keep it together nonetheless.

Setting goals is important for DevOps success

For my monthly column over at FierceDevOps I wrote about the importance of setting goals. I was motivated to write this by this point being repeated in Leading the Transformation many times, e.g.:

Management needs to establish strategic objectives that make sense and that can be used to drive plans and track progress at the enterprise level. These should include key deliverables for the business and process changes for improving the effectiveness of the organization.

It made me think that most of the corporate failures I've seen over the years were due to management being vague about what they wanted and what the team should be doing. Someone has to set the goals and, at the very least, it's management's job to make sure its done (they don't have to do it, though I tend to think they do: they just need to make sure it happens).

Anyhow, check out the piece!

Coté Memo #077: Avoid going from "VP of Having a P&L" to "VP of Special Projects"

DevDaysDays Chicago

I'll be at DevOpsDays Chicago in a few weeks, August 26th to 27th. If you want to go and haven't registered yet, you can use the code PIVOTAL10 to get 10% off, which gets it down to like $170 or something. It's excellent value for a tech conference, plus you can see me speak and staff a booth! While I'm up there, on Aug 26th, I'll be speaking at the local Cloud Foundry Meetup.

Tech & Work World

Stacking the Deck

I'm working on the second part in my "cloud native journey series" (part one was an overview and brief summary). Here's an excerpt from my draft on greenfield journeys, on selecting the right initial projects:

Selecting your first projects

If you're a small team, or a small company, selecting the project to work on is likely easy: you probably just have one application, so select that! In larger companies, there are often 100's, of not 1,000's of application and projects you could pick from. You want to pick one that will have customer value (that is, be customer facing) and will give you feedback once you deploy it (people will use it a lot, it won't just be shelf-ware). You also want to pick a small enough project that getting it into production is possible in a short amount of time, let's say 3 months at the maximum. Finally, if things go poorly, you want it to be a somewhat low profile project so you can sweep it under the rug if things really go poorly so you can live to greenfield another day.

This last point is no doubt contentious to the purer minded of y'all out there, and I can sympathize. We should strive for truth and transparency! I'm sure you're lucky enough to be in a corporate structure that rewards the value of failing (learning), but think about your peers who are not so lucky and work in caustic corporate culture that punishes any type of failure by "promoting" the former "VP of Having a P&L" to "VP of Special Projects." In such cases, you're given the chance to advance to the next place on the board by success, so you'll want to pick a project accordingly. Of course, the point is that as you build up the success record of failing fast, as it were, you'll be able to change said caustic corporate culture around...hopefully. While a bit dated, the 2010 booklet, The Concise Executive Guide to Agile has a detailed discussion and methodology that's helpful for picking your initial projects.

There's a different type of project you can choose as well, what I like to think of as a "moribund" project. It fits all the criteria above, but already exists and just needs to be shown some love. One of our customers, Humana, profiled this strategy. Their Vitality project wasn't getting the engagement levels they wanted: just 3% of potential users. They wanted to triple engagement, getting it to 10%. As they detailed in their keynote at this year's CF Summit, after reving that project with a more agile and cloud native approach, they were astonished by the increase in engagement to over 30% of potential users. They then parlayed this success into two other, small but important projects and are not on the path to transform how applications are done company wide, beyond the greenfield.

At ~3,500 words, I need to cut down the full piece a bit. We'll see what comes out the other end of the chute!

Shameless Self-promotion

Some recent items from me/us:

More from "cloud native" land

I'm not sure if you've noticed, but the infrastructure niche of the tech world has gone crazy for "cloud native." Consequently, I follow it a lot and type that phrase a lot. Here's some recent items I've found:

Quick Hits

Fun & IRL

7 Minute Workout

I've been trying to the old 7 minute workout via an app (there's a NYTimes one up too). Not having exercised for, let's see...none of my life, it sure is hard and just the right amount of time and pain that I keep doing it.

We'll see what happens.

Sponsors

Meta-data