We're a midsize company with roughly 1,000 users. Our internal IT environment is fairly mature, heavily virtualized, and split between on-premises systems and the cloud, although our Azure skills could be stronger. The existing sysadmins are capable and reliable.
Our software development effort, which is outsourced overseas, is a very different story. Projects often arrive without infrastructure or security requirements, and the developers seem unsure what they actually need. They are building applications in Blazor despite our push toward cloud-native approaches, and several mobile app projects have failed badly. Much of the code is bundled into one DLL, documentation is limited, HTTPS was initially overlooked, and we have found passwords stored in plaintext. The team has also resisted change control and modern CI/CD pipelines.
I'm trying to figure out what kind of technical leadership we're missing. Do we need a senior DevOps or platform engineer? Could that person help review application code and plan infrastructure, or do we really need a development manager, software architect, or senior engineering lead first? Our sysadmins are already strong at traditional operations, so I'm unsure where this responsibility should sit. What would be the most practical way to start correcting the situation?
4 Answers
Don’t focus too much on the single DLL or lack of comments yet. Those may indicate poor engineering, but plaintext credentials, missing transport security, no repeatable builds, and unclear ownership are the urgent risks.
A useful immediate test is to start with a clean build agent and see whether your company can check out the source, build it, deploy it, and recreate an environment without the vendor manually intervening. If that fails, you have a serious control and continuity problem. You should own the repositories, build process, deployment credentials, infrastructure definitions, and documentation.
The team structure may be part of the problem. Development, infrastructure, and security should collaborate from the beginning instead of handing a finished application to IT at the end. You don’t necessarily need a large new department, but you do need clear ownership: engineering owns the application, platform or infrastructure staff provide the secure runtime, and leadership enforces the process.
Given the current situation, bringing in an experienced Azure architect or engineering consultant for a short engagement could help establish the landing zone, architecture guidelines, CI/CD foundation, security baselines, and project template. After that, a permanent platform engineer and a stronger development lead may be more effective than hiring one person expected to fix everything.
This sounds primarily like an engineering leadership and accountability problem, not simply a missing DevOps hire. Someone on your side needs authority to define the technical standards, nonfunctional requirements, security expectations, and definition of done before work begins. They also need enough influence to reject work that fails those standards.
A senior DevOps or platform engineer can absolutely help with Azure architecture, deployment automation, security controls, and reviewing parts of the application. However, that person should not become a permanent babysitter for an unqualified development team. You likely need a senior engineering lead, development manager, or application architect who owns the quality of the software and the outsourced team.
The outsourcing agreement matters too. Security, documentation, testing, infrastructure requirements, source access, and acceptance criteria need to be written into the contract. Otherwise every correction becomes a request for extra unpaid work.
If you can only add one person initially, I’d lean toward a senior technical lead who understands both application development and Azure rather than a generic DevOps administrator. They can establish the target architecture, define requirements before projects start, assess whether the vendor is capable, and decide what should be handled by your existing IT team.
Your sysadmins can then operate the resulting environments, while a platform-focused engineer builds reusable deployment templates and safe defaults. The long-term goal should be to make the secure path the easy path: managed identities and a secrets vault instead of passwords in configuration, HTTPS enforced by the platform, code and dependency scanning in CI, proper logging, and policies that prevent unsafe cloud resources from being deployed.
Automated secret scanning, dependency checks, and pipeline gates can catch some problems, but they should support good leadership and standards rather than replace them. A pipeline can reliably deliver bad software if nobody defines what acceptable software is.