There is a particular kind of mistake that is easy to make inside a professional community.
We find the thing that made the community valuable to us, and then we start to believe that thing should define the community for everyone else.
For some people, that is technical depth. They want more time spent in the weeds, more conversation about systems, standards, signal flow, troubleshooting, design, interoperability, and the actual work of making technology function. For others, the value is in management, leadership, communication, personal development, relationships, career growth, or simply finding people who understand the strange little corner of the world we happen to work in.
And for a surprising number of people, when you ask what matters most, the answer is not a session, a certification, or a piece of content at all. It is the people they met. The relationships they built. The feeling that they had found others who understood the work, the frustration, the absurdity, and sometimes the loneliness that can come with it.
None of those are bad things to want, but the problem starts when preference becomes prescription.
There is a perfectly reasonable argument that professional organizations can drift. They can become so focused on growth, partnerships, visibility, leadership language, events, and all of the machinery surrounding the work that they lose touch with the work itself. There are times when “back to basics” is probably exactly the right instinct.
The harder question is: whose basics?
I have my own bias here. I have spent enough of my career watching technical problems turn out to be people problems that I probably overcorrect in the other direction. Put ten engineers in a room talking about codecs long enough and I will eventually start wondering who is developing the next generation of leaders, who is teaching people how to communicate, who is helping someone navigate a bad boss, and whether anyone in the room has thought about what happens when the person who knows everything leaves.
But I also love the technical side of this work. I can happily disappear into the details of a system, a design, a platform, or a problem that needs to be solved. That expertise matters because it is how we deliver real results. Technical depth is a partner to leadership and strategy. It is the mechanism that turns all of our plans and promises into something that actually works.
The mistake is not caring deeply about the technical work. The mistake would be assuming that because I see the technical work as a means to an end, everyone else has to see it that way too.
The engineer will naturally want more engineering. The manager will want more leadership development. The person who came for technical training may think everything else is noise. The person who found a career opportunity, a mentor, a friend, or a sense of belonging may believe those things are the real value. They’re all right.
The mistake is deciding that because something was valuable to me, then that is where the value lies for all.
I think about that often in the context of Higher Ed AV Media. The people who contribute are not interchangeable voices producing variations on the same approved theme. They are people with jobs, families, expertise, frustrations, strange interests, unfinished thoughts, and occasionally something they need to say.
The value is in the fact that they do not all see the same thing the same way.
One person notices the technical problem nobody else has written about. Someone else understands what it feels like to inherit a broken team. Another has spent years thinking about accessibility, classroom design, faculty relationships, budgeting, burnout, AI, networking, leadership, or any of the countless things that make up the work we broadly call higher education technology.
The editorial challenge is not to flatten those differences into consistency. It is to recognize when there is something useful in a perspective and help make enough space for it to be heard clearly.
A technical case study can belong next to a personal reflection. A piece about network architecture can belong next to one about management. A technician, director, instructional designer, faculty member, manufacturer, consultant, or someone who somehow wandered into AV and never found the exit can all have something useful to say.
Not everything will be for everyone. That is not a bug. It is a feature.
A reader may skip one article because the subject has nothing to do with their work and spend twenty minutes with the next because it names a problem they have been unable to articulate. They may read something because it teaches them something new, because it shows them how someone else sees the world, because they disagree with it, or because the person writing has lived through something they have not.
That is part of what a community is supposed to do. It should expose us to people who are not exactly like us.
This year, is HETMA Homecoming, and the more I think about that word, the more it seems to fit.
Alumni all come back. Those who studied engineering, English, biology, art, business, law, education, music, or something else entirely. Some were athletes. Some were in student government. Some spent most of their time in a lab, a theater, a library, a residence hall, or a bar just off campus. They graduated in different decades, built different lives, and may have almost nothing else in common.
Yet all of them can come back to the same place and call it home. They all wear the same school name on their sweatshirt. They all cheer for the same team.
That is part of what makes a campus remarkable. Its meaning is not diminished because thousands of different people experienced it differently. Its meaning becomes larger because they did.
Our community is the same.
It should not belong to the person who has been there the longest, the person with the loudest voice, the person with the most expertise, or the person currently holding a title. We should all advocate for what we think the community can add, where it can improve, and what it may be missing. That is part of caring about it.
But there is a point where advocating for addition can turn into advocating for subtraction. When what I want it to be requires that it not be what you want it to be then we hit the null state. A preference becomes a standard, then a boundary, then a test of whether someone or something really belongs.
At that point, we are no longer building community. We are seeking control, usually in the name of making it “better” when the reality its we’re making it comfortable or familiar to ourselves.
Professional communities are especially vulnerable to this because expertise can make certainty feel justified. We spend our careers getting good at something. We build strong opinions because strong opinions are often useful. We learn what works for us.
Then, if we are not careful, “this is what works” slowly becomes “this is what matters,” and eventually, “this is what everyone should be doing.”
Some of the best things that happen in communities are things nobody centrally planned. People meet. They start talking. They get irritated about something. They build a project, a podcast, a meetup, a scholarship, a weird side initiative, or an entire career path around a shared interest.
They care because some part of it belongs to them. They have authorship. They have room to pursue what they see, make something other people may not have thought to ask for, and occasionally create something far more valuable than anyone could have designed by committee.
Leadership is making space and then resisting the urge to fill every space yourself. It is seeking to understand before being understood, and recognizing that a team or a community can become something none of us would have been capable of designing alone.
The goal is to create the conditions where the community can become more than the sum of its parts, and certainly more than any one of us thinks it should be.
