I job-hop a lot in corporate environments (mostly Fortune 100), doing DevOps for legacy systems/teams rather than coding. As such, I don't push for anything when I first arrive.
It can take a while to understand how all the moving parts interact, both technically and organizationally. The systems in question are sometimes responsible for tens or even hundreds of millions of dollars in business, and critical corporate functions. Wading in with "Hey, I know more than you, stop doing that and do this instead" is the short path to sudden emergency downtime for production systems! And that's knowing they hired me because I'm the expert and know more than them.
So there will be processes that are really, really stupid. Slow, inefficient, maybe completely dysfunctional. But if they work, they work. Fixing/replacing them means interactions with other processes that can be very difficult to pull off. Process is usually a Big Ball of Mud Antipattern at the point I'm brought in, and fixing anything in the Big Ball of Mud is a challenge.
As for legacy apps... yes, built with antiquated technology, often poorly implemented, with a lot of uncertainty and fear. Change is really scary. What to do about this stuff depends on what the long-term vision for the product is. Is it in maintenance mode, or under active development? Is there a plan to replace it? Is there a realistic plan to replace it that has working results and a viable schedule? Generally, the best thing to do is leave the scary ugly thing alone. It was probably done pretty well back in its day.
Where I usually find myself making progress early on is finding things that are broken due to communication problems. One team says one thing, the other team says another, and everyone is mad and nothing gets done. Often, it's just a matter of rephrasing things to both teams, to find common ground and a way forward that everyone wants.
So really, my expertise isn't cool tech. It's being a good communicator on the engineering rather than the management side, someone with both development and operations experience who can speak to the concerns of both sides, and has seen similar problems in other organizations (big organizations like these usually have 10+ year people in key positions, who have no idea how the rest of the industry works anymore).
So yeah, the first thing I push for? Learning the lay of the land, so I can start charting paths.
It can take a while to understand how all the moving parts interact, both technically and organizationally. The systems in question are sometimes responsible for tens or even hundreds of millions of dollars in business, and critical corporate functions. Wading in with "Hey, I know more than you, stop doing that and do this instead" is the short path to sudden emergency downtime for production systems! And that's knowing they hired me because I'm the expert and know more than them.
So there will be processes that are really, really stupid. Slow, inefficient, maybe completely dysfunctional. But if they work, they work. Fixing/replacing them means interactions with other processes that can be very difficult to pull off. Process is usually a Big Ball of Mud Antipattern at the point I'm brought in, and fixing anything in the Big Ball of Mud is a challenge.
As for legacy apps... yes, built with antiquated technology, often poorly implemented, with a lot of uncertainty and fear. Change is really scary. What to do about this stuff depends on what the long-term vision for the product is. Is it in maintenance mode, or under active development? Is there a plan to replace it? Is there a realistic plan to replace it that has working results and a viable schedule? Generally, the best thing to do is leave the scary ugly thing alone. It was probably done pretty well back in its day.
Where I usually find myself making progress early on is finding things that are broken due to communication problems. One team says one thing, the other team says another, and everyone is mad and nothing gets done. Often, it's just a matter of rephrasing things to both teams, to find common ground and a way forward that everyone wants.
So really, my expertise isn't cool tech. It's being a good communicator on the engineering rather than the management side, someone with both development and operations experience who can speak to the concerns of both sides, and has seen similar problems in other organizations (big organizations like these usually have 10+ year people in key positions, who have no idea how the rest of the industry works anymore).
So yeah, the first thing I push for? Learning the lay of the land, so I can start charting paths.