How should we control access to user data?
Work on matching format from LLM Adoption Strategy.
project starling is a great example of the roles
This is an exploratory, draft chapter for a book on engineering strategy that I’m brainstorming in #eng-strategy-book. As such, some of the links go to other draft chapters, both published drafts and very early, unpublished drafts.
Reading this document
To apply this strategy, start at the top with Policy. To understand the thinking behind this strategy, read sections in reserve order, starting with Explore, then Diagnose and so on. Relative to the default structure, this document has been refactored in two ways to improve readability: first, Operation has been folded into Policy; second, Refine has been embedded in Diagnose.
More detail on this structure in Making a readable Engineering Strategy document.
Policy
- think of this as a user-facing product – how would this need to work if customers could see access and the rationales behind that access?
- everyone should be better after this, including our users and the teams providing rationales, not a security win
Refine
This strategy made heavy use of Strategy testing:
- weekly meeting with involved participants
- “broad church”
- sponsoring executive joined <– sponsor
- highly engaged guide for whom this was their top priority and able to drop all other projects to make space for this one
- took over one team entirely to implement work
- also partially took over several other teams
- significant work upfront to align with executive team to pre-authorize time allocation from teams / disruptions to roadmaps
- identified clear metric, and had to do a lot of instrumentation to get there
- created slack channel that showed activity, especially legacy activity to see where gaps were, including sponsor and guide both being in channel and asking about issues – almost all errors in understanding and implementation were quickly visible in either the metrics data or the channel showing non-compliance
- spent about 3 months in active refinement before finalizing the approach
Diagnose
…
Explore
…