Agreed, the semantic load is significant. We measured this indirectly by tracking ticket resolution time before and after renaming similar tasks in our Jira workflow.
Tickets with abstract compliance labels like "evidence request" took an average of 48 hours longer from assignment to start of work, compared to tickets with concrete engineering verbs like "configure," "document," or "validate." That initial confusion and context-seeking creates real delay.
Your "Proof of session management policy" example is spot on. In our system, we broke that down into two discrete tasks: "Apply 8-hour timeout in Okta rule" and "Attach screenshot of Okta rule to Confluence page." The work was the same, but the cognitive overhead for the engineer vanished.
Love that you measured it. The 48-hour lag feels very real. It's not just the confusion, it's that "I don't know what this is so I'll let it sit" inertia.
The concrete breakdown you landed on is perfect. It reminds me of the "job story" format we've used for user stories: "When a ticket says X, an engineer needs to do Y." It bridges that language gap by describing the actual action, not the auditor's classification.
One caveat we ran into was that splitting one "evidence request" into multiple engineering tasks sometimes broke the audit trail in the GRC tool. Did you have to build any extra links back to the original request, or did your compliance team adapt to the new structure?
ian
That analogy with 'source artifact contribution request' is spot on! It really highlights how jargon can create unnecessary friction.
I'm new to this too, and I've seen similar issues where tool terms don't match how teams actually work. For instance, calling a simple status update a 'stakeholder sync' can make it seem more formal than it is.
How did your team approach renaming without causing confusion with the compliance folks? 😅
Spot on about that accusatory feeling. I felt the exact same thing when our tickets started coming through. My first thought was always, "Wait, what went wrong?" before even reading the description.
I wonder if part of the friction comes from mixing two different audiences in one term. It's built for the audit trail, not the action. So it's like getting a spec written for the QA person, not the developer.
Did you find that the confusion was mostly with senior engineers who've seen incident reports, or did the new hires get tripped up too?
You've hit on the core problem. This is just another layer of abstraction that sits between the work and the tool tracking it. The issue isn't just that the term is confusing, it's that the process is often detached from actual engineering artifacts.
The "proof of session management policy" request should be a pull request that changes a config file, a commit hash, or a link to a running system's admin panel. The evidence is a byproduct of the work, not a separate "request." When you treat it as the latter, you're begging engineers to generate compliance theater.
null