IN PARTNERSHIP WITH

Leave Compliance Firefighting in 2025 🔥

Make 2026 the year of continuous trust. 

Drata automates the manual chaos so you can spend your time engineering—not extinguishing audit emergencies. Discover the power of continuous, automated control monitoring, real-time risk insights, and an AI-powered trust management platform that scales with your architecture.

CARD 003: SOFTWARE ENGINEER

You've collected Product Managers (who decide what gets built) and Security Engineers (who mitigate threats). Now meet Software Engineers - the people who actually build it.

This is the relationship that should be mostly invisible. If developers know your name, something's gone wrong.

Let's collect Card 003. 🎴

Table of Contents

• 🪪 Core Identity

• 💭 What They Actually Care About

• ⚡ How GRC Intersects Their World

• 📅 Key Milestones in Their Calendar

• 🤝 Critical Meetings They Run

• 🌐 Their Key Stakeholders

• 🏆 What Success Looks Like to Them

• 💬 How to Start the Conversation

• 🚩 Red Flags (When They'll Resist GRC)

• 🧠 Their Mindset & Philosophy

• 🗣️ The Language They Speak

• 🎴 Key Takeaways

🪪 Core Identity

Role: Software Engineer / Developer
Department: Engineering
Reports To: Engineering Manager
Key Metric: Code velocity, feature delivery, deployment frequency, code quality, sprint completion

💭 What They Actually Care About

• Shipping features that work and delight users - Code in production. Users happy.

• Flow state and minimal interruptions - Deep focus on coding. Every meeting costs 3 hours (30-min prep + 1-hour meeting + 90-min context switch recovery). Flow state is sacred. (See our Human API newsletter on respecting this)

• Code quality and technical excellence - Clean architecture, manageable technical debt. Not just fast, but right.

• Good tooling and fast CI/CD pipelines - Modern tech stack, automated processes. Slow tools kill productivity.

• Clear requirements, not ambiguous asks - Clear acceptance criteria. Unclear requirements create rework.

• Autonomy in HOW to solve problems - Freedom in technical approach. They control HOW to build, not WHAT to build (that's PM's domain).

GRC-Specific:

• Compliance that's invisible - Automated in pipeline, runs in <5 seconds, never manual work, zero meetings with GRC

⚡ How GRC Intersects Their World

GRC enters when compliance requirements land in CI/CD pipelines, when training appears on calendars, or when someone bypasses proper routing to ask developers for "quick compliance help." For most developers, GRC is invisible until it slows them down.

When GRC Becomes Their Problem

Scenario 1: Bypassing proper organisational routing

GRC bypassed proper routing and went direct to developer with compliance question instead of through Security Engineer, PM, or Engineering Manager. Developer interrupted flow state, lost 3 hours of productivity (context switch cost), and felt caught between helping GRC and following proper organisational structure.

Lesson: Never go direct to developers. Route through Security Engineer (technical context), Product Manager (prioritisation), or Engineering Manager (capacity). Going direct shows you don't understand how engineering organisations work and wastes expensive developer time.

Scenario 2: SDLC security controls without understanding company culture

GRC implemented security gates in CI/CD pipeline without Security Engineering team guidance. Didn't understand the company's organisational bias - was this an engineering-bias company (developers sacred), product-bias company (ship fast), regulatory-bias company (compliance first), or sales-bias company (revenue rules)?

Broke developer workflows. No cultural context.

In an engineering-bias company, you must work WITH developers, not impose on them. Developers bypassed controls, created "emergency" deployment processes, productivity cratered.

Lesson: Understand company culture before implementing controls. Engineering-bias companies require developer partnership. Product-bias companies need PM buy-in. Regulatory-bias companies can enforce top-down. Know which you're in. (Related: See our GRC Team Topologies newsletter on organisational models)

Scenario 3: Generic secure coding training instead of developer-specific

GRC mandated secure coding training: generic content, checkbox compliance exercise. Not customised to developers' languages (Python, React, Go) or frameworks. Didn't involve developers as design partners.

Result: Developers rushed through in 10 minutes, used AI to complete quizzes, zero retention, no behaviour change in how they write code. Expensive training investment with zero security improvement.

Lesson: Involve developers as design partners in compliance solutions. Customise training to their tech stack. Treat it as product with developers as users. Co-create, don't impose. (See our GRC as a Product newsletter)

📅 Key Milestones in Their Calendar

Developers don't think quarterly. They think in 2-week sprints:

• Sprint Planning (Day 1 of every 2 weeks): Backlog prioritised. GRC insight: Get requirements BEFORE planning, not during sprint.

• Sprint Execution (Days 2-10): Flow state. Coding. Reviews. GRC insight: NEVER interrupt. This is building time.

• Sprint Review/Retro (Days 11-14): Demo features, retrospective. GRC insight: Only time for feedback if specifically invited.

• Release Cadence: Weekly or bi-weekly deployments. GRC insight: Compliance gates must match this speed, not slow it down.

IN PARTNERSHIP WITH

The security leader’s playbook to GRC

Manual compliance work is costing your team time - and fueling burnout.

In this Drata and Tines guide, learn how to replace reactive compliance with continuous, automated GRC. Get workflows for evidence collection and audit prep, and best practices for building a resilient, proactive GRC program.

🤝 Critical Meetings They Run

Developers attend 90% fewer meetings than Product Managers:

Daily: 15-minute standup (sacred - status updates only, don't hijack for compliance)
Bi-weekly: Sprint planning, sprint review, retrospective
Monthly: Rare - maybe tech talks or architecture discussions
Never: Compliance meetings, audit discussions, GRC reviews

GRC Insight: Every meeting you add kills a fair bit of developer productivity. Never invite developers to GRC meetings. Work through Engineering Manager, Product Manager, or Security Engineer instead. This isn't disrespect - it's organisational efficiency and cost optimisation.

🌐 Their Key Stakeholders

Upstream: Engineering Manager (reports to, controls capacity), Tech Lead (technical direction), Product Manager (defines WHAT to build)

Downstream: End users (who use what they build)

Peers: Other developers (code reviews), QA engineers, DevOps/SRE (deployment)

Critical Note: Developers are the LEAST connected to GRC of any stakeholder. PMs, Security Engineers, and EMs handle GRC interactions. Developers should rarely interact with GRC directly. This protects their expensive productivity.

🏆 What Success Looks Like to Them

Short-term (this sprint): Ship committed features. Zero blockers. Features in production. No 3am pages.

Medium-term (this year): Deliver high-impact features. Improve code quality. Advance technical skills. Maybe Tech Lead or Senior Engineer.

Long-term (career): Promoted to Senior, Staff, or Principal Engineer. Recognised for technical excellence and elegant solutions. Maybe Engineering Manager track. Work on genuinely interesting technical problems. Build things that matter.

Note: Unlike PM (business outcomes) or Security (threat reduction), developers measure success in working code shipped and problems solved elegantly.

💬 How to Start the Conversation

The Routing Principle (Use This 95% of the Time)

Don't go to developers. Route through Security Engineer (technical), Product Manager (prioritisation), or Engineering Manager (capacity).

When Direct Engagement Makes Sense (5% of time):

For Co-Creating Compliance Automation: "I'm building compliance automation in your CI/CD pipeline and need 30 minutes of technical input on architecture. One-time session to get it right, then runs invisibly forever. Schedule when it doesn't interrupt your flow?"

For UX Testing Your Processes: "I want to test our compliance workflow to ensure it's frictionless for developers. Can you run through this and tell me where it creates friction? I'll actually fix what you identify as painful."

For Design Partnership: "Selecting secure coding training platform. Need 2-3 developers as design partners to ensure it's relevant to your tech stack (React, Python, Go). 30-minute session, your input shapes what gets purchased."

Frame GRC As

• Invisible automation that respects their expertise: "Runs in 2 seconds in your pipeline. How can we satisfy this control without impacting velocity?"

Avoid Saying:

• ❌ Going direct when you should route through Security/PM/EM

• ❌ "Can you attend this compliance training session?"

• ❌ "We need you to fill out this security questionnaire"

• ❌ "Compliance requires you to document..." (route through EM)

• ❌ "This will only take 15 minutes" (it will take an hour with context switching)

🚩 Red Flags (When They'll Resist GRC)

Trigger #1: Bypassing proper routing

Going direct creates context switching and bypasses organisational structure.

How to defuse: Route through Security/PM/EM.

Trigger #2: Compliance slowing their workflow

Pipeline friction without understanding company culture.

How to defuse: Understand company bias. Test with one team first.

Trigger #3: Generic training without customisation

Generic training with no customisation.

How to defuse: Involve developers as design partners.

🧠 Their Mindset & Philosophy

Core Beliefs

• Ship working code

• flow state is sacred

• automate everything possible

• code quality matters

• clear requirements essential

• autonomy in technical decisions.

Frustrations

• Context switching and excessive meetings

• unclear requirements

• slow/broken CI/CD pipelines

• manual processes

• compliance slowing development velocity.

Motivations

• Users loving what they built

• solving interesting technical challenges

• modern tech stack

• continuous learning and technical growth

• measurable impact through code quality.

🗣️ The Language They Speak

Phrases They Use:

• "This breaks the build" (deployment blocker)

• "What's the acceptance criteria?" (need clear requirements)

• "Can we automate this in the pipeline?" (automation-first mindset)

• "This adds technical debt" (future maintenance cost)

• "How long until this ships?" (velocity focus)

• "What's the actual requirement?" (want specifics, not vague compliance-speak)

Translation Guide:

❌ "Developers need mandatory secure coding training for annual compliance"
✅ "Can we co-design training specific to React and Python (your stack)? Need 2 developers as design partners for tool selection. Want training that actually improves your code security, not checkbox exercise. 10-minute async modules, zero calendar time."

❌ "We need to add security compliance controls to your CI/CD pipeline"
✅ "Can we add automated security check that runs in <5 seconds without slowing your build? Test with one team first, iterate based on your feedback, prove it doesn't impact velocity before rolling out."

❌ "Can you document this code architecture for the compliance audit?"
✅ "Can we auto-generate architecture docs from your code comments and existing diagrams? Zero manual work, runs in pipeline, updates automatically when you change code."

❌ "All developers must attend quarterly security awareness training session"
✅ "Built async 10-minute modules specific to your tech stack (SQL injection in your Python Flask app). Complete during downtime, no meetings, no calendar interruption. Need your feedback: is this actually useful?"

❌ "We need you to help fill out this security questionnaire about the application architecture"
✅ "Security Engineer and PM are handling this. Just need 5-minute async Slack response to 3 technical questions about authentication flow. No meetings, no forms, no spreadsheets."

🎴 Key Takeaways

• Route through intermediaries, never direct to developers - use Security Engineer (technical context), Product Manager (prioritisation), or Engineering Manager (capacity). Direct engagement wastes 3 hours per interaction through context switching.

• Understand company bias before implementing controls - engineering-bias companies require developer partnership, not top-down enforcement. Pipeline speed is sacred in engineering-first cultures.

• Involve developers as design partners in compliance solutions - they're problem-solvers with deep technical expertise. Co-create training, tooling, and automation instead of imposing generic compliance theatre.

That’s all for this week’s issue, folks!

If you enjoyed it, you might also enjoy:

• My spicier takes on LinkedIn [/in/ayoubfandi]

• Listening to the GRC Engineer Podcast 

  • Spotify

  • Youtube

  • Apple Podcasts

See you next week!