Transform Your Delivery: Three Technology Roles You’ve Never Heard Of

Kent Corley

A great deal has been written about delivering software and systems. There are a multitude of different tools, methodologies, and approaches that impact people, process, and technology and have been discussed in blogs like these forever. However, one question that has not had enough attention is: “What exactly are the key roles from an organization perspective that can amplify the process of systems delivery?

The roles people should understand better are those focused intensely on delivery. These are Delivery Manager, Delivery Architect, and Delivery Engineer. You hear a lot about project managers, solution architects, scrum masters, and developers, but I want to condense what is important around delivery out of these potentially vague job titles into the essence of “what is delivery?” and the people whose job it is to make it happen.

The modern production line is a great analogy for modern software development. I like to think the people that fill these delivery roles are the ones that architect, build, and run that production line. Learning about what they can do for you will help in thinking about organizing your team to understand, align, and take advantage of these “production line” software delivery practices.



In discussing the “delivery manager” role, I am going to be a little intentionally provocative about standard IT project management. Let’s define the IT project manager as someone that manages a schedule, meets with the delivery team(s), identifies risks and issues, and provides status to executive stakeholders. Many times, these folks are in a standard PMO-matrixed organization where they are assigned to one or more projects and have responsibility for the project, but not necessarily the resources on the team or the specific business outcome of the project. Many quality systems are delivered by project managers every day, and I personally have been in this role more than once. And yet, this type of project management has the potential to create quite a bit of dysfunction if you are not careful.

The quality of the project is directly related to the skill of the project manager. There is distributed (meaning, little) accountability in many instances, and the focus is on the “management” not the “project.” With this approach, you can end up with a well-constructed and well thought out plan that is months late, with a beautiful, informative status report that is bright RED (meaning, late with no way to recover).

Accountability and focus are where this traditional model can break down. Re-casting a project manager role as a Delivery Manager can help. In my definition, a Delivery Manager is someone that is on the hook to deliver the solution and is not matrixed. People on the project report directly to the Delivery Manager, and he or she is one throat to choke. They are a strong coach that has experience doing the work they are managing— including direct role-based experience as a developer, tester, and/or architect. The Delivery Manager works with the Delivery Architect and Delivery Engineer to build out the delivery pipeline to production. Focus is on the speed and quality of the delivery. In smaller teams, the actual role of the person could be a scrum master, in SAFE (Scaled Agile Framework) that person could be the release train engineer or product manager. The important point here is that this individual is 100 percent focused on the delivery, has specific technical skills and background to coach a team, and is fully accountable for the success of the project. In a previous article, I discuss how the closer this person represents the business goals, the better.



The Delivery Architect is a solution architect, where the solution is the delivery system or the “assembly line” that delivers capabilities to production. In the world of DevOps, this is called the Delivery Pipeline. Think of this individual as the industrial engineer for the assembly line.

The Delivery Architect helps select the myriad of tools you need to leverage in order to support your delivery. This individual can also act as a Product Manager for the delivery system by defining and advocating for key requirements. The Delivery Architect can evangelize for continuous integration and continuous delivery (CI/CD) practices, with leadership, business, and delivery teams. They ensure this system is as easy to use as possible, as these delivery teams are really their customers. The Delivery Architect should have deep technical knowledge around development processes, CI/CD tools, virtual infrastructure (public and private clouds), and a deep operations perspective. They should also be focused on bottlenecks in the pipeline and use metrics to make certain the system is constantly optimizing to focus on speed and quality of releases.

Side Note: If you trying to get up to speed on CI/CD continuous integration or continuous delivery, there are some great websites and materials out there. My favorites are the blog DevOps Cookbook and the book The Phoenix Project, both co-authored by Gene Kim.



The Delivery Engineer is the person (or people) that are responsible for implementing the delivery CI/CD pipeline and automating all the associated environments. Historically, this job is handed out to either a developer as a part time job to try to automate some things, or to someone who has a title of Configuration Manager. In my experience, the Configuration Manager role is often filled by someone that has an operations background, writes a lot of ad hoc scripts not under source control (even when the person is responsible for supporting the source control system). This person is arguably the most overworked and underappreciated person in the building.  As an aside, when I see what I call the “Configuration Manager anti-pattern” in a company I am working with, I ask who is that person’s backup, and invariably get an answer that they are working on it. This should by no means be an afterthought, or something done when you can make the time. This work should be invested in and prioritized just as much as an auto company invests in engineers to optimize its production lines. Many studies demonstrate that investment in this area pays very rich dividends (one is cited below). This is particularly true when the Delivery Engineer works with Platform Engineers to build a solid platform for a system, allowing developers to focus on implementing business logic (and not getting the logger working in a new test environment for the 100th time).


When you go out to LinkedIn, you don’t see much demand for people with these names in their title, and I am not suggesting (at least at this point) that we should go through an org transformation to retitle everyone in your delivery organization. But if you are doing large scale systems development, or systems integration of large COTS packages, you should at least understand what these roles are responsible for and make sure you have people in your delivery organization that you can point to and say, “They are doing that the work.”

Focusing on delivery— the act of delivery, and the systems that facilitate your delivery —will help accelerate your delivery in ways that I still don’t think are truly appreciated by many organizations.  Luckily, studies such as Puppet’s the “State of Devops Report,” paint a picture of how beneficial these capabilities are to an organization’s bottom line. This kind of focus brings attention to where it matters in delivering new capabilities for your customers and stakeholders. See who in your organization is doing (or not doing) these roles. I am certain when you look for these disciplines, you’ll learn something about your organization — what’s working, what’s not, and what you can do to impact change.