⚙️ The GRC People Engineers Respect Most Have Never Shipped Code

Some of the GRC people I have most often seen engineers seek out have never shipped a line of production code. If you do not code daily, that should tell you the bar is closer than the "get technical" advice makes it sound.

They understand enough to delegate. They are amazing at building programs, creating bridges with other teams, asking critical tough questions and probing the direction to ensure it's been thought through properly.

I have argued before that being technical in GRC is local to the workflows you own. These people are technical in the way their company's GRC actually requires. The three scenes below are composites of people I have worked near, with the details changed.

She asked what share of the traffic it covered

A security team presents a control as done. The configuration is strict and every test has passed, so the status on the slide is green. The GRC lead in the room has never written a rule for the tool behind it.

She asks what share of the traffic the control applies to. The answer is most of it. The remainder is an older route, exempted at rollout, that still carries the partner integrations.

She holds strength and coverage as two separate questions, and she always asks the second. Coverage got its own line in the five metrics because a strict control tells you nothing about the traffic that never passes through it.

Afterward the engineers start bringing her designs earlier, because her question costs an afternoon in week one and a rebuild in week ten.

She asked three questions about a pipeline she could not build

A different GRC lead sits in a design review for an evidence pipeline. She could not build it and says so at the start. Then she asks three things: what happens when this check fails silently, who finds out, and what did we decide not to cover.

The engineers have answers for the first two. The third produces a list of four data sources that were left out on purpose and written down nowhere. The list goes into the design doc.

The first question would have caught the control from the debugger issue, a restore check that passed for eight quarters while it had no way to detect a failed restore.

Then she writes the definition of done in two lines. Every check reports its last successful run and has been shown to fail on a known-bad input, and a missed run pages a named owner. Every source left out is listed in the doc with the reason. She hands the build to an engineer, who owns it from there.

The bar she clears is telling whether the direction has been thought through. I call it the delegation bar, and you can clear it on a system you could never build yourself.

A question the room cannot answer sends the design back, and three answers become a definition of done an engineer can own.

She protected two calendars

A GRC leader watches the audit cycle grow every year until it takes the whole team. The testing of high-risk controls that no framework asks for keeps slipping to the next quarter.

She does not ask for headcount. She owns her team's calendar, so she ring-fences two people whose time the audit cannot touch. She has the two of them test those high-risk controls and walk their first findings over to the platform team, with a proposed fix attached to each and no ticket filed.

Within two quarters the platform team is asking those two to look at things before launch. Ring-fencing two calendars is a move high on the leverage ladder, where a program changes what gets attention instead of tuning a threshold. It takes knowing how her company allocates time. The audit has a deadline and an outside party attached, so it wins every calendar conflict until she takes two calendars out of the contest.

No with a reason, yes with a path

I wrote last month that these people earn respect by "saying no with a reason and yes with a path", and the table sets each one beside its lazy version as you would hear it in a review.

The reason has to change what the engineer does next and the path has to name a condition and an owner, which is the day-to-day form of turning obstacles into allies.

The two questions I asked about a warehouse

I sat in on a product brief where the data engineering team mapped out their warehouse infrastructure. I listened and sketched a rough diagram as they talked.

When they finished I asked two questions. How are RBAC and least privilege enforced at the ETL service account that writes into the warehouse, and how are they enforced at the BI tool that reads from it? Those were two trust boundaries I could not trace on my own diagram.

They paused, because they had not thought about either one yet. All I had done was listen and draw.

I code daily now, and the questions still do more of the work than the code.

The people behind those three scenes are still better than me at the parts that are not code. They prioritise ruthlessly, because they know what every decision costs and where their judgement is best used. They drive the work through risk and know what compliance is for. They also know when to be a security partner and when to push on the sales side so the CISO looks good.

Write down your last no

Write down the last no you gave and the reason you attached to it. If the reason would not change what the other person does next, it was a lazy no. You can still go back with a better one.

Then, before your next design review, write the three questions from the pipeline scene at the top of your notes. Ask them out loud, even when you think you know the answers, because asking is how you clear the delegation bar.

This is a career move, because people route work toward the person whose questions make the project smaller. I argued in What Comes After GRC Engineering that the market ran with the mechanics and left the job open, and this is that job.

The engineer whose project shrank after your question is the one who adds you to the next kickoff, and the kickoff is where the scope you care about is still cheap to change.

Try this week

• Write down the last no you gave and its reason. If the reason would not change what the other person does next, rewrite it.

• Before your next design review, put the three questions at the top of your notes: what happens when this fails silently, who finds out, what did we decide not to cover.