The topic of gatekeeping, especially in tech, seems to be getting increased attention recently. I'm not sure of the exact reason, but I think most of us can agree that the unproductive form of gatekeeping has gotten quite frustrating.
I'm calling out the unproductive form because a little bit of research indicates that a productive form of this actually exists. Whether it be to protect the worthiness of news, media, data, or to protect privacy, there seem to exist legitimate forms of gatekeeping—you can Google for more info around this on your own.
The point of writing this is to explore the unproductive form of gatekeeping, and what the opposite of that practice might be.
Whether it's your level of experience, your job title, or the various skills you have learned and practice, there is no shortage of folks that will tell you why you are not really at the level you think you are at, or why you might never really reach such a level.
Some common threads around unproductive gatekeeping include:
- "You're not a software engineer because [Insert infinite reasons here]."
- "[Insert programming language they dislike] programming isn't real programming."
- "You don't have a degree, so you're not actually a [Insert infinite variations of professions]."
Unproductive gatekeeping exists at all skill levels; it's a big fish, small fish cycle sometimes. I've been told before that I'm not a real web developer because I use tables versus CSS—this was after CSS had just come out, and I had not made the transition yet (dating myself here).
I was also once told that I'm not a real iOS developer because I was programming on a windows based machine versus an Intel-based Mac. Believe it or not, when the original iOS SDK was introduced, there was a PC toolchain that allowed us to make iOS apps, at least before Apple walled it off (dating myself again).
It's easy to identify and focus on unproductive gatekeeping because it's prevalent and so damn frustrating, but what of concentrating on the opposite of unproductive gatekeeping—by pondering this, I'm not referring to "productive" gatekeeping. My question is, what is anti-gatekeeping?
I think the answer is stewardship.
There are a lot of definitions for stewardship on the interwebs—do the Google search. I've done my investigation and have distilled a definition to the following:
- Stewardship is having a level of experience and taking responsibility for elevating others to the same level of expertise.
- Stewardship is being entrusted with what's in your care, like your craft, and guiding others through a path that empowers them to be entrusted with the same.
- Stewardship is creating an environment where people can grow and improve within a space while enhancing their sense of well-being.
- Stewardship is acting in service to others despite your personal interest.
I like these definitions; they feel right!
What Stewardship Might Look Like
Let's take the definitions above and imagine what stewardship (anti-gatekeeping) might look like out in the real world:
- When someone expresses a challenge or loss, instead of explaining why these are dues all people pay, or how they're doing things wrong—choose to be compassionate. Respect their journey and normalize their struggle. You were there once yourself.
- When someone expresses a win or achievement, instead of reducing that experience or shadowing that achievement behind your own—choose to give praise. Share that these achievements and victories will stack themselves into even greater ones. Help them keep the rocket fuel burning.
- When someone expresses interest in what you do by asking you a question, instead of finding reasons for the irrelevance of their question—choose to share more details about your own experience. Answer the question, share what worked for you and what didn't, and guide them towards the next questions they should be asking.
- Finally, be in service to your field and industry by empowering, elevating, and stepping out of the way.
Follow me on Twitter - It's the best way to learn about any new content I publish.
Top comments (2)
Take my like my good fellow.
It's a nice retrospective and analysis which I loved to read, I want to add that people that does this usually are insecure so think they are in trouble if any other gets the same knowledge.
A good practice, specially for newbies, when they come to show something they did is to ask why they do that, why they did it that way, and what it solves (use cases into the real world) so they can make an analysis of the "product" they just developed.
Then, if they have questions or difficulties to reach the answer it's important to help them so they can make a previous analysis before developing something and analyzing later.
I expect the young newbies to be better than me at the same age because of the tools, methodologies and so that seniors are developing; it must be always some kinda exponential 😄
I'm happy you enjoyed reading it!
I totally agree with the insecure part, it's a pattern I've seen repeatedly in my own career. I wish folks could be a bit more open. To your point, asking questions of newer devs around why they chose a certain approach, and what they think it solves, is a great way to much more productive conversations - and a new dev will learn so much more through this kind of approach. Thank you for sharing your thoughts, very useful! :)