Product manage your kubernetes stack to make it more useful for your developers. Think of developers as the customers, rather than thinking of your SL* metrics as the customers. Otherwise, you just have a blinking cursor with awesome uptime.
Big sales deals require aligning all the different people at the buyer. With IT stuff, there’s always conflicting priorities and desires across different groups. When they don’t align, it drives 6+ months of delay to the sale. Worse, post-sale you’ll have trouble showing value (leading to renewal, buying again, expansion) as those teams battle it out when it comes to using your stuff.
If you’re doing anything with programming, apps, or the software you build and use to run your organization, check out the sessions we have at VMware Explore 2022, coming up August 29th to September 1st. (It’s the new name for VMworld, same conference, though.)
Overly ambitious aspirations often fail. Scale back your digital transformation dreams to starts small, learn, grow, repeat.
06 – Big Bang Releases
The sixth reason why changing, how you do software at large organizations usually fails: doing way too much at once, the big bang release.
Oftentimes, when you’re changing, how you do software at a large organization, you wanna have a big successful release. You’ve got a lot to change hundreds, if not thousands of teams, and you’re investing a lot of time and money and attention from a corporate perspective. So what you really wanna do is build up a case that it’s gonna have a huge impact and it’s worth going through all of this risk and change.
So you build a business case that includes transforming nearly everything within at least a couple of years. The problem here is that until you start changing things, you’re not gonna learn what works and doesn’t work in your organization.
It’s not gonna all go according to the books and the fancy conference talks you’ve seen. You’re gonna have to find the people, the processes, the software, what your customers think. Many things are gonna be unique to your organization, the processes, the cultures that are set up.
You need to start small and ramp up as you learn more to more. and That’s gonna be the way that you actually control risk and costs.
Beware of Luxury, Jan Steen. Kunsthistorisches Museum, Vienna.
14 reasons why your digital transformation strategy probably will go poorly: the fifth reason.
You probably don’t have true continuous integration and continuous deployment in place. What this means is that you’re not only automating the way that you build your software, that you test your software, that you even make the images or the package of the software to be deployed continuous integration.
But that you also don’t have a way of automating getting that software to production, setting up all the configuration needed the infrastructure, the storage, the compute, the networking, all the other middleware. That’s gonna be used setting up all the infrastructure that’s needed to run that software in production and also having the configuration that goes with it.
And even the monitoring and the instrumentation that you’re gonna need. You’ve gotta think about the entire process that it takes from idea to that code running in production and find all the things that are going in the handoffs between there, you’ve got a bunch of boxes and arrows. And what I find is that people optimize those boxes, but they don’t really think about the arrows, the handoffs and how long it takes to get between them.
So the first thing that you should do is look through that flow of things and find out where the wait times are. What’s taking a long time. Good luck!.
The 14 reason out of 14 that getting better at software and large organizations often doesn’t work out. And that is that you can’t actually change the organization. Whenever you’re getting better at software. You’re often moving from a project based way of doing things where people are assigned features and wire frames, and they just do that and deliver it.
And it’s someone else’s responsibility to make sure it’s successful, evolve it and even run it. However, in a more product way of doing software, the way that really good companies do it. That team that builds the software is responsible for it over the lifetime of the software. They actually write the software and observe if it’s solving problems that people have.
If it’s actually meeting the objectives, the business goals, uh, that people have, what this means is that you’re gonna need to change the organization around to reflect that responsibility that they have. Those teams have to be unified across the life of the software, interact with the business side.
Even interact with customers more and observe them and see what they’re doing, which is not usually the organization structure that you find in most it departments and large organizations. So make sure you can change that organization structure around and start planning on how you’re gonna be doing that.
If you’re improving the way you’re doing software in a large organization.
Tanzu Talk is back! Your new hosts are Coté, Ed, and Ben. In this episode we cover recent news in the cloud native world, plus highlights from the recent Tanzu Application Release. Plus, light discussion of the political climate in Star Trek versus Star Wars as it represents programming philosophy.
So far, the format is to cover some cloud native news and then talk about a larger topic. We have some guests upcoming as well. It should be in your ears every week or so. Subscribe!
Platform Engineering, platform as a product, and so forth. If you’re standing up kubernetes or any cloud stuff for developers, you probably need to change how you think about operations in general. Shift from service delivery to product management.
14 reasons why your digital transformation initiatives to get better at software may be slowing down. Number four.
Often what you do when you’re fixing up how you do software in a large organization you’re putting a platform in place. Whatever your cloud infrastructure layer, along with whatever frameworks you use for developers and tools on top of it is to get them to be more productive.
Often time an infrastructure team is asked to build this and they build it without spending enough time with the actual customers of that platform, the developers. They’ll build this platform and then they show it to the developers, and developers are not interested in using it. Kind of little wonder because they weren’t consulted.
So there’s two things you can do to avoid that.
One is to involve developers very early on one or two teams to help decide what’s in the product and explore it, validate it, change it as you product manage what you’re building for them.
Two, you’re gonna need to do at least quarterly road shows internal conferences, where you can go visit teams of developers and have your platform advocates not only training them, but convincing them that it’s a good idea to use.
14 reasons why your digital transformation is stalling in a large organization: number three.
If you’re looking to improve the way that you do your custom software in a large organization, you likely have a huge amount of what people call tech debt or legacy software.
These are the systems you’re currently using that have brought you all the success and revenue that you have, and now they’re too old and they really can’t be changed. And if you actually try to go in and use them. There may not even be the skills of people who know what they’re doing. As you wanna start using those pieces of software, those services in different ways, it takes longer and longer to the point where people say it can’t be changed unless you’re willing to put up with six or 12 months.
Now there’s all sorts of reasons this happens, but mostly it has to do with neglect. Just letting things go too far and not maintaining them, not upgrading them and thinking about how you build long term architectural agility into them. So make sure when you’re looking to improve how you do software, you’re really paying attention to and planning for how you’re gonna modernize your software. Identify the legacy software that’s holding us back and modernize it as needed.
14 reasons digital ,transformation fails in large organizations: number two security.
There’s many things your security staff is gonna wanna do when it comes to making sure the software you build and run is secure.
One, they’re gonna need to build up a risk profile to understand the new technology you’re using the deployment frequency, all the types of risks that can occur. These risk profiles give them way to model and think about the security risks they’re willing to take on, those they’re not willing to take on, remediations to do. It’s kind of the core model for how security thinks about things.
The next thing they’re gonna need similar to compliance is to make sure the software using follows the policies and the guidelines that you have. They’ll also use this to patch software as bugs come along the third party software that you use. In order to patch that software, they’re gonna need to know what you’re using and where it’s deployed, how it’s configured and so forth and so on.
So these are things that security groups are gonna need to know. And if you don’t anticipate and plan for that and talk with them about it, it’s gonna slow you down.
14 reasons why it’s hard to change the way you do software in large organizations, number one.
Compliance basically means that you’re following legal and self-imposed policy and guidelines: the ways that you’re doing things and not doing things. Governance.
A compliance person can’t come in and check every single hour of something that’s happening. So your software developers and product managers and operations people have to document that they’ve followed the rules. And they need to also provide that documentation to the auditors who can then go in and audit it, look over it and make sure that it’s following the right way to do things.
The compliance people often work a lot slower than you want if you’re doing a weekly or even daily release with your software. That becomes a huge hurdle.
You need to spend a lot of time thinking about your build pipeline, the platform that you’re relying on, the process that you use to make your software, and even most importantly, going to your compliance people and spending a lot of time to show them the new ways that they can make compliance even better when you automate and change the way you do your software.
The charitable guidance on what “shift left” means is: operations and security people working closer with developers, being friendly with them, and vice-versa.
More or less it’s that lean idea of “move the decisions closer to where the work is actually done.” The phrase has gotten blown up to mean more than the original DevOps think (have developers put in work to make their apps run better in production, and have ops people work with developers to do so) to mean any activity that’s working closer with “developers” rather than in some waterfall-like, impersonal process before or after developers.