How We Built Privacy Into Architecture, Not Policy

The Privacy Lie

Most "privacy-focused" developer tools are lying to you.

They claim to protect individual data, but dig into the architecture and you'll find:

• A settings toggle to "enable manager visibility"
• An admin panel that can query any user's data
• A leaderboard feature that's "disabled by default"
• Database queries that could trivially produce individual rankings

The protection is policy: "We promise managers won't access individual data." But policies can be changed. Settings can be toggled. Promises can be broken.

When pressure mounts (layoffs, budget cuts, executive curiosity), policy evaporates. The data is there. Someone will access it. And once they do, trust dies.

We built something different.

Privacy as Architecture

Our approach treats privacy as architecture, not policy. The system is designed so that producing individual comparison data requires building new features, not flipping a setting.

Here's what that means in practice:

Individual Profiles Are Isolated

There is no "get all developer scores" endpoint. The API doesn't support it. No screen renders it. The concept doesn't exist in the product.

When a developer views their effectiveness profile, they request their own data—authenticated by their own identity. When a manager views team aggregates, they receive team-level statistics that don't contain individual-level data.

This isn't access control bolted onto a data model built for rankings. Rankings were never modeled.

No Leaderboards Exist

Leaderboards aren't a feature we disabled. They're a feature that was never built.

To create a leaderboard, you'd need to:

1. Add new database queries that don't exist
2. Create new API endpoints that don't exist
3. Build new UI components that don't exist
4. Handle new edge cases that we've never considered

This is deliberate product work—not a settings toggle someone can flip under pressure. Even our own team can't turn on rankings; we'd have to build them.

Team Scores Aren't Rollups of Individual Scores

When a manager views "team effectiveness," they're not seeing an average of individual scores. Team scores are computed from sprint-level team data: story points completed, PRs merged, bugs encountered, retro participation.

The difference matters. If team scores were member averages, individual scores would have to flow through the aggregation pipeline, where they could be logged, exported, or leaked. In our pipeline, they were never an input.

There's no "team_member_rankings" table waiting to be queried. There's a calculation that produces team-level statistics without ever materializing individual comparisons.

Technical Deep Dive

Here's concretely how this works.

Data Model: Scoped by Identity

Developer effectiveness snapshots are stored in DynamoDB with a single developer's history as the partition:

// Developer effectiveness snapshot entity
{
  PK: "ORG#org_123#DEV#user_456",  // Partition: one developer's history
  SK: "SNAPSHOT#2026-06-30",        // Sort key: the snapshot date
  dimensions: {
    delivery: 78,
    flow: 82,
    quality: 85,
    // ...
  }
}

To query your own effectiveness, the key is built from your authenticated identity. There's no query pattern that retrieves "all effectiveness snapshots for team X."

The data exists, but the access paths don't.

API Layer: Scoped Endpoints

Our API endpoints are designed for their intended use cases—not for flexibility that enables surveillance:

// This endpoint exists
GET /api/me/effectiveness
// Returns: your own effectiveness profile

// This endpoint exists
GET /api/teams/{teamId}/effectiveness
// Returns: aggregated team metrics (no individual data)

// This endpoint does NOT exist
GET /api/teams/{teamId}/effectiveness/members
// Would return: individual member scores
// We never built it.

When a new feature request comes in, we ask: "Does this endpoint enable individual comparison?" If yes, we design it differently or don't build it.

Team Metrics: Computed From Team Data

The team effectiveness calculation never reads individual profiles. Its input is sprint-level team data extracted from retro data snapshots:

// Team effectiveness is computed from sprint-level team data.
// Individual profiles are not read anywhere in this path.
const sprintData = extractTeamSprintDataFromSnapshots(snapshots, team);

const effectiveness = calculateTeamEffectiveness(
  team.id,
  team.name,
  orgId,
  deduplicate(sprintData),
);
// Result: team-level dimensions only. There are no per-member
// scores to strip out, because they were never part of the input.

The calculation's inputs are things like story points completed, PRs merged, and bugs encountered per sprint. What managers see can't leak individual scores, because individual scores were never part of the computation.

Why Privacy Enables Accuracy

This isn't just about respecting developers—though it is. It's about getting accurate data.

Goodhart's Law in Action

The moment developers know they're being ranked, their behavior changes. They optimize for the metric rather than the outcome. They game what can be gamed. They hide what makes them look bad.

If your PR review score affects your standing, you'll rubber-stamp PRs to boost your volume. If your delivery score is visible to management, you'll ship fast and fix later. The data becomes unreliable because it's measuring performance, not work.

Trust Enables Honesty

When developers trust that their individual data is private, they engage honestly with the system.

In a surveillance system, a developer with declining quality scores hides the problem, games the metric, or stops engaging. In a trusted system, the same developer actually investigates why, tries improvements, and uses the feedback.

The same data, treated differently, produces opposite outcomes.

Research Supports This

Studies consistently show that surveillance reduces productivity, creativity, and quality. Workers under monitoring:

• Take fewer risks (avoiding the visible failures that often precede innovation)
• Focus on appearances over substance
• Experience higher stress and lower satisfaction
• Leave for less-monitored environments when possible

Privacy isn't just ethical—it's pragmatic. You get better data from trusted systems than from surveilled ones.

Patterns You Can Adopt

Whether you're building internal tooling or a product, these patterns apply:

Pattern 1: Design Access Paths First

Before building your data model, decide: "Who should be able to access what?" Then design the model so those are the only access paths.

If managers shouldn't see individual metrics, don't build a query that could produce them. It's easier to not build something than to build it and lock it down.

Pattern 2: Never Materialize Comparisons

Store only the aggregate level you intend to show. This means:

• No "rankings" table that could be dumped or exported
• No per-person rollups a future report could join against
• Aggregates computed from data that never contained individual scores

Yes, this constrains what you can build later. It's worth it.

Pattern 3: Make Privacy Observable

Users should be able to verify what's visible to whom. In our UI, the developer's profile states plainly what it is and isn't: private to you, not a performance rating, not used for compensation decisions, not visible to managers unless you share it.

Privacy that requires trust in documentation is weak. Privacy that's visible in the product is strong.

Pattern 4: Audit Privacy-Impacting Changes

When evaluating feature requests, explicitly ask: "Does this change what's visible to whom?"

New dashboard for managers? What data does it show? New export feature? What does it export? New report? Who sees it?

Make privacy review part of your feature process, not an afterthought.

What Can Managers Actually See?

Managers see team-level aggregates only: a 0-100 team health score, dimension averages, trends, and anomalies. Individual scores, rankings, and per-person trends don't exist in any view.

Managers CAN See:

Managers CANNOT See:

This creates a useful constraint: managers must focus on systemic improvements, not individual targeting.

When the team's quality score drops, the manager can't identify who's responsible—so they're forced to investigate process, environment, and team-level factors. That's usually where the actual problem lies anyway.

Optional Sharing: Developer-Controlled

We mentioned that individual profiles are private by default. But developers can optionally share their data with their manager for 1:1 coaching.

Two properties matter here. Sharing is an explicit opt-in the developer initiates, not a default or a setting the manager can flip. And it's revocable: the developer can withdraw visibility at any time.

The asymmetry is intentional. The developer controls their data. The manager accesses it only by invitation.

This enables coaching without surveillance. A developer struggling with flow metrics might share their data to get help—knowing they can unshare if the relationship changes.

The Business Case for Privacy

Privacy-as-architecture isn't just ethical. It's good business.

Better Retention

Top engineers have options. They leave environments that surveil them for environments that trust them. By building privacy into architecture, we help companies retain talent.

Better Data

Surveillance corrupts data. Privacy enables honest engagement. The metrics you get from a trusted system are more reliable than those from a surveilled one.

Defensible Position

When regulators, journalists, or employees ask about surveillance, there's a big difference between "we have policies" and "we architecturally cannot surveil."

GDPR, CCPA, and similar regulations are increasing pressure on employee monitoring. Privacy-as-architecture is ahead of where regulation is going.

Trust Preservation

Engineering cultures built on trust outperform those built on control. Privacy is how you signal trust—and building it into architecture signals commitment.

The Path Forward

If you're building tools that handle individual data (developer metrics, performance data, anything sensitive), consider this:

1. Policy isn't enough. If the system can produce surveillance, eventually someone will use it that way.

2. Design for the access patterns you want. Don't build flexibility you'll need to lock down.

3. Make privacy visible. Users should be able to see exactly what's shared with whom.

4. Accept the constraints. Privacy-as-architecture means some features are hard to build. That's a feature, not a bug.

We built Simyl Flow this way because we believe trust enables improvement. Surveillance destroys both.