If you were trying to get a gist of the overall maturity level of an IT Ops and Infrastructure organization by asking only one question, I think you’d be hard pressed to beat the question, “How mature is your DevOps?” I’d prefer that to “How do you use the cloud?” or “How fast can you provision a server?”. The reason is that DevOps is the only industry buzz word that has a built-in “why”. We get better at DevOps for a specific reason… to lower the friction for agile development teams. There’s lots of reasons to go to cloud and a lot of reasons to automate things… some of them are good and some of them are bad, but if you’re always seeking to make dev teams more agile, you’re likely on the right track.
That’s why I’m always so enthusiastic to read the “State of DevOps” each year (a report commissioned by Puppet). It helps you see where high-performing DevOps organizations (ones that can deploy to production regularly) are differentiating themselves from lower performers. This can help prioritize your strategic goals and initiatives.
This year I had three key takeaways from the report:
Automation and cloud are key to DevOps, but definitely not the only keys. 62% of companies stuck in “mid-evolution” on their DevOps Journey say that they have high levels of automation. 65% of those “mid-evolution” companies are on public cloud, but only 20% using it effectively.
The DevOps Journey is something we’ll be focusing on for a while. From 2018 to 2021 only 8% of companies graduated to high performing DevOps teams (going from 10% to 18% of all companies).
Platform Teams are becoming key. This is something that I’ve been working with my customers at Kyndryl on for the last couple years. Platform teams are highly correlated not only with high performance on the devops scale, but also with employees feeling like they know their role.
Check out the report here and let me know if you think I missed something.
I can usually tell by 15 pages in to a self-help book whether it’s going to resonate with me; usually, it’s not going to. I can’t stand being told about how much I can get done in the morning if I start at 3am or that if I work 10x harder than everyone else it will pay off. These are obvious, hard work usually pays off (although if you think it automatically does, you should read Peak by Anders Ericson).
Dweck’s book is entirely different. It suggests that if you want to find fulfilling success, you should look at the world a little differently. You should stop asking yourself if you are successful and start asking what you can do to grow. I have to admit that 15 pages in to this book, I thought the idea was too simple to be useful. The more I read though, the more I liked the way it challenged me to think about life.
I’ve always been one to enjoy my successes with a little pat on the back (or more likely a celebration scotch). What I considered a success though was often what the rest of the world would view that way. For example, if my team at work won a new big project I would celebrate. If we had a month where we didn’t get a new project, I’d feel bad. It always felt a little cheap celebrating when the project win was just lucky and it was always tough to feel too bad when we made a great pitch to a customer that I knew would help them in the long-run, but that got scuttled when a key stakeholder retired. This book gave me a better way to look at these projects than pure outcome based success or failure.
Dweck would have us focus on “growing”. In the above example, the team clearly grew in our capability to identify and sell key projects by making that presentation (maybe we also learned how to identify clients we shouldn’t bother with). Dweck points out that it’s not that luck doesn’t exist; it’s just that you don’t want to let let your luckiest moments be the way you define yourself. This construct has given me a more consistent way to approach my days. Even on a bad luck day I start thinking about what I can learn from the situation and the best possible way I can move from here. If I’ve done my best and learned, I feel content and even more ready to take on the next day.
Jeff Bezos built a company that’s worth about the same on the stock market ($1.67T) as the entire circulating supply of Pakistani Ruppees ($1.68T). That means you could BARELY trade every Pakistani Rupee in existence for all the stock in Amazon. I guess I’ll read some of his wisdom and see what he has to say.
I found the book pretty interesting. It’s not exactly a page turner and there are parts that are a little repetitive (the guy has clearly practiced telling his life story), but you can leaf through those parts quickly and be back in good material.
It starts with a republishing of all of his shareholder letters as CEO of Amazon (the last one you’ll have to find on the internet until they publish a new edition). They’re a fantastic read. It’s almost a retelling of the whole internet. From an optimistic Bezos reporting that Amazon had “established long-term relationships with many strategic partners, including America Online, Yahoo!, Excite, Netscape, GeoCities, AltaVista, @Home, and Prodigy.” in 1997. To a one word title of “Ouch” in 2001 after he saw some 90% of the value of Amazon wiped out. To explanations of how Amazon refuses to take a short-term perspective, even in a world where quarterly earnings are analyzed so heavily. To discussions of how, being a big company allows it to make big bets like the Fire Phone (dud) and AWS (clear winner) that it might not always win. To the mentality of “customer first” that Bezos uses to push employees because customer loyalty only lasts until your competition shows your customer something they never knew they wanted.
The remainder is a collection of Bezos’ speeches. This got repetitive with stories of how he admired his grandfather for being resourceful on a remote farm and sticking up for his mom when she was a pregnant high school. You should feel free to skip around, but don’t miss the speech on Blue Origin (his space company). The company is endeavoring to build the “infrastructure” for future generations to reinvent industries in space. He talks about the need to have big Lunar landers to send enough equipment to the moon so that the natural resources on the moon can start to be used for construction of more items in space (this makes sense since it’s much more efficient than trying to launch HEAVY things out of earth’s gravitational pull). It’s a fascinating way to choose to spend a personal fortune that is roughly 2,000,000 times larger than the average American’s.
Because of where I am professionally (with Kyndryl about to break off of IBM and provide me the opportunity to really grow the size, number of services, and the value we can provide the customers of my Cloud Advisory Service practice), I found the 2016 shareholder letter the most impactful. He talks about techniques for always staying in Day 1 because “Day 2 is stasis. Followed by irrelevance. Followed by excruciating, painful decline. Followed by death. And that is why it’s always day 1.” Resisting the urge to just get what you can from customers and instead keep innovating for customers, is the energy we’re going to need at Kyndryl.
I rarely bother to post books I read for pleasure on the blog, but I thought that a lot of the people that I know professionally may be interested in this one. I started reading it in November when we were just starting to be able to think about what a post-Trump America might look like. After four years of hating the news so much I rarely watched it, I was trying to remember what it felt like when I had agreed to let an Obama staffer live in my extra bedroom when the 2008 campaign was tight in Pennsylvania. This book did not restore that optimism.
The book is simultaneously interesting and boring because President Obama really dives in to telling about what his goals were, what challenges he met, and how he and the team dealt with them. The book would be more inspirational, and more of a page turner, if he left out those details. It would also feel like a commercial for his presidency instead of a memoir. If you’re in the mood to hear the details of the political process and how Obama and team tried to manipulate it, you’ll enjoy this book. If you’re looking for a compelling narrative that’s fun to read, there’s an abridged version.
One last recommendation. Definitely get the audiobook, he reads it himself and I think being able to hear his emotions and emphasis while he reads is worth the slower pace.
I found a lot of great nuggets in this book, but I’m not sure I’d recommend it to everyone. If you’re trying to sell your boss on a move to AWS, definitely give her this book. If you’re trying to figure out what your IT priorities are, I’d recommend Leading the Transformation or The Pheonix Project. If you insist on reading something that’s written by an AWS Employee, I’d even try War, Peace, and IT by Mark Schwartz.
While I found some nuggets that I enjoyed and found informative, I found most chapters just identifying a problem and then explaining how being in the cloud mitigates that problem. It’s not really surprising considering it’s 53 chapters in only 298 pages (at least how Kindle counts it). One big exception to this is Chapter 5 and Chapter 53 outline processes and are a little more detailed (but each of them could be an entire book). The other little nuggets that I liked were:
Chapter 23’s discussion of the future of Managed Services in the cloud was interesting. I believe the combining of migrating to cloud and managing applications (essentially turning them in to SaaS) was a great point. Also, the highlighting of DevOps as an important feature of an MSP.
I liked Chapter 33’s discussion of Hybrid Cloud. Too often AWS and their surrogates talk about Hybrid Cloud as a fantasy. Unless you have the kind of capacity that it’s worth building an entire datacenter that runs just for you (like Netflix), you’re probably better off having everything in the cloud. The problem is, you can’t just put it there by magic. Orban does a nice job recognizing Hybrid Cloud as a stage, maybe a VERY VERY long one, but not a destination.
I liked the discussion in Chapter 46 about a company’s vision for moving from Centralized IT to Exponentially Growing IT.
2020 was a year where I expected to just entrench and work on establishing myself at IBM. It was a really good year for that, and (thanks to a lack of travel and a bit of a COVID slow period) also allowed me to set some pretty ambitious fitness goals. That leaves me feeling pretty good about what I was able to accomplish, making it possible for 2021 to be more about refining and doubling those successes.
Specifically, I have set three goals:
I want to really focus on working with CIOs/CTOs to make their “Infrastructure and Operations” teams in to a value add part of IT. As I spend more time with more companies I see them consistently able to articulate how a better customer experience or using AI can bring value to their bottom line, but then they are unable to understand why they can’t securely and efficiently create the platforms necessary for those innovations to occur on top of. I am intending to spend 2021 moving beyond the containerization, cloud, and automation discussions I’m leading customers on now and pull that together in to a more strategic view of the organization. You’ll see this in more frequent observations on Twitter, some blog posts, and (if you’re lucky enough to be a client) in a new model we’ve been working on for how to change your culture and tooling.
I am planning to be much better about keeping up with my professional contacts. I realized yesterday that I haven’t done an inventory of my contacts since very early 2020. My plan will be to do better at connecting with people I’ve worked with on LinkedIn and reaching out to folks I worked with a few years ago to see how they’re doing.
I managed to finish 2020 in reasonable shape. I have not traditionally been good at staying in good shape once I reach it. I tend to yo-yo back and forth between in shape and out of it. My goal this year is to stay around my current level of fitness for the whole year.
If you’ve read much of Gene Kim’s work you’ve heard of the transformation that HP Printers made to their firmware development process. Kim cites it so frequently because it is an example of one of the oldest software development groups around making software that’s some of the hardest software to test (printer emulators anyone?) transforming from a waterfall development process to an agile one. Gruver and Mouser are the executives behind that transformation and this book is full of great lessons that everyone who’s had an IT department for longer than Amazon’s been a bookstore can learn from.
Let me give you three of my favorite things about this book, and I encourage you to read it and come up with your own:
In the very first chapter they talk about how many companies make the mistake of trying to start an enterprise agile transformation by just having one team transform. It doesn’t work because, at least in most companies, a meaningful development team can’t go to production on its own. You have that one transformed team running scrums and using whiteboards full of sticky notes to deliver code to an integration test environment where it will sit for 6 months. The key is to find ways to iteratively improve the whole organization (or at least ALL the parts that have to develop together) towards agile.
Having worked in technology all my life, I had never really considered why software development should be managed so much differently then your other cost centers. I really liked their point that what makes software development so hard to plan for is that it’s hard to see and often changes from looking 80% done to looking destined for the trash heap overnight. That ever-changing aspect is also what’s great about software. It’s hard to predict where you’ll be in 6 months in a software dev project, but it’s much much easier to change your mind today about where you want to be tomorrow. Doing agile software development makes so much sense because it’s just using the inherent strengths of software rather than trying to mold it in to a waterfall techniques.
Finally, this book isn’t afraid to make the tough point that executive teams must understand technical concepts like continuous delivery to be successful. They can’t just be great people managers or inspirational leaders. They have to know when to make exceptions to the “no branches” rule and when to require automated tests. These are things that reasonable development managers can disagree on, but a knowledgeable executive must set a standard for.
I confess, Value Stream Mapping as a technique is something I already do with clients and I was reading this book mostly to make sure that I could say that I did (and now it’s on the Internet!). I will say that after being taught value stream mapping primarily as it relates to the DevOps movement and CI/CD pipelines, I was surprised to see how general the approach is. It seems like it would be really valuable for enterprises to do in areas outside of manufacturing (it’s based on Lean and started as one of the Toyota techniques) and IT. Maybe someday I’ll focus more on my MBA and less on my Comp Sci background and actually use it that way.
In this book “review”, I thought I’d spend some time in this blog post talking about the nuggets throughout the book that are a bit different when our team looks at creating a value stream to find opportunities for IT Automation. Feel free to leverage this in your business, or give us a call and we can help you get started!
First of all, we are usually doing a couple Value Stream Maps in our spare time in the first week of an Ansible Tower Foundation engagement. While also installing Ansible, connecting it to our client’s Git, Active Directory, Credential Management, etc… Consequently they are usually a lot less involved. This different results in a few big changes:
The scope has to be different. The book talks about focusing on customer value streams being from “ring to ring” (from the phone call to order to the ring of the cash register). We still like to focus on this, but we often take IT Operations customers ring (a ServiceNow request to get a new VM) to service fulfillment (a notification to the user that they can log in).
The session itself is shorter. I like to try to keep it to either one hour or two depending on the complexity. This allows for nice crisp time keeping. 10 minutes to intro the concept, 20 minutes for current state, 10 minutes to brainstorm opportunities for improvement, 20 minutes for future state.
I think the charter becomes MORE important when you want to do a short session. It is important to have your sponsor identify the limitations of the exercise and the precise scope. This will limit wasteful conversation during the workshop.
Since our focus is typically on finding out how best to improve an IT Operations value stream via automation, we are looking for slightly different things in the value stream map:
We do not limit ourselves in looking only for automation opportunities. We are looking for all manner of improvements… avoiding batching, identifying opportunities to run in parallel, etc… It’s not our goal to fix those as part of the project (though IBM has some excellent process consultants). It’s merely our goal to avoid the investment of automating a process that shouldn’t exist at all or is not a bottleneck.
The Gemba walk is usually not a physical one. I like to have actual operators walk an actual ticket on screen where possible. In longer running processes it may be constructive to view several tickets in different phases.
We use all of the resulting automation “kaizens” to start our clients’ automation backlog. Because of the value stream mapping we can be clear about just how much value can be expected out of each automation.
Overall, I definitely recommend reading the book. Even if you’re only planning to use the technique for CI/CD or IT Operations value streams. It will give you a lot of perspective on the history of the technique and its uses in the wider enterprise, in addition to arming you with the vocabulary you need to leverage it for your use case.
I actually finished the Unicorn Project a couple weeks ago and didn’t take great notes on it, so this won’t be as extensive of a review as I often provide. I did enjoy the book, and like it’s predecessor (the Pheonix Project) it does a great job of showing how some of the best processes in the industry can come to life in a specific company. It does a beautiful job covering both the DevOps revolution at the team level with containerized dev environments, versioned APIs, and everything else required to decouple deploys, automate test, and implement CI/CD. It also touches on the transformations necessary to abstract your mainframe/legacy environment and the evolution of management thinking around experimenting with parts of your org while gaining efficiencies in others.
My only real critique is that it’s not very realistic. It demonstrates how powerful these concepts CAN be by taking an ideal company. The ficticious company in the book has a CIO who understands the need to empower engineers and keep the vision high-level (rather than command and control), a great agile coach, an operations team that wants to put in the extra work required to give control to the developers, and a development team that is excited about experimentation… not something I often see in clients. It also glosses over things that I’ve seen very difficult. At one point it takes a development team over three weeks of hard work to put together an automated test suite for their application that includes (presumably) either mocks or test instances of upstream and downstream systems. They’re right to call this hard work, but I’ve rarely seen developers tackle it in a few weeks, even on a backend system without a UI.
The best use of this book is to give it to a CIO or CTO who struggles with what success looks like in their organization. If you still have someone who’s trying to count server consolidation ratios or incident tickets, give them this book.
If you’re going to be working in technology for more than 10 years, you should read this book. It’s written by a set of economists associated with the Creative Destruction Lab at the University of Toronto. As you might imagine from an incubator with that name, they have made many investments in Machine Learning companies. The observations in the book are less about how machine learning works (though there is obviously some introduction required) and more about the implications for the wider economy.
As the title suggests, they believe that the current advancements in artificial “intelligence” are not related to general intelligence, but are making advancements in computers’ ability to distill lots of data about what humans have done to make a prediction. For example, Google’s image recognition doesn’t actually “recognize” images, it is only able to say, “based on other sets of pixels that people have identified as tables, I think that there is a 98% chance that is a photo of a table.” This key assumption then allows them to predict how further advancements in these prediction machines will impact the kinds of companies, jobs, social programs, etc… that will go up (or down) in economic value.
As they put it, “Economics offers clear insights regarding the business implications of cheaper prediction. Prediction machines will be used for traditional prediction tasks (inventory and demand forecasting) and new problems (like navigation and translation). The drop in the cost of prediction will impact the value of other things, increasing the value of complements (data, judgement, and action) and diminishing the value of substitutes (human prediction).”
The remainder of the book explores logical deductions from that fact. Some of the more interesting of which are:
Some areas of prediction only become real game changers when the machines reach near 100% certainty. For example, imagine if when Amazon made a recommendation they could be 98% sure that you’d want to buy the product… would they send automatically send the product to a distribution center near your house? Maybe just send it straight to you and let you return one product in fifty that they’re actually wrong about.
The value of data is going up quickly.
Machines and humans have distinct strengths… humans tend not to be thorough while machines can’t discover independently a new type of data that should be incorporated. The two will be paired with machines doing the prediction and humans doing the judgement.
They identify 6 types of risks associated with Prediction Machines. The most interesting of which is that on things like driving an airplane, humans are getting less and less skilled at it while auto-pilot does more.