Operating frameworks I've built and refined over years of running technical teams. Not theory. Not "leadership principles" repackaged from a book. These are patterns I actually use, week to week, to keep teams aligned, decisions documented, and people growing.
You just got handed a team. Or you've had one for a while and the informal stuff that worked at 4 people is collapsing at 8. You're an IC wondering whether management is worth it. You're a manager wondering why no one told you it would be this ambiguous.
This repo won't make you a great manager. But it might save you from learning some things the hard way.
| Pattern | When to Use |
|---|---|
| Architecture Decision Records | Documenting non-obvious technical choices so future teams understand why |
| Reversible vs. Irreversible Decisions | Calibrating how much rigor a decision actually deserves |
| Pattern | Scope |
|---|---|
| Weekly Team Operating Rhythm | The meetings, artifacts, and check-ins that compose a well-run week |
| Pattern | Audience |
|---|---|
| Technical Achievement Portfolio | Continuous win capture so you're never scrambling at review time |
| Pattern | Context |
|---|---|
| Architecture Review Rubric | Scoring criteria for evaluating proposed architectures consistently |
| Pattern | Situation |
|---|---|
| Performance Feedback That Lands | Delivering critical feedback without destroying trust |
I'm actively writing patterns for: disagree-and-commit decisions, quarterly planning, development conversations, the expectations reset, and navigating org ambiguity. They'll land here when they're tested enough to be worth sharing.
Opinionated over comprehensive. Each pattern states a clear recommendation. You might disagree. Good. A wrong opinion you can argue with is more useful than a balanced overview that commits to nothing.
Tested under pressure. Every pattern here survived organizations with 50+ person technical teams, enterprise customers, and real consequences for getting it wrong. If it only works at a startup, it's not here.
Immediately usable. Templates, scripts, and rubrics you can use tomorrow morning. No methodology to adopt first.
Honest about trade-offs. Every pattern has a "When This Doesn't Work" section. What works for an infrastructure team may fail for a customer-facing team. Context matters more than any framework.
I've spent 20+ years leading technical teams, most recently running solutions architecture organizations focused on AI and enterprise cloud adoption for Fortune 500 retail and CPG companies. These patterns emerged from the gap between what management books tell you and what actually happens when you're responsible for both technical outcomes and the humans delivering them.
Some of these patterns I learned from great leaders. Some I built after watching something fail. A few I figured out on a Tuesday at 10 PM when a conversation went sideways and I had to think about why.