Internship Operating System | Systems Design Case Study

Role: Media & Publicity lead

Focus: Operations · Systems Design · Cross-functional Coordination · Intern Experience

I identified a gap in how internship expectations and responsibilities were being communicated and managed, then developed a department-level operating model and abstracted its underlying logic into a reusable framework.

01 — The context

In a youth-led organisation, I worked in a Media & Publicity leadership role spanning media, publicity, podcast/content production and related digital workflows. The internship programme involved contributors working across departments. That meant a good experience depended on more than recruitment alone: people needed a shared understanding of roles, expectations, supervision, resources, timelines and collaboration.

02 — The problem I identified

The initial recruitment communication left important parts of the internship experience insufficiently clear, including the nature of the opportunity and the practical expectations surrounding the role. I raised these questions before interviews because applicants were being asked to invest their time, and the organisation needed to be clear about what it was asking of them and what structure it would provide.

The problem therefore became broader than applicant selection:

How do we create an internship experience in which the organisation, managers and interns have a shared understanding of responsibilities, expectations and workflow?

03 — From recruitment clarity to operating clarity

I approached the problem in two stages.

First: clarify the opportunity

I pushed for clearer communication around the nature of the role, duration, expectations, mentorship and the overall experience being offered.

Then: solve the internal coordination problem

As we worked through the internship structure, it became clear that clarity also had to exist inside the organisation. Managers and departments needed a shared way to understand:

• who was responsible for what;

• who supervised each intern;

• what needed to happen and when;

• which tools and resources were required;

• how work moved between people and departments;

• what the expected output was;

• how feedback and development would happen.

That shifted the intervention from a recruitment fix to an operating-system problem.

04 — From department system to reusable framework

Because I directly managed Media & Publicity, I first built a detailed operating structure around the work I already understood deeply.

It covered onboarding, roles and expectations, tools, content workflows, portfolio projects, weekly operations, analytics and planned outputs.

The detail was intentional: it reflected the complexity of work I was directly managing.

I then separated that department-specific content from the underlying structure and turned the reusable logic into a master framework that could be adapted to different kinds of team work.

The reusable structure

The master table organised work around a common set of questions:

What needs doing? · What kind of work is it? · Who assigns it? · Who owns it? · Where does it stand? · When does it happen? · What resources are needed? · What needs to be delivered? · What can be shown? · What happens after review?

The point was not the database itself. The point was making the organisational logic visible, repeatable and adaptable.

05 — The operating architecture

Role architecture

Who is responsible for what?

Clear roles, responsibilities and boundaries between leads, managers and interns.

Workflow architecture

What needs to happen, when, and in what sequence?

Tasks, timelines, status and expected outputs made the work easier to follow.

Collaboration architecture

Who needs to work with whom?

The structure accounted for collaboration between managers, interns and departments, including shared work, dependencies and handoffs.

Development architecture

What does the intern gain from the work?

The system made room for feedback, reflection, recognition and demonstrable work rather than treating interns only as task capacity.

06 — Making collaboration visible

Work rarely stays within one role or department. I therefore treated collaboration as a layer around the work itself: the work table tracks the task, the people structure captures reporting relationships, and collaboration records make contributions, timing and handoffs visible.

The logic

Work

The Master Table remains the starting point for the task or project.

People

Managers, leads and interns are connected through a shared people structure with department and reporting relationships.

Handoffs

When work crosses roles or departments, a collaboration record captures who needs to contribute, what they need to do, when it is needed and what happens next.

Operational collaboration and manager-only evaluation are kept as separate layers so that people can see what they need to do without exposing information that belongs to managerial review.

07 — Designed with the team

I did not treat the framework as a finished system that other people simply had to accept.

I brought the structure into the wider team and asked for feedback on how collaboration should work and which tools were needed. That feedback informed the refinement of the framework.

Initial framework → Team feedback → Refinement → Agreement to use

The important part was that the structure had to be understandable and usable by people who had not originally designed it.

08 — Designing the intern experience, not only the workflow

The operating structure reflected a broader principle: when people contribute voluntarily, the organisation should make the exchange clear and meaningful.

The framework therefore made space for:

• clear expectations;

• defined responsibilities;

• appropriate resources and tools;

• mentorship and feedback;

• recognition and credit;

• ownership of demonstrable work;

• portfolio development and reflection.

The objective was not simply to extract output. It was to create a clearer relationship between organisational contribution and the contributor's development.

09 — Immediate result

The immediate value I saw was clarity.

The team had a clearer way to understand responsibilities, boundaries, timelines, tools and how different people would work together. It also gave us a more concrete way to think about how interns could be supported, recognised and developed rather than leaving those expectations implicit.

The team responded positively to the structure, and the framework gave us a practical answer to a problem that had previously been difficult to define clearly.

10 — Why this matters

What stayed with me was not simply that I had built a database. I had helped the team make sense of a problem that initially felt like a puzzle.

I wanted to solve it without lowering the standards we wanted the organisation to represent, while also making sure that contributors were not treated as disposable labour. Their responsibilities, contributions, support and opportunities for recognition needed to be clear.

That experience changed how I think about operational problems: the best time to solve a problem is often before it becomes a visible failure.

When a team anticipates ambiguity and gives people clarity about their roles, responsibilities and ways of working, it reduces unnecessary friction and gives people more confidence in the organisation around them.

For me, that is where good systems design becomes more than administration. It can help an organisation protect its standards, value the people who contribute to it, and build greater trust with its stakeholders.

What this project demonstrates

Systems thinking · Process design · Role clarity · Cross-functional coordination · Human-centred operations · Operational documentation

Evidence boundary

This version focuses on the design decisions, architecture and immediate value of the work. Individual names, raw internal conversations and sensitive personnel information are not included.

The detailed evidence record remains separate from this public-facing case study.