You celebrate Pi Day. I use ISO 8601. We are not the same.

Szescstopni

The Constraint You Won't Find on a Jira Board

• 🚧 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.
• 🧠 It applies the Theory of Constraints to engineering orgs: improving non-constraints may look productive, but it does not meaningfully improve overall throughput.
• 📋 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.
• 👀 Many visible bottlenecks, like code review or QA, are only symptoms. The root cause is often elsewhere in decision-making structures or organizational boundaries.
• 🙋 Leaders themselves can become the constraint when too many decisions depend on their permission rather than their unique expertise.
• ❓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.
• ⏳ The article stresses that most lost time sits in waiting, not doing, so teams should map total elapsed time, not just active work time.
• 🔓 Removing a policy constraint usually does more than speed up decisions. It also increases ownership, autonomy, and earlier problem surfacing across the team.
• 🔄 Fixing one constraint is not the end. The constraint will move, so leaders need to keep reviewing where work gets stuck and why.
• 📈 The core leadership lesson is to stop confusing busyness with throughput and instead ask whether value is actually flowing through the whole system.

Architectural debt is not just technical debt

• 🏗️ Architectural debt extends far beyond code — Enterprise architects must focus on three layers: application/infrastructure, business, and strategy, not just technical implementation details
• 🔧 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
• 🏢 Business layer debt creates operational blindspots — Poor documentation of ownership, stewardship, and interdepartmental processes leads to wrong assumptions and multiplied operational issues
• 📊 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
• 👀 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
• ⚔️ 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
• 📈 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

Advice for New Principal Tech ICs

• 🎭 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
• 🔄 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
• 🎯 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
• 💬 Communication Over Code — Success depends more on influence, alignment, and connecting the right people across large-scope projects involving multiple directors and VPs
• 🏆 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
• 📚 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
• 🎯 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
• 🔗 Dot Connector — Sometimes the most valuable thing is connecting teams who need work done with teams who've already done similar work
• 👥 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
• 🎁 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)
• 🚨 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
• 💭 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"
• ⚖️ 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
• 🎯 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
• 🏝️ Loneliness Factor — "You're part of all teams but also part of none"; build a network of peers for open conversations

Design Your Organization for the Conflicts You Want to Hear About

• 🏗️ 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
• 🎯 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"
• 💡 Value-add principle — Don't put department B under executive A unless that executive can genuinely add value to both functions, beyond just alignment
• 🚫 Empire building prevention — The value-add rule defeats executives who want bigger teams for resume purposes rather than genuine capability to manage them
• 🌍 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
• 📊 Mitigation strategies for scale — As organizations inevitably consolidate, use transparency culture, extended QBRs with second-level leaders, and robust reporting to maintain visibility
• 🔍 Ground truth preservation — Each organizational layer and combination insulates you further from reality — be intentional about which conflicts deserve your direct attention
• 👥 Flatten strategically — Create extended leadership teams beyond direct reports to maintain connection to key functional conflicts even as the org grows

We should all be using dependency cooldowns

• 🛡️ 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
• ⏰ 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)
• 🎯 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
• 💡 Implementation is trivially easy — tools like Dependabot and Renovate make it as simple as adding a few lines of config: cooldown: default-days: 7
• 🏢 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
• 🔧 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
• ⚖️ 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
• 🎪 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

That’s all for this week’s edition

I 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.

See you all next week 👋

Oh, and if someone forwarded this email to you, sign up if you found it useful 👇