Welcome back to the weekly newsletter! Lots to get into this week, but first some thoughts on something rattling around in my noggin; perceived complexity.
I once had a non-technical leader ask me about someone hiding behind “perceived complexity” in a project we were working on. They worried that the project seemed to have stalled and we would miss a significant milestone, putting the broader project at risk. Their interpretation was that the engineers working on a primary workstream were dragging their feet, obfuscating to make it seem like they were working hard without hardly working.
The question inside the question was fair, “this feels behind, but I don’t know enough to help, what can we do?” The way it came out was much more pointed and less empathetic to all aspects of the milestone’s complexity. It was a core system that was being rewritten to facilitate a major migration, all while making sure the company didn’t accidentally stall out in the process.
I’m sure this is not a foreign question for engineering leaders. We’re dealing with stakeholders who don’t understand the underpinnings of the broader systems, and it’s hard to know how granular to explain. Here are a few things I’ve found helpful over the years (at least more helpful than asking them to write it themselves).
Show the work. Linear (my favorite ❤️) or Jira are two systems great at showing high-level data and breakdowns of work. I’ve written before about how velocity can be deceiving, so report out with a filtered view or an explanation of shifts. If nothing else, showing your work makes visible the chunks into which your team has broken the larger project. The benefit of charts is that you can see the ebb and flow of interruptive work (additions to scope) and the progression of work because of it.
Be objective about trade-offs. Something like, “I hear you saying that you are concerned about the completion of this piece of work, if we are able to drop X and Y, we can regain focus on Z.” Removing the emotion and focusing on what’s in the way of potentially completing Z can shift the focus of the stakeholder from defensive to advocate, bulldozing everything that is not Z out of your path.
Show diagrams. This is my go-to lately. Pointing at flow charts and architecture diagrams has been much easier than talking theory or writing out large documents. The diagram doesn’t even need to be high fidelity, it can be a generalization to get the point across. Having this tangible artifact can go a long way.
Build the trust bridge. The hope is that this is something you’ve worked up to already. In other experiences, I’ve had bosses ask “Hartley, should I be worried about this?” which led to solid, supportive conversation. From there, they trusted I would get the job done, as I had proven many times in the past. If you’re not at that point, have the hard conversation and find out how best to build trust for future situations.
Rarely do engineers drag their feet intentionally. Most are well-meaning and get enjoyment out of finishing complex projects. To assume they are hiding behind perceived complexity is to believe they do not desire to do well in their craft.
In moments of doubt, clarity is your best ally. The more we can demystify the work through visibility, honest trade-off conversations, and simple diagrams, the less room there is for misinterpretation. Stakeholders don’t need every technical detail, but they do need to feel confident that progress is real and purposeful. Our job isn’t just to lead the work, it’s to make it digestible. The hope being that, over time, we all need less TUMS.
Now, onto the links I found interesting this week.
🧭 Remote Work & Leadership That Scales
Remote Teams Need Systems, Not Surveillance
Micromanagement often shows up dressed as “visibility.” This piece argues that what remote teams really need is better systems, not tools that track every keystroke. Fits nicely into the above, no?
Remote Excellence Guide
More on trust! A structured, practical handbook for high-performing remote teams. It’s full of principles and templates you can actually use.
🏛️ Power, Privilege & the Toligarchs
Rise of the Toligarchs – Scott Galloway
The new power players aren’t politicians, they’re tech-native thought leaders. Prof G’s take on the rise of tol-igarchs is sharp, timely, and uncomfortable in all the right ways.
Watch: The Rise of the Toligarchs
The written piece is strong, but the video version is classic Galloway: data-backed, unfiltered, and genuinely insightful.
Bond Capital’s TAI Report
Mary Meeker’s latest breakdown on the state of AI, filled with data, perspective, and insight on what’s really next after the hype.
🛠 Engineering Culture & Career Moves
10 Years of Engineering Ladders – Camille Fournier
A decade later, Camille’s framework for IC and management growth still holds up—and this reflection shows why transparency and clarity matter more than ever.
The Engineering Manager Archetypes
Are you the Architect, the Catalyst, or the Fixer? This archetype model helps you better understand your strengths and where you might need backup.
⚙️ Quick Hits
Company Boards Pressuring CEOs to Replace IT with AI
The pressure is real, and boards are asking hard questions about AI-first orgs.
What Nobody Tells Devs About Docs – PostHog
A love letter to documentation that doesn’t suck. If your devs dread writing docs, start here.
100 AI POVs from Experts – Section AI
A goldmine of mini-perspectives from people shaping the future of AI.
9 of Anthropics best guides
All free in Anthropic Academy
Your Privacy Guide to AI Chatbots
Section AI offers practical advice to keep you and your team safe while using chatbots, from toggling off model training to being thoughtful about prompts.
Want more like this each week?
Hit subscribe or reply to let me know what themes you want more of: AI, leadership, systems thinking, team health, you name it.