What I Actually Do, What I Don't, and Why That Matters More Than Keywords

A LinkedIn profile can look off when someone scans for buzzwords, but in real delivery environments, the difference between keyword alignment and operational fit is often where the real value lives.

There's a funny thing that happens on LinkedIn.

Someone searches a few keywords. Maybe they want "DevSecOps leader,""cloud architect,""platform transformation,""security consultant,"or some fashionable remix of all four. They land on my profile expecting one thing, then quickly discover I'm not shaped exactly the way their internal template expected.

Good.

That's not me being difficult. That's me being precise.

I've spent enough years in enterprise delivery, cloud transformation, security integration, and operational recovery to know that keyword alignment is not the same thing as problem alignment. One is easy for search filters. The other is what actually helps organisations get unstuck.

I am not trying to be all things to all people

Let me save a few people some time.

I do not sell myself as a generic resource who can be dropped anywhere to make a slide deck prettier. I'm not especially interested in theatre disguised as transformation. I don't show up to sprinkle security vocabulary over unstable delivery systems and call it maturity. And I'm not the person to hire if the real mandate is to preserve dysfunction while using modern tooling to make it look intentional.

That may sound blunt, but operational reality is blunt.

What I do is work at the seam between software delivery, security, resilience, governance, and engineering culture. That seam is usually where the real trouble sits. Pipelines look automated but remain fragile. Controls exist but nobody trusts them. Teams ship fast in some places, crawl in others, and spend too much time negotiating exceptions because the system was never designed to make good decisions visible.

That's where I tend to be useful.

Why my profile may look different

If someone expects a pure-play specialist with a narrow lane and a tidy label, my profile may feel a bit inconvenient.

I'm not just interested in tools. I care how those tools alter behaviour. I care whether your CI/CD flow actually supports secure change, whether Infrastructure as Code is governed in a way that people can live with, whether secrets handling is embedded into workflows instead of patched in later, whether observability tells the truth, and whether auditability survives contact with delivery pressure.

That broader shape can confuse people who are still searching in nouns.

But most hard delivery problems are verbs.

Teams are waiting.
Controls are bypassed.
Incidents are repeating.
Pipelines are brittle.
Ownership is vague.
Risk acceptance is informal.
Evidence is scattered.
Engineers are tired.

You don't solve that with a keyword match. You solve it with someone who can see the system, name the trade-offs, and help people build a better operating model without pretending the constraints are optional.

What I actually do

I help organisations make delivery more secure, more governable, more resilient, and less exhausting.

That can mean shaping SecDevOps programmes that align engineering work with policy and risk expectations. It can mean hardening CI/CD with meaningful gates instead of decorative ones. It can mean defining practical control points around build provenance, artifact integrity, Infrastructure as Code review, secrets management, dependency hygiene, and deployment approvals. It can mean improving feedback loops so teams can see drift, exposure, failure patterns, and operational regressions early enough to do something useful about them.

Sometimes the work is strategic. Sometimes it's deeply hands-on. Most of the time it's both, because strategy without implementation is a very expensive form of optimism.

A typical engagement pattern might look something like this:

• review a handful of critical services rather than boiling the ocean
• map the current path from commit to production
• identify where security checks exist, where they fail, and where they're simply being ignored
• compare formal governance expectations with what teams actually do under pressure
• assess Infrastructure as Code practices for consistency, drift control, review quality, and traceability
• instrument observable signals around pipeline health, deployment friction, rework, exceptions, and incident recurrence
• redesign a few high-friction workflows so the secure path becomes the easier path
• create evidence that leaders, auditors, and engineers can all use without requiring three separate versions of reality

That kind of work fits well with focused baselining and early dashboards around a small set of critical services, with practical outputs in weeks rather than months [4].

What I do not do

I do not treat security as a compliance costume.

I do not believe governance should arrive as a late-stage committee ambush.

I do not think developers need more friction for the sake of appearing serious.

I do not confuse automation with judgment, nor dashboards with understanding.

And I do not believe a healthy engineering culture can be built on permanent exception handling, vague ownership, and silent resentment between teams.

Plenty of organisations are living like this already.They don't need more jargon. They need a clearer operating model.

The better-fit argument

So if someone finds my profile because a few keywords happen to line up, but then notices I don't present myself in the usual interchangeable format, that difference may actually be the point.

If you need someone to stay neatly inside a single box, I may not be your first choice.

If you need someone who can connect delivery practice, platform realities, governance obligations, security engineering, and team behaviour without losing the plot, then the profile starts to make more sense.

The benefit is not that I look different.The benefit is that I work across the places where the costly disconnects usually hide.

Those disconnects are rarely glamorous. They show up as approval bottlenecks, weak rollback habits, unenforced branching rules, unowned secrets, noisy scanners nobody trusts, inconsistent artifact promotion, audit panic, brittle infrastructure changes, and a lot of crossed fingers dressed up as process.

That's real work. That's where I live.

A practical closing thought

If you came across my profile expecting a neat buzzword match and found something a little broader, a little more opinionated, and a lot more operational, that is by design.

I'm not trying to look like every search result. I'm trying to be useful where delivery, security, and governance have to coexist in the real world.

And if your environment is feeling the strain between speed, safety, accountability, and developer sanity, it may be worth reading past the keywords. That is usually where the interesting conversation starts.

References
https://jpsoftworks.com/
https://jpsoftworks.com/blog
https://owasp.org/www-project-software-assurance-maturity-model/
https://slsa.dev/
https://www.nist.gov/cyberframework