Implementing a successful DevOps and platform engineering team

I'm starting this post from when the organization was small and just starting out in DevOps all the way through implementing a platform engineering team with self service.

Showing the power of DevOps

n 2008 I came to the credit union from another one through a merger. The credit union I came from was ~200 million in assets and about 70,000 members.

The initial environment that I oversaw after the merger was a single server, which we manually deployed code from our local developer systems. At least we used configuration transforms for configuration, so that was nice.

That broader setup remained in place for years, but in 2013 I became the lead developer over the online banking system. That role is where things really started taking off and where I began pushing for a DevOps culture at the credit union. The legacy deployment model continued until about mid-2015. The original environment and deployment process for online banking was like this. It was running on Windows 2008R2 servers. The vendor would manually copy each file over to each of the 6 servers. The servers were on a private cloud hosted by another vendor, and we had very limited scalability resources, further causing us to need to do nightly deployments. There were also development tools like Visual Studio 2010 and SQL Server installed on every server among other tools. This resulted in no 2 servers being identical. It was a mess and wildly unreliable to say the least.

After I became the lead, I saw the deployment practices from the vendor and state of the servers. I explained to our management the issues and we eventually kicked the vendor out of the environment. They no longer had access to deploy code or even access the servers. From there I chose a server and made the others identical and used that as the basis for our development code base. Since no 2 servers were identical, we accepted the risk and potential issues that would arise from this and proceeded to fix any bugs that arose over the next couple of months. I had also improved the deployment process by using TeamCity to automatically package the site and built a script to do the deployment. The script automatically removed the server from the load balancer, synced the files to the server, and re-add them. It was clunky. But it worked as well as it could within the restraints we had.

Once the code base was identical across all systems, I proceeded to remove the development tools from each of the servers. The now increased reliability and deployment frequency showed how things can be more reliable, and deployments less impactfull. We went from deployments every quarter to every week. Deployments were small, easy, quick, and reliable. We only wanted to do it weekly due to the fact we had to do them at night and were still largely manual due to our limitations of not being able to connect those servers to TeamCity.

During this time, I built a new environment for our other software. It was a load balanced environment where everything deployed to it was from TeamCity and completely automated. It was rudimentary and still required nighttime deployments for some software while the majority were acceptable to take a few minutes of downtime during the day. The deployments were controlled by branches in Git. As in, one branch for the dev environment and one branch for production. Not ideal, but much better than manual code deployments from the developer's station.

The implementation of DevOps at the credit union

With the creation of .NET Core, I wanted to revisit our entire deployment and running strategy across everything, from online banking down to individual API's. I spent a lot of time researching this, and blue/green was what I ultimately chose. I created the credit unions first blue/green deployment setup that ran active/active in 2 data centers in late 2015. A principal we still maintain today between our Windows and Kubernetes infrastructure.

The blue/green servers consisted of a development and test environment running on the same servers and a stage and production environment on different servers. There were 2 servers in each data center per color per environment. This allowed for active/active data center deployments, the first at the credit union. We had different tiers of systems. We had an API tier and front-end site tier. We also had a member facing tier that lived in the DMZ.

In the end, it was something like 80 VM's. This was a lot, and Team City couldn't handle this deployment strategy and sheer number of servers at the time very well. I chose a different tool for deployments, Octopus Deploy. We stored all configurations in Octopus and removed them from source control. This allowed for things like build-once and promotion of artifacts. At this time, we also started to change our code hosting from GitHub Enterprise to TFS.

With this strategy we could deploy to one color, which we called stage, then move the workload from the old color to the new one. The exact running environment could be tested and verified before our members and employees used the system. This allowed for hit-less deployments during the day. It has allowed us to replace the entire farms servers during the day for OS upgrades without incident.

We still use this environment for our Windows hosted systems, 11 years later.

Late 2016 to early 2017 we migrated our online banking from our hosted provider to the blue green strategy on premises. This allowed for much increased capacity, built-in fail over, database redundancy among the other benefits that we already saw from blue/green. We then went from a weekly night deployment to multiple deployments per day. Extremely powerful.

During this time, I had not only lead development responsibilities but DevOps. For the entire development staff. It was too much for one person to handle.

The DevOps manager role

Eventually we replaced the aging online banking system with a new vendor. This was a sad day, but it was inevitable. About a year later, in 2018, with the demand for DevOps related work, pipelines, environments, support, tool administration, it became apparent that we will need a DevOps team.

I know, I know, DevOps isn't a role, however, in practice, I disagree. The dream is that it isn't; developers do it all, from start to finish. However, developers only want to code; they don't want to build pipelines and run environments or be on call to support their software. IT doesn't want to deal with all of the rapid changes; they want stability. There needs to be an intermediary, someone who speaks the language of developers and IT. They are effectively facilitators at heart. Making it so developers can get their tasks out to production through pipelines and interfacing with IT to request things like firewall rules and servers as needed.

At the credit union the DevOps team, myself at this point, was responsible for developer tools as well as all the above DevOps work, pipelines, deployments, application support. It was a lot, and we had one very large task ahead of us. Move all of our stuff onto the blue/green environment. We had a developer who liked the world of DevOps, and I was able to hire him to help out with this and the other responsibilities.

We were much smaller at this point in time, only a handful of teams. And supporting them was OK, not great though. There were a lot of needs from the development staff. We were very nimble and flexible. We made a lot of progress in terms of automating things, which still continues.

Then, we experienced a massive growth spurt in the development staff. In a couple of years, we went from something like 20 to about 80 developers. That was a lot to handle. So, the DevOps team grew. The turning point, and this is the most important now, is to put one DevOps engineer on a team; these were senior level engineers and lower. Put the lower engineers on the more self-sufficient teams, and the stronger ones on the more needy teams.

The principals

Now we're in 2019, a couple of years into our DevOps journey. At this point, we had our blue/green environment set up and fully utilized. I had about 6 or 7 DevOps engineers underneath me. And it was a lot for a single person to manage technically and as a people manager.

Most of the development teams had an individual DevOps engineer; some were split across 2 teams. However, I became a bottleneck for technical issues. I was no longer able to support the engineers the way I wanted to. I was working long days, 10-12 hours to try and stay on top of things; it wasn't sustainable. In addition, we wanted to bring in something new, the next iteration of our hosting environment, Kubernetes. We chose Rancher/RKE1 for this with vendor support. This was a good idea for our first set of clusters. Expensive, but using a vendor when we didn't have much experience was a good idea in theory.

By bringing in Kubernetes we needed some expertise in the field. So, we got a principal engineer, we went through a couple of them over the next couple of years, until we found an amazing individual. Now mind you, we're still senior at the top of the band, just one person to support the development teams and help us with our Kubernetes journey. He eventually left after a year but came back to a principal role. He brought someone else along as another principal.

This was the game changer. These 2 were not assigned to individual development teams, but instead they supported and helped to mentor the other DevOps engineers. At this point I had 9 people underneath me, and there were about 80 developers we were supporting. I had 3 or 4 DevOps engineers dedicated to a specific principal. All of a sudden, teams were moving more freely, getting unblocked, DevOps was running nicely.

More growth and the creation of platform engineering

Then, 2024 rolled around and we had another growth spurt. Over the next year we grew to 120 developers, however we didn't grow the DevOps team very much. By the end of this growth spurt I had 10 DevOps engineers supporting about 15 highly performing development teams. This wasn't going so well. We can't grow our DevOps team linearly with the development teams. It's just not feasible. Things started taking a long time, new repositories with pipelines and environments could be 2 weeks of development and DevOps teams scaffolding a boilerplate project that worked in Kubernetes with health checks and everything to support it.

We needed something to help reduce the burden on DevOps engineers to support our development teams. We shifted DevOps engineers between teams based on workload a couple of times up to this point, but it still wasn't enough.

It's now 2025. We're neck deep in the largest project the credit union has ever done. We're creating new repositories daily using a GitHub Workflow that my soon to be platform lead created. It worked but was problematic. It was largely reliant on people choosing the correct drop-down options and filling out the other fields correctly. This worked for a few months, but we realized we needed something better. At this point, mid 2025, we chose Backstage as the tool for the job and went to BackstageCon at KubeCon in Atlanta.

There, my lead and I took the platform engineering track. Learning everything we could. We worked the evenings after the conference to get it up and running, and by the end of the conference we had a locally running instance of Backstage that could create a plain empty repository.

When we got back, I had tasked my lead with getting it up and running. We were waiting for the beginning of the year to start hiring the other platform engineer due to budgeting. In February of 2026 we hired the second platform engineer, this time a developer. We wanted the insight of someone from our development staff, with the mindset of DevOps. We also wanted a developer because Backstage is just a shell. You build everything in it.

Right now, it's 2 people. One highly skilled DevOps engineer as the lead of this team, and one highly skilled developer. They were tasked with automating the DevOps manual tasks.

We first started by automating the creation of repositories in GitHub. This turned out to be a big win with low friction. By April 2026 we had automated the creation of most of our repository types, taking new repositories from weeks to minutes, and building consistent boilerplate applications that supported Kubernetes and our other infrastructure.

We also automated the creation of certain request tickets in Service Now to make that easier for the DevOps teams to request things like firewall rule changes and new servers. No more do people need to know what the SQL server port is, or IP ranges for Kubernetes clusters. It's simple drop downs and Backstage fills in the required information.

Conclusion

Looking back, every major step in this journey came from the same need: reduce friction, improve reliability, and help development teams move faster without sacrificing stability. What started as cleaning up inconsistent servers and automating deployments eventually became blue/green infrastructure, dedicated DevOps support, principal-level technical leadership, and now a platform engineering team focused on self-service. 

The lesson for me is that DevOps and platform engineering are not fixed destinations. They are responses to the size, maturity, and needs of the organization at a given moment. What worked for a handful of developers did not work for 80, and what worked for 80 did not work for 120. Each phase required us to rethink how we supported teams, where the bottlenecks were, and how much ownership we could safely push closer to developers. 

We are still early in the platform engineering phase, but the direction is clear. The goal is not to replace DevOps engineers or remove collaboration. The goal is to make the common path easier, safer, and faster so engineers can spend more time solving business problems and less time waiting on repetitive infrastructure work. I’m excited to see where this goes next as we continue growing the platform, the teams, and the credit union’s ability to deliver software.