Building a Common Ground

This post is the first in a series about Systems Administration at CS++. This post also inspired a talk that I gave at FOSDEM in 2026, viewable here

This post is one of the longest I have ever written, which is why I turned it into a talk.

It covers a very unique position that student-led societies has, how we solved it, and how you and your team can benefit from what we learned.

I recommend you read the whole post for context and inspiration, though the conclusion works as a standalone unit if you don't have the time.

CS++ is split into two main groups, the events, finances, and day-to-day operations managed by 11 committee members, and the technical services and physical infrastructure managed by 5 committee members.

This post is about the latter. As of March 2026, CS++ runs almost 40 services for nearly 10 societies in TU Dublin, we are also involved in the 'Backup Intersocs Nationally' initiative, a plan to backup every Computing & Networking Society's critical data on eachother.

Specifically, this post is about those 5 committee members, who are officially called 'Systems Administrators'. These 5 members are all students of TU Dublin who volunteer their time to maintain and grow this technical stack.

By now you might see the problem. These 5 students can be from any of TU Dublin's 6x Computer Science courses, none of which share a single module or syllabus (or may not even be a CS Student at all!) Atop this, they could be as young as a First Year Undergraduate, or a PhD candidate in their final year.

This presents a highly unique situation that is alien to that of industry jobs, there is NO guaranteed knowledge, NO guaranteed time commitment, and NO consistent time that a Sysadmin may be in the committee (Usually a maximum of 4 years).

Currently, the 5 Sysadmins are in 4 different undergraduate courses, with 2x in their 4th (and final) Year, 2x in 3rd Year and 1x in 2nd Year.

We have to maintain critical services for ourselves and others with a team that is fully replaced every 4 years. Also, that team has no guaranteed knowledge on any technology.

When I joined the university 4 years ago, I began to shape the technical stack of CS++ and became the de-facto Chief Sysadmin and Architect. Now, with less than 100 days until I stop being a Sysadmin (July 1st, 2026), my focus has been solely on handover. Not only am I handing over the services and topics I was the owner of, I am also passing on my knowledge, skills and experience that I gained from joining the society.

The biggest thing I wanted to do was to build a common language, understanding and knowledge-set that the Sysadmins can build upon. I solved this by creating a series of tasks called Sysadmin Challenges.

The (currently) 11 challenges were designed to build upon each other, with the goal of covering all aspects from the hardware we use, to the software we run everything on. I also wanted to drill in the regular tasks Sysadmins will perform, and prepare them for common pit-falls they will run into. The challenges start with creating a Virtual Machine from a template, and moves on to networking, security, troubleshooting and ends with building a complete cluster from scratch.

These challenges were designed so that the majority of them can be done in our staging environment, whenever Sysadmins are available to do them, and not in an environment where I am always available. This required the instructions to be written in a manner that would allow Sysadmins to complete the challenge completely unsupervised.

I was the only Sysadmin to have any prior knowledge and experience in systems administration, as these skills are not taught in any of the courses. Since we advertise the role as 'experience preferred, but not needed', I had to make sure that everything they need to know is passed on to allow them to perform their duties, and feel empowered to work on new projects.

These skills are transferable to personal projects and help improve their understanding of what they learn in class, and most importantly, are beneficial in their careers after graduation.

I am a firm believer in Free as in Freedom, and as such, the Sysadmin Challenges (like all CS++ projects) is GNU GPL V3.0 licensed.

Even though they are highly specialised to our environment, the concepts and approach fit as a good template for others to transform to the environment of other societies and teams.

The Sysadmin Challenges were highly inspired by the CTF Challenges from Zerodays and the AWS GameDays. By providing high-level instructions and leaving out common pitfalls, the Sysadmins are forced to troubleshoot and research on their own to achieve a goal.

Task instructions follow a simple format:

1. A series of milestones to be achieved
2. Any relevant notes
3. Services to use (To avoid misdirection)
4. Milestone Headers
5. Completion Criteria
6. This approach helps inform the Sysadmin on what they must use for that challenge, and provides relevant hints but avoids hand-holding to actively stimulate learning.

All things change, and the current technical stack should be no different. As software reaches EOL, and CS++'s procedures and infrastructure changes, the challenges should be amended to be accurate to the new infra.

By being a public repository on CS++'s GitHub organisation, this allows all Sysadmins to amend the contents, as well as anyone with a GitHub account to open issues and pull requests to suggest changes.

The challenges also fail-safe. If the society dies (although unlikely), the information isn't lost and can be easily found by those restarting it in the future.

Putting it simply, knowing how to do something while not knowing why is useless. A good Sysadmin needs to know why a task has to be done, instead of just how to do it.

The Sysadmin Challenges focus on how to do something, and our docs tell our Sysadmins why and what. As described in our Docs Philosophy, they have been written with the 'Bus Factor' in mind, i.e. 'What happens if the soc dies, or there is no handover?'

As a solution, the docs are written as a series of layers (an approach pioneered by Seán in the University of Galway CompSoc).

“You can't automate tasks when you don't have tasks to do. You have no tasks without having services. You have no services without an Operating System. You have no Operating System without Hardware.”

The aim of this approach to documentation is to prepare for a possible full Sysadmin reset, and empower them to learn about our systems, what we did, why we did it and how it was done.

This gives a solid foundation to rebuild upon. Even if they choose a different technical stack, they will eventually encounter the same problems we did, and the docs should help them overcome it.

The docs and the challenges give Sysadmins the why and how, but this does not empower them to choose their own actions and to feel like they can contribute without being told what to do.

In February 2025, I changed how we delegated tasks and implemented 'Ownership'. The hierarchy was flattened, and instead of a single leader, everyone was a leader. Every topic and service had an owner.

Owners were not expected to do all of the work for the topics they owned. Instead, they were the expert for that topic and each owner was empowered to make the decisions they thought were best. This automatically gives them agency and massively increased engagement within the Sysadmins.

As students, we are used to being in a hierarchical structure (We are answerable to lecturers, and other staff). This does not work as well in student-led societies. Therefore, leadership structures in societies should unconsciously empower everyone and make them feel engaged and committed to what they are working on. Ownership does just that, and made it easy to naturally redistribute the workload as personal and academic commitments change over time.

Ownership also naturally supports handover. Last year I was the owner for more than half of the ownership topics. Now I am just responsible for the password manager, VPN, systems architecture and security, and with sysadmins shadowing and docs for all of these. Once I graduate, these can be seamlessly handed over and the team can continue to grow.

Ownership also naturally supports handing over. Last year, I was the owner for over half of all Sysadmin topics. Now, I am just responsible for the password manager, our VPN, the architecture and security. With younger Sysadmins shadowing my work, and the documentation on these topics. I know that when I graduate, I can seamlessly hand over all of them to the rest of the team and they can grow them without me.

CS++, like all student-led societies have a very unique advantage that you will not see in a professional environment.

WE KNOW EXACTLY HOW LONG PEOPLE WILL BE AROUND FOR.

At most, a Sysadmin will be around for 4 years. That gives us 4 years to train them up, and then prepare for handover.

The approaches we have taken for training, handover and ownership are directly transferrable to industry environments. You should be testing and fixing your onboarding documentation as you take on new colleagues. You need to always remember that what you have in your head is not shared to the newbie.

Practical challenges in onboarding are great at reducing the learning curve. A handful of practical challenges that make them rehearse what they regularly do is great. Having them naturally run into the quirks of your environment as they practice is even better!

Most importantly, WRITE THOSE DOCS AND KEEP THEM UP TO DATE. You will not be here forever, no-one will. The Saturn V can't be built anymore because the quirks of machining and integrating the system were kept in the minds of the manufacturers. Those manufacturers are dead.

You should be writing down everything you know, I like to use Diátaxis for that. Your work should have its quirks documented. You should even include why you did something like that.

Future you will thank current you for writing such good documents. Because future you might not remember why it had to add a timeout to a function.

You won't know how long you and the others will be around, so make it easier for those cleaning up after you.