Does digital transformation necessitate organizational transformation?
AWS Enterprise Service Manager - Global Accounts in Software, 10,001+ employees
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.CTO in Software, 11 - 50 employees
Google "Conway's Law"Chief Information Officer in Manufacturing, 10,001+ employees
It has helped to spur a culture change/shift towards moving forward with industry standard processes through digital lenses.Content you might like
CTO in Software, 201 - 500 employees
Without a doubt - Technical Debt! It's a ball and chain that creates an ever increasing drag on any organization, stifles innovation, and prevents transformation.Text64%
Audio24%
Video10%
Emojis only!2%
297 PARTICIPANTS
Big Data21%
Remote Work17%
Microservices / Containerization11%
CI / CD5%
Zero-Trust15%
Automation2%
Digital Transformation16%
Cloud / Cloud Native1%
DevOps or DevSecOps6%
Other (comment)1%
1006 PARTICIPANTS
Chief Data Officer in Travel and Hospitality, Self-employed
Data & AnalyticsCEO in Services (non-Government), Self-employed
Using AI tools 2-3 a week. Use cases: -summaries of content
-slide outlines
-abstracts
-citations.
-Beauti.Ai for slide preparation
-Chat GPT 4
-Styluschat
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?