Author: Spyros Kalaitzis

  • When LLMs help humans understand themselves

    When LLMs help humans understand themselves

    Yesterday I had a profound experience.

    It started with a small question: what the heck do I stand for as a leader?

    Like everyone else having an idkfa moment these days, I decided to test my principles using an LLM and the collective wisdom of people that have thought about this for much longer than I have (and without the crutch of AIs).

    Cue our panel of experts:

    1. Peter Drucker – Management pioneer who developed foundational concepts like management by objectives and knowledge work
    2. Simon Sinek – Known for the “Start With Why” framework and leadership that inspires action
    3. Brené Brown – Research professor specializing in courage, vulnerability, and empathy in leadership
    4. Jim Collins – Author of “Good to Great” who researches what transforms companies from average to excellent
    5. Daniel Goleman – Pioneered emotional intelligence application in leadership effectiveness
    6. John C. Maxwell – Leadership expert behind “The 21 Irrefutable Laws of Leadership”
    7. Patrick Lencioni – Organizational health expert focused on team dynamics and leadership clarity
    8. Adam Grant – Organizational psychologist specializing in originality, motivation, and meaning
    9. Amy Edmondson – Harvard professor known for psychological safety research in high-performing teams
    10. Marshall Goldsmith – Executive coach focusing on behavioral changes that drive leadership success

    Their mission, should the AI role-playing as them was to accept it, was to give me a series of questions that would help me articulate my authentic leadership approach.

    Starting with Peter Drucker, what questions would he ask me if he was guiding me through this process? Have the next expert review and iterate on the previous one’s answer, until they’ve all contributed and we’ve reached a final set of questions that would allow me to distill my philosophy in one paragraph.

    And so they did.

    When I asked the gang to review my answers, a particular comment stood out:

    Simon Sinek would commend your purpose-centered approach but might challenge you to articulate why this purpose matters to you personally to make it even more compelling.

    (the two books of Simon siting at my bookshelf, still unread, gave me disapproving looks)

    Out of curiosity, and a bit of guilt, I pulled on that thread:

    Ask Sinek to guide me through this via a dialog where he asks me a question, I respond, and then he considers my answer and moves to his next question. This dialog should continue until we’ve succeeded in articulating why this purpose matters to me personally.

    This journey you’ll have to experience for yourself, trust me.

    As for where I ended up, see the description in my profile.

    In the meantime, I’ve got some reading to do 😉

    references:

    Photo by Yosef Futsum on Unsplash

  • AT THE MOUNTAINS OF UNCERTAINTY

    AT THE MOUNTAINS OF UNCERTAINTY

    If you are distressed by anything external, the pain is not due to the thing itself, but to your estimate of it; and this you have the power to revoke at any moment.

    Marcus Aurelius

    Your eyes are locked on the screen. You know this isn’t real, but to your body it may as well be… Thankfully, the film is about to end. Now, if only your amygdala knew this.

    When you can’t see what’s hiding in the dark, your mind imagines the worst. Fleeting glimpses of something horrible. But this hidden terror, could be just a cat rustling through the bushes.

    Any monster, once revealed, loses some of its power. Film directors use this to play with the senses. They don’t show the threat. The keep us guessing, building the tension continuously.
    This works because fear of the unknown is hardwired in all of us. A long time ago, staying alive often meant not finding out what that sound was.

    No plan survives first contact with the enemy.

    Helmuth von Moltke the Elder

    In unknown situations, our survival instincts kick in. We try to gain control to feel safe. But that’s the flaw in our plans: we can’t control everything.

    Old models, like Waterfall, assume everything is known from the start. That we can see the whole path from the top of the hill to the bottom. Real life, especially if in complex domains, rarely works that way.

    This is why “Responding to change over following a plan” is so powerful. It spins the old assumption on its head. We need to accept that we can’t know everything, and move forward anyway.

    Courage is not the absence of fear. It’s the ability to act despite it.

    Being brave doesn’t mean we should jump head first without checking. We need to be smart, removing the risks by not leaving dark places that “monsters” can hide in. And short iterations are great at doing that. We either deliver, or find out why we didn’t. The quicker we reach one of these outcomes, the better we can prepare for the next one.

    After all, we’re here to solve a problem, not to just put some pixels on a screen.

    Ask:

    • How important is this problem to solve?
    • What happens if we don’t?
    • How much time are we willing to spend on this? A week? A year?

    Parkinson’s law says:

    “Work expands to fill the time available for its completion.”

    Which can also be used to our benefit. If we only have 2 days to build a shelter, we should think be thinking of huts, not castles.

    Yes, a castle would be amazing. But what’s the point of how many fireplaces it’s going to have, if we can’t deliver it in the first place? (and this assumes that we actually know how to build a castle already)

    So start with something small. Test the foundation. Fix problems. Iterate.

    And that backlog? Clear it. Those 237 “must-have” features from 2019? We won’t be building them. The team has changed. The market has shifted. Our understanding has evolved.

    So we’ll have some unknowns, so be it. We’ll figure this out.

    references

    Photo by Neil Rosenstech on Unsplash

  • The true cost of principles

    The true cost of principles

    Sean’s voice crackled through the loudspeaker: “Can you hear me?”

    “Yes”, muttered the director.

    “Look Stacy, no one’s more upset than us. We’re in a tough situation, I know.

    The launch should’ve happened a month ago. Everyone’s been working non-stop.”

    “Then why didn’t it?” she interrupted.

    Sean continued.

    “This was supposed to be a quick experiment. Two sprints max.”

    “I know!” Stacy’s frustration carried over as if he were in the room.

    “But then we needed CRM integration. Product wanted customizable widgets. Compliance had a pile of checks. Engineering guidelines changed mid-stream… And when I tried reducing scope, nothing could be cut from the MVP.

    We must decide what’s more important. Either it’s an experiment with rough edges, or it’s a sure bet that we build properly. Moving the goalposts constantly helps nobody.”

    —-

    Most of us have experienced this conversation.

    When everything is a priority, nothing is.

    Time is finite. Demand always exceeds capacity. Teams without power to triage effectively won’t be able to deliver—the classic tragedy of the commons.

    Some leaders try to avoid the costs of hard choices by saying yes to everything. But this is just kicking the can down the road. Sooner or later, the non-decision will trigger a crisis.

    “Passion for excellence”, “Customer first”, “Bias for action”.

    Fine principles, but without ruthless prioritization they are nothing more than hollow words, worthless when facing a hard choice.

    And in unstructured environments, they become tools of control; swords hanging constantly above people’s heads.

    “Bring me a rock—no, not that one.”

    For a principle to have value, it must carry a cost:

    – User happiness over technical convenience.

    – System stability over delivery speed.

    Only when these choices are consciously made, and written down, they become useful.

    To do this, start by examining your constraints: budget, time, talent, compliance adherence. Anything that you can’t easily get more of.

    Which resource is most scarce?

    This scarcity is your guide for prioritizing.

    Compliment this by understanding what stakeholders actually need (yes, including those “pesky” end users).

    What is more important for them?

    Finally, consider the classes of deliverables.

    Should they all treated equally?

    Are there any that can tolerate compromises in the above?

    For example:

    – Does every experimental feature require the same rigorous test coverage as your core platform?

    – Does that quick experiment truly warrant the same legal scrutiny as your flagship product?

    – Should the rarely used feature have the same polish as the app’s main flows?

    We get in situations like the above, when we assume the answer is “yes” to all such questions.

    To avoid it, you must be willing to sacrifice some things for what matters.

    It’s simple but not easy. That’s how you get real principles.

    references

    Photo by bady abbas on Unsplash

  • Missing the Forest for the Trees: Rethinking Performance Management

    Missing the Forest for the Trees: Rethinking Performance Management

    Most organizations implement performance management backwards.

    They focus on individual achievement while hoping for team success.

    And in the end, they undermine both.

    The problem is with where we measure, not how.

    Personal output, skill gaps, growth areas, contributions against role expectations are all looking at the individual.

    This seems like a logical place to start, but creates a fundamental problem: it puts self-preservation above collective achievement.

    When my year-end review depends solely on my output, why would I prioritize helping others?

    To see the cracks, look where there are hand-offs between functions.

    Consider quality: if engineers are evaluated only on how “good” their code is, they have little incentive to help colleagues improve. They will invest in perfecting their deliverable, and defer as much as possible anything that doesn’t contribute to this goal.

    Collaboration with peers, end user experience, overall system stability, and even code reviews, will be put in the back seat.

    This pattern shows up in any solution built in a vacuum, without collaboration.

    Beautiful designs ignoring technical complexity, perfect product specs lying on unrealistic timelines, changes to shared systems without considering side-effects.

    If the deliverable is optimized for individual success, the collective product will suffer.

    Performance reviews compound these problems through their retrospective nature. There is nothing you can do for something that occurred months earlier. To get better, you need feedback while the opportunity to change things has not passed—the best source of which are the people around you

    Traditional evaluations routinely violate this principle.

    A better approach is to bring the focus to the collective outcomes to measure individual success.

    This shift requires rethinking how we assess things.

    Instead of asking

    Did this person complete their assigned tasks?

    we should ask

    Did this team achieve its goals?

    The former creates silos; the latter builds bridges.

    The achievements of our civilization came through cooperation, not isolation. High performance teams understand this truth and design evaluation systems that reflect it.

    To test your organization’s approach, examine how performance is evaluated.

    What percentage of individual reviews reflects team outcomes?

    If the answer is “little” or “none”, congratulations: you’ve just identified a structural barrier to collaboration.

    The next time you evaluate performance—yours or someone else’s—ask whether you’re measuring what truly matters: the individual trees, or the health of the entire forest?

    And remember:

    There are no winners on a losing team, and no losers on a winning team.

    Fred Brooks

    references

    Photo by William Warby on Unsplash

  • “How long will this take?”

    “How long will this take?”

    The dreaded question. The one that no team wants to answer.

    People think this question is about time. It’s not.

    The currency of estimates are confidence & trust. And this is how your answer is measured.

    (more…)