Where It Started
When I was a Unix systems administrator at Texas A&M’s College of Architecture, our department wasn’t particularly organized. That wasn’t unusual for higher ed IT at the time. Tech departments across the university were growing organically, responsibilities were expanding, and most groups were figuring it out as they went. Around that time I read Gene Kim’s The Phoenix Project, and like a lot of people who read it, I recognized way too much of my own environment in it.
Eventually I was able to convince my manager to read it, and he pushed for the entire department to read it before scheduling a group offsite. We stepped back and named every problem we could see. We looked at our processes and figured out what to cut, what to improve, and where software could do the job instead of a person. Then we made a plan and executed it.
That exercise is where the appetite for this kind of work came from for me. Once you’ve stepped back from the day-to-day, looked at how the work actually flows, and changed the shape of it, you start looking for the next place to apply the same thinking.
Wanting APIs Instead of Hardware
For me, the next place was my own infrastructure. We ran our own everything in the College of Architecture. Active Directory, mail, file servers, the whole stack. All of it out of a makeshift server room that had been retrofitted with extra cooling and not much else in the way of redundancy. I didn’t want to keep managing hardware. I wanted APIs I could consume to provision what I needed.
Each College Ran Its Own
The way the university worked, central IT provided shared services for the institution, but each college and program had its own IT organization. Because each college controlled its own money, none of them were required to use central IT for anything. They could, but they didn’t have to. And most of them didn’t want to. There was real hostility toward the idea of moving anything to central IT, mostly because nobody wanted to give up control of something they’d been running themselves for years. So when I started pushing for our college to move that direction, I was pushing against the default position of most of my peers across the university.
Central IT was running VMWare, same as we were, same as most groups across campus. The difference was that they were running it at scale, in a real data center, with the staff and processes to operate it as a platform. They were building it out with the intent to resell capacity to the colleges. So I pushed for the College of Architecture to move our compute over. We were already moving mail off-prem as part of a university-wide push, so the timing was right.
Crossing Department Lines
Offloading the hardware was a clear win, but it didn’t get me out of running ancillary services. I still had a Git server, a Chef server, and Atlassian Confluence and Jira, none of which I had any interest in continuing to manage. So I started getting to know my counterparts in other colleges. The Library and the College of Liberal Arts had fellow technologists doing similar automation work, dealing with the same problems. We started meeting regularly.
I pushed for us to centralize some of these ancillary services and share the management burden across departments, with real representation and a voice for each group. The services themselves ran on central IT’s infrastructure. They offered up resources to support the effort because it served their goals too.
That kept growing. We ended up running an official TAMU private GitHub instance that quickly became popular across the university. We pushed central IT to think about how they could support automation use cases that historically hadn’t been provided for, because nobody had ever asked. We helped centralize services that were genuinely useful to a much wider group than the small handful of us who started the conversation.
It was a good run. All of it from the bottom. A few technologists across departments pushed for changes that ended up affecting the entire university.
What Actually Made It Work
There were a few specific conditions in place around us, and without any one of them the push to centralize across departments would have died on the vine.
Autonomy
The first was that we were treated like adults. My direct manager was largely absent. He let me focus on the work that made me valuable and trusted me to figure out the rest. The other technologists I worked with across departments had similar latitude. Nobody was asking us for status updates on whether we’d been talking to people in other departments. Nobody was checking whether centralizing a Chef server was on a roadmap somewhere. We were given enough room to notice problems and act on them.
That kind of autonomy gets undersold. If I’d been on a tightly managed team where every hour had to map to a ticket, I never would have had the slack to walk over and meet the Library’s sysadmin in the first place.
Leadership Backing
The second was that our direct leadership backed the work once it became visible. Saving the university money and building something useful for the broader institution turned out to be an easy story for them to get behind. They didn’t have to drive the work, and they didn’t try to. What they did was endorse it once it had legs, give us cover when we needed it, and make it easy to keep going. The version of this that doesn’t work is leadership that tries to steer it from the top, or that gets territorial because it didn’t originate in their org.
You can’t mandate that culture into existence. But you can absolutely kill it.
Permission to Cross the Lines
The third is the one I think about the most. None of what we did was technically my job, or anyone else’s job either. Reaching out to the Library wasn’t on my goals. Pushing central IT to expose new capabilities wasn’t a project anyone had funded. We were doing it because the work was useful and we could see it was useful. That only works in a culture that doesn’t punish you for it. If at any point someone had pulled rank and told us to focus on our own departments, or made us feel like we were overstepping, the whole thing would have collapsed. What we had was a small group of people who had decided, individually, that the work mattered more than the turf. Central IT didn’t feel threatened that technologists from other groups were proposing changes to their platform. That was rare, and we knew it was rare, which is part of why we worked to keep the group functioning.
You can’t mandate that culture into existence. But you can absolutely kill it. One leader who treats a question from outside their reporting line as a challenge to their authority is enough to teach everyone around them to stop asking.
Transformation from the ground up sounds romantic when you write about it after the fact. In the moment it’s just a handful of people noticing something is broken and choosing to do something about it. The hard part isn’t finding those people. They exist in every organization. The hard part is whether the organization gets out of their way.
If you’re a leader and you want this kind of energy in your organization, the work isn’t to manufacture it. It’s to make sure you’re not the reason it can’t happen.