{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigijrndd2ht7l3scauaknt2s56jlrx7of5hml2qd4vixiiqvyctqq",
    "uri": "at://did:plc:wpq5klc63onhz6zbwaigzzt5/app.bsky.feed.post/3mjgzxekj34x2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreiebhoupe43u44j23drcsqsoxldnves7qgtji2msdehg75r5hpik7u"
    },
    "mimeType": "image/png",
    "size": 3424059
  },
  "description": "Weekly, hand-picked engineering leadership nuggets of wisdom",
  "path": "/the-managers-guide-136/",
  "publishedAt": "2026-04-14T09:11:00.000Z",
  "site": "https://the.managers.guide",
  "tags": [
    "Szescstopni",
    "The Constraint You Won't Find on a Jira Board",
    "Architectural debt is not just technical debt",
    "Advice for New Principal Tech ICs",
    "Design Your Organization for the Conflicts You Want to Hear About",
    "We should all be using dependency cooldowns"
  ],
  "textContent": "> You celebrate Pi Day. I use ISO 8601. We are not the same.\n>\n> Szescstopni\n\n* * *\n\n### The Constraint You Won't Find on a Jira Board\n\n  * 🚧 The article argues that the biggest delivery constraint is often **not the Jira bottleneck** , but hidden approval chains, unwritten rules, and leadership habits that slow work down.\n  * 🧠 It applies the **Theory of Constraints** to engineering orgs: improving non-constraints may look productive, but it does not meaningfully improve overall throughput.\n  * 📋 A major focus is on **policy constraints** such as required sign-offs, escalation paths, and outdated rules that keep decisions from happening at team speed.\n  * 👀 Many visible bottlenecks, like code review or QA, are only **symptoms**. The root cause is often elsewhere in decision-making structures or organizational boundaries.\n  * 🙋 Leaders themselves can become the constraint when too many decisions depend on their permission rather than their unique expertise.\n  * ❓A practical way to find the real constraint is to ask **“why can’t we just…”** at every point of friction until you uncover the person, rule, or process blocking flow.\n  * ⏳ The article stresses that most lost time sits in **waiting** , not doing, so teams should map total elapsed time, not just active work time.\n  * 🔓 Removing a policy constraint usually does more than speed up decisions. It also increases **ownership, autonomy, and earlier problem surfacing** across the team.\n  * 🔄 Fixing one constraint is not the end. The constraint will **move** , so leaders need to keep reviewing where work gets stuck and why.\n  * 📈 The core leadership lesson is to stop confusing **busyness with throughput** and instead ask whether value is actually flowing through the whole system.\n\n\n\n### Architectural debt is not just technical debt\n\n  * 🏗️ **Architectural debt extends far beyond code** — Enterprise architects must focus on three layers: application/infrastructure, business, and strategy, not just technical implementation details\n  * 🔧 **Application layer focus shifts at enterprise scale** — Instead of worrying about code structure, EAs should concentrate on integration patterns, system overlap elimination, and vendor lock-in balance across hundreds of applications\n  * 🏢 **Business layer debt creates operational blindspots** — Poor documentation of ownership, stewardship, and interdepartmental processes leads to wrong assumptions and multiplied operational issues\n  * 📊 **Strategy layer mistakes have massive long-term impact** — Mis-defined business capabilities or outdated capability maps can derail 3-5 year transformation strategies and make bad decisions look appealing\n  * 👀 **EAs have unique advantages for debt identification** — Unlike developers, enterprise architects have time, visibility, and access to leadership to flag architectural debt through dashboards and presentations\n  * ⚔️ **Battle selection is crucial** — Architectural debt should be tolerated more in innovation systems versus core systems of record, and EAs must have bandwidth to actually fix flagged issues\n  * 📈 **Data-driven debt cases work best** — Building compelling arguments requires AS-IS/TO-BE comparisons, business cases showing improvement benefits, and clear risk assessments of inaction\n\n\n\n### Advice for New Principal Tech ICs\n\n  * 🎭 **Different Principal Flavors** — Some dive deep in one space while others excel at horizontal influence; find the flavor that plays to your strengths rather than trying to be everything to everyone\n  * 🔄 **Role Reversal** — The work that made you successful before (like coding) becomes the side task; your core role shifts to technical vision, design feedback, and making everyone more effective\n  * 🎯 **Part-Time Everything** — You become part-time PM, designer, engineer, scientist, QA, hiring manager — \"nothing is not your job\" due to your high judgment and broad perspective\n  * 💬 **Communication Over Code** — Success depends more on influence, alignment, and connecting the right people across large-scope projects involving multiple directors and VPs\n  * 🏆 **Being Right Isn't Enough** — You must convince others you're right AND convince them to care enough to act; focus on building momentum and getting ideas over the finish line\n  * 📚 **Teaching the Org** — A big part of the work involves teaching organizations to value things they don't currently care about; expect a ~30% success rate on pitched ideas\n  * 🎯 **Unique Work Category** — Focus on work that \"won't happen without you\" — usually at the intersection of what you care about most and what you're exceptional at\n  * 🔗 **Dot Connector** — Sometimes the most valuable thing is connecting teams who need work done with teams who've already done similar work\n  * 👥 **Scale Through Others** — Spend 1-2 hours per week with someone to enable 40 hours of work under your insights; focus on building others who can take your place\n  * 🎁 **Give Away the Work** — Transition from involving others in work to making the work theirs; let them take approaches you wouldn't take (unless it's high-risk)\n  * 🚨 **Guard Your Time** — Your entire week can fill with reviews, escalations, and meetings; learn to push back or you'll have no time for ideas you really care about\n  * 💭 **Schedule Think Time** — \"You need time to think. If you are going from meeting to meeting, you can't process things and can't look ahead\"\n  * ⚖️ **Credibility Comes With Responsibility** — People may read too much into your casual comments; be clear about what you know, don't know, and what you're simply commenting on\n  * 🎯 **Critical Path Paradox** — To get to principal, you put yourself on the critical path; to be effective as principal, you actively remove yourself from it\n  * 🏝️ **Loneliness Factor** — \"You're part of all teams but also part of none\"; build a network of peers for open conversations\n\n\n\n### Design Your Organization for the Conflicts You Want to Hear About\n\n  * 🏗️ **Design for valuable conflicts** — Instead of reducing span of control, design your organization to surface the conflicts you most need to hear about as CEO\n  * 🎯 **Strategic conflict exposure** — When you combine departments (like engineering under product, or marketing under sales), you silence important strategic tensions that get resolved \"in the family\"\n  * 💡 **Value-add principle** — Don't put department B under executive A unless that executive can genuinely add value to both functions, beyond just alignment\n  * 🚫 **Empire building prevention** — The value-add rule defeats executives who want bigger teams for resume purposes rather than genuine capability to manage them\n  * 🌍 **Geographic expansion reality check** — Just because someone runs US sales doesn't mean they can add value to European operations — ask hard questions about passports, language skills, and regional networks\n  * 📊 **Mitigation strategies for scale** — As organizations inevitably consolidate, use transparency culture, extended QBRs with second-level leaders, and robust reporting to maintain visibility\n  * 🔍 **Ground truth preservation** — Each organizational layer and combination insulates you further from reality — be intentional about which conflicts deserve your direct attention\n  * 👥 **Flatten strategically** — Create extended leadership teams beyond direct reports to maintain connection to key functional conflicts even as the org grows\n\n\n\n### We should all be using dependency cooldowns\n\n  * 🛡️ **Supply chain attacks follow a predictable pattern** — attackers compromise popular open source projects and have limited windows of opportunity (typically hours to days) once they go public\n  * ⏰ **Most attacks have very short exploitation windows** — analysis of 10 recent attacks shows 8/10 had windows under a week, with many lasting just hours (Ultralytics phase 2: 1 hour, rspack: 1 hour)\n  * 🎯 **Cooldowns are a simple, effective defense** — waiting 7-14 days before updating dependencies would have prevented 80-90% of recent supply chain attacks at zero cost\n  * 💡 **Implementation is trivially easy** — tools like Dependabot and Renovate make it as simple as adding a few lines of config: `cooldown: default-days: 7`\n  * 🏢 **Vendors are incentivized to act quickly** — security companies scan for compromises and report them rapidly (within hours/days) because it demonstrates their value, creating a natural detection window\n  * 🔧 **Package managers should adopt cooldowns natively** — while Dependabot/Renovate work well, having cooldowns built directly into package managers (like pnpm's `minimumReleaseAge`) would be even more effective\n  * ⚖️ **Not a silver bullet, but high ROI** — cooldowns won't stop all attackers but offer massive risk reduction for minimal effort, addressing the \"80/20\" of supply chain security\n  * 🎪 **Supply chain security is overhyped by vendors** — dozens of companies have financial incentives to amplify fears, but simple techniques like cooldowns can mitigate most real-world risks\n\n\n\n* * *\n\n# That’s all for this week’s edition\n\nI hope you liked it, and you’ve learned something — if you did, don’t forget to give a thumbs-up, add your thoughts as comments, and share this issue with your friends and network.\n\nSee you all next week 👋\n\nOh, and if someone forwarded this email to you, sign up if you found it useful 👇\n\n## Sign up for The Managers' Guide\n\nYour guide to engineering leadership\n\nSubscribe\n\nEmail sent! Check your inbox to complete your signup.\n\nNo spam. Unsubscribe anytime.",
  "title": "The Managers' Guide № 136"
}