Does digital transformation necessitate organizational transformation?

Recently, Docker has become more accepted with the mainstream technology audience. That audience transformation shifts the kinds of things you build and the kinds of problems that need to be solved. Docker is no longer only for bleeding edge early adopters who don't want to pay for anything and who have 7,000 microservices. It's now going into places that are earlier in their technology modernization journey and that need a lot more guidance and handholding. Docker is a small startup company. It doesn't have the resources to do those kinds of hand holding. And so that creates some very interesting overlaps where people are trying to learn complicated technologies. Technology has only gotten more fragmented and more complex as we've gotten things like microservices and polyglot programming over the past couple of decades. People are trying to get up to speed, and they're trying to figure out how to do it right. It remains a significant challenge for people to onboard and understand what a modern technology stack and a modern application means.  In the large enterprise context, I think a lot of it comes down to, are you willing (as a company and as a culture) to empower your people to the level necessary to really take advantage of these modern approaches? Why do you want microservices in the first place? So you can innovate independently and empower the team that owns them to do the right thing and to work with their customers and to have their own product manager and be embedded within the team, engaging with customers, building what they need, iterating quickly. If you're working within a larger corporate context (may have siloed development and operations groups in different geographical locations, or a legacy of executives leading rather than teams leading) you have an organizational structure and culture that it's going to hold you back from the benefits. It is the same as lifting and shifting an application from an on-prem data center into public cloud without doing anything to it. You're taking something that was built for infrastructure and highly available at the single node level, and you're moving it into something where you have to build for high availability at the software layer instead. If you just move it into a new environment, you're probably paying more for less because you're not taking advantage of all the capabilities necessary to improve. With the org structure and the processes you've got to put in the work to tell the right story that helps them move forward instead of telling a story that puts you at odds and makes it extremely difficult to make that kind of progress. How do you take everybody, wherever they are, and help them all shift forward and move their applications forward?

18 views
4 comments
1 upvotes
Related Tags
Anonymous Author
Recently, Docker has become more accepted with the mainstream technology audience. That audience transformation shifts the kinds of things you build and the kinds of problems that need to be solved. Docker is no longer only for bleeding edge early adopters who don't want to pay for anything and who have 7,000 microservices. It's now going into places that are earlier in their technology modernization journey and that need a lot more guidance and handholding. Docker is a small startup company. It doesn't have the resources to do those kinds of hand holding. And so that creates some very interesting overlaps where people are trying to learn complicated technologies. Technology has only gotten more fragmented and more complex as we've gotten things like microservices and polyglot programming over the past couple of decades. People are trying to get up to speed, and they're trying to figure out how to do it right. It remains a significant challenge for people to onboard and understand what a modern technology stack and a modern application means.  In the large enterprise context, I think a lot of it comes down to, are you willing (as a company and as a culture) to empower your people to the level necessary to really take advantage of these modern approaches? Why do you want microservices in the first place? So you can innovate independently and empower the team that owns them to do the right thing and to work with their customers and to have their own product manager and be embedded within the team, engaging with customers, building what they need, iterating quickly. If you're working within a larger corporate context (may have siloed development and operations groups in different geographical locations, or a legacy of executives leading rather than teams leading) you have an organizational structure and culture that it's going to hold you back from the benefits. It is the same as lifting and shifting an application from an on-prem data center into public cloud without doing anything to it. You're taking something that was built for infrastructure and highly available at the single node level, and you're moving it into something where you have to build for high availability at the software layer instead. If you just move it into a new environment, you're probably paying more for less because you're not taking advantage of all the capabilities necessary to improve. With the org structure and the processes you've got to put in the work to tell the right story that helps them move forward instead of telling a story that puts you at odds and makes it extremely difficult to make that kind of progress. How do you take everybody, wherever they are, and help them all shift forward and move their applications forward?
0 upvotes
Anonymous Author
You have to look at why you want to move to agile or any new model. If you keep the same organizational structure you're wasting your time. You might as well stay where you're at. You need to look across the organization and figure out how you are going to invest in your people and train them to operate differently. They have to be independent. We have the concept of two-pizza teams: teams shouldn't be bigger than where you would need two pizzas to feed them. They should have authority to make decisions and fail quickly. If you're not making at least two or three bad decisions a week, you're not making enough decisions. When you fail quickly, you can course correct and move forward. The worst thing you can do is sit and commiserate for months on what direction to go in. You have to empower teams, without fear of failure, operate independently for what they're developing and course correct if for some reason something's not working out. They know what needs to be done and they know how to make the right decisions, but if you require sign-off from layers above them, it's going to fail. I've done a ton of lift and shift. You can talk to your blue in your face to customers who say, “We just want them out of our data center. We've been mandated again with the cloud, just move them.” Okay. We can do that, but what are you really accomplishing? There's not a lot of value necessarily in just lifting and shifting into the cloud. You may even end up paying more. There are things you can do to old, tired applications like moving API off of proprietary databases to more cloud native databases. And then you can start taking advantage of some other services that are built around that. The application layer stays the same, but you can swap out some of the parts underneath it as you go forward to make it more cloud-like. You can take advantage of the services that come as part of the cloud from that standpoint, but you have to be willing to invest, enable people to do it, and let them fail. Don't be afraid of failure. That's probably the biggest thing I see embraced in the companies that are succeeding these days.
0 upvotes
Anonymous Author
Google "Conway's Law"
0 upvotes
Anonymous Author
It has helped to spur a culture change/shift towards moving forward with industry standard processes through digital lenses.
0 upvotes