Traditional IT is failing in the enterprise because people are asked to do too much and they can't scale. Why does a DevOps culture want small full stack teams that are highly collaborative, because it can scale and succeeds. If you need to do more, you optimize with automation, become more efficient, you adjust scope or you add more resources where it makes sense for the business need.
Silos do not scale. On the surface you think it does and many IT leaders believe it does but scaling does not happen when you have competing goals and deliverable. You just react to everything and mostly fail in one way or many. The team misses deadlines, create issues, or have unhappy employees who are just waiting to move to a DevOps culture.
DevOps cultures should be polarized. You either enable people to do the job or you are part of the team. You will fail if you are in the middle. If you work in a silo that tries to be technical, business and project smart, you will fail because you can't do all of those things in isolation. You will struggle with competing deliverables. No one will care what all you have to do because you are a silo and just need to deliver. By the time you realize you are behind, you will have lost employees or not be able to hire until you don't need them.
The solution is to have full stack teams that work at the same pace and goals. This way everyone succeeds or fails. There is no silo failures because "They did not deliver". My personal opinion is this is the best way to deliver, especially at smaller companies with solid DevOps cultures. The job satisfaction and relationships which build will last forever. Another benefit is the knowledge learning is accelerated from a strong DevOps team across the whole stack. I stay in touch with a team I worked on in 2004 before we called this stuff DevOps.
The next best option is to be an enabler team. I see "DevOps" teams being formed in the industry and this is where they do succeed. They do the upfront work like Value Stream Mapping, CI, CD, Monitoring, Infra, CM or what ever is needed around the code and then, get out of the way. They are like a consulting company, not a silo. This is helpful in the Enterprise because many companies just want features delivered and don't have the leadership to stop and deliver automation. "DevOps" teams can't know about each use case or business need. They should be enabling the teams to be more agile and deliver the business needs faster.
The book the E-Myth teaches that you either work on the business or in the business. True DevOps team work in the business and enablement teams work on the business. If you are not in a DevOps culture, decide which kind of silo you want to be and lead your teams in that direction. Traditional IT silos do not scale and need leadership to be able to deliver at scale in the future. I recommend if you are a small silo team that delivers for many more teams, you should be an enabler. If you are a team that matches up to the product teams, then maybe you should move to a DevOps culture team. Be careful that product teams are different than projects. Projects scale up and down. You will not keep up in that scenario so you should be an enabler. Here are some examples of enablement:
Silos do not scale. On the surface you think it does and many IT leaders believe it does but scaling does not happen when you have competing goals and deliverable. You just react to everything and mostly fail in one way or many. The team misses deadlines, create issues, or have unhappy employees who are just waiting to move to a DevOps culture.
DevOps cultures should be polarized. You either enable people to do the job or you are part of the team. You will fail if you are in the middle. If you work in a silo that tries to be technical, business and project smart, you will fail because you can't do all of those things in isolation. You will struggle with competing deliverables. No one will care what all you have to do because you are a silo and just need to deliver. By the time you realize you are behind, you will have lost employees or not be able to hire until you don't need them.
The solution is to have full stack teams that work at the same pace and goals. This way everyone succeeds or fails. There is no silo failures because "They did not deliver". My personal opinion is this is the best way to deliver, especially at smaller companies with solid DevOps cultures. The job satisfaction and relationships which build will last forever. Another benefit is the knowledge learning is accelerated from a strong DevOps team across the whole stack. I stay in touch with a team I worked on in 2004 before we called this stuff DevOps.
The next best option is to be an enabler team. I see "DevOps" teams being formed in the industry and this is where they do succeed. They do the upfront work like Value Stream Mapping, CI, CD, Monitoring, Infra, CM or what ever is needed around the code and then, get out of the way. They are like a consulting company, not a silo. This is helpful in the Enterprise because many companies just want features delivered and don't have the leadership to stop and deliver automation. "DevOps" teams can't know about each use case or business need. They should be enabling the teams to be more agile and deliver the business needs faster.
The book the E-Myth teaches that you either work on the business or in the business. True DevOps team work in the business and enablement teams work on the business. If you are not in a DevOps culture, decide which kind of silo you want to be and lead your teams in that direction. Traditional IT silos do not scale and need leadership to be able to deliver at scale in the future. I recommend if you are a small silo team that delivers for many more teams, you should be an enabler. If you are a team that matches up to the product teams, then maybe you should move to a DevOps culture team. Be careful that product teams are different than projects. Projects scale up and down. You will not keep up in that scenario so you should be an enabler. Here are some examples of enablement:
- Build CI and CD solutions for teams to use and give them control of it.
- Build up front Chef/Puppet code and then hand it over
- Create frameworks and reporting for monitoring solutions but let the teams implement and support monitors
- Engineers should give access or views into systems so they can be supported. Don't be controlling by owning changes and security concerns
- Build solutions to run QA automation and reporting. Then, let the QA teams own the scripts.
- Provide ways to give Dev and QA development systems to test any time they need it.
Comments