The Zapier workflow that fixed Monday mornings. The Power Automate flow that cut your team's help desk volume by roughly a third. The Zendesk triage setup that nobody complains about anymore because it just quietly works. All of that belongs to the company you built it for. None of it is on the public internet. None of it is in a GitHub repository. And when you go looking for your next role, or your first international client, or a promotion into a technical function, you will feel the weight of that absence.
This is the portfolio problem that almost every IT and support professional hits. Developers have GitHub. Designers have Behance. Writers have their bylines. IT ops and support builders work inside closed systems, for employers who own the output, and the work disappears the moment you sign an NDA or leave the job.
I have spent years thinking about this, partly out of necessity and partly because I kept watching sharp, capable people get passed over for roles they were clearly ready for, because they could not show their work. Here is what I have learned about fixing it.
What Doesn't Actually Work
Before the real answers, a quick clearing of the field.
Screenshots with client data blurred out. These prove very little. A blurred Zendesk view tells a hiring manager nothing about whether you designed the workflow intelligently or inherited it from someone else and just kept it running.
Generic claims without any specifics. "I automated ticket routing for a large company" could mean a single tag rule in the Zendesk views panel, or it could mean a multi-channel classification system with fallback logic. From the outside, those two things look identical. The vague claim does not help you.
Long lists of tools. Every IT professional says they use Zapier, Zendesk, n8n, Power Automate, HubSpot, and Active Directory. The list is table stakes. It does not differentiate you from the person who watched one tutorial for each tool and that was it.
Certifications as the main proof. Certifications matter, but they prove you can pass a vendor's exam. They do not prove you can design a system under real constraints, handle an edge case at 11pm, or explain your reasoning to a non-technical stakeholder. They are a baseline, not a portfolio.
The Core Insight: Teach the Concept, Not the Client
Here is the shift that unlocks everything else.
The actual intellectual property in your work is the problem-solving, not the implementation. The fact that you ran Zapier for Company X is Company X's business. The fact that you understood how to connect a form submission to a Help Scout conversation, tag it by urgency, and route it to the right team based on keywords, that understanding is yours. You developed it. You own it. And you can demonstrate it publicly without exposing a single client system.
The way you demonstrate it is by teaching it.
The best proxy for seeing someone's work is watching them explain it clearly enough that someone else could do it.
When I write a post explaining how to set up group-based M365 licensing, or how Zendesk triggers differ from automations, I am not showing you a client's Zendesk. I am showing you that I understand the system deeply enough to explain the decisions behind it. That is more useful information for someone evaluating my capabilities than any screenshot would be.
Four Things That Actually Build Public Proof
Write about what you are learning on the job. Not confidential details. Not client names. The concept. "I set up a Zapier multi-step zap this week and hit an interesting edge case with webhook timeouts. Here is how I resolved it." A single LinkedIn post like that, 250 words, is genuine public proof of capability. You are not revealing anything proprietary. You are demonstrating that you think rigorously about your work.
This is the whole point of this blog. Not every post I write is directly tied to a specific client engagement. But all of them reflect how I think about systems, where the complexity hides, and what to do when things break. Someone hiring for IT or support work can read three posts and have a clearer picture of my capabilities than they would get from a full CV.
Rebuild the concept with demo data. If you built a triage workflow for your employer, you cannot share that specific workflow. But you can build a simplified, anonymized version using free-tier tools and dummy data, document it, and share the writeup. The problem you solved, the approach you took, the tradeoffs you considered. None of that requires any real client information. The technique is yours.
Build small public side projects. Nothing elaborate is required. A single GitHub repository with a simple Power Automate template. An n8n workflow that pulls public data from a free API and does something useful with it. A shared Notion doc with a structured triage checklist you built from scratch. These are tiny. They take a few hours. But they are searchable, linkable, and permanently yours.
Get specific recommendations, not generic ones. "Felix is a great teammate and hard worker" is noise. "Felix built a password reset automation that removed roughly 15% of our help desk ticket volume, and he documented it so clearly that a junior team member maintained it without his involvement" is signal. When you deliver something genuinely useful at work, ask the person who benefited from it if they would be willing to write a specific recommendation on LinkedIn. The specificity is what makes it credible.
Where to Start If You Have Nothing Public Yet
Pick one thing you built or fixed in the last 90 days. Anything. The more mundane to you, the better, because what feels routine to an experienced IT professional is exactly what someone earlier in their career desperately needs to understand.
Strip out everything company-specific: names, logos, exact numbers, anything identifiable. What remains is the problem, your approach, and what you learned.
Write 300 words about it. Post it on LinkedIn. That is one piece of public evidence that did not exist before you wrote it.
The first one is the hardest, not because it is technically difficult, but because it requires you to adopt a new habit: treating your daily work as something worth documenting and sharing, not just something worth doing.
The Real Reason This Matters
The IT work gets done either way. The automation runs, the tickets close, the users get their access. Your career does not automatically advance because you did good work. It advances because decision-makers can see and evaluate the good work.
Developers understood this early, largely because their work was already digital and shareable. Support and IT operations professionals are catching up. The ones who do it early have a significant and compounding advantage: a growing body of public evidence that makes them easier to evaluate, easier to trust, and easier to hire.
You do not need to build a personal website or start a YouTube channel. You need to make one piece of your thinking visible each week. Write the LinkedIn post. Share the checklist. Explain the edge case. Turn the thing you learned into the thing someone else can find.
Your best work is under NDA. Your best thinking doesn't have to be.
If you are working through this and want to talk through what to share first, get in touch.
Comments