After weeks of using ChatGPT Dots and Grok Bot, they're neck and neck. I compare autonomy, proactivity, memory and how they work.
There's a huge difference between telling a team what to do and getting them to understand what they're trying to achieve. Giving context isn't sharing more information, it's helping someone understand what game they're playing.
More and more teams are delegating code review to an agent. Before accepting the shift, it's worth pausing on a more basic question: what was code review, done between humans, actually doing all these years.
Building something is no longer expensive. Deciding what to build-and getting everyone to understand it the same way-is what's still expensive.
There's a stage in a team's growth where everything revolves around getting the process in order. But if you're not paying attention to how it ages, the process starts taking up space it shouldn't.
When a team fails, the first reaction is to look for someone to blame. But what can we do to exercise proactive leadership?
Reflections on how an organization like AIESEC can develop leaders more effectively than many companies.
There are people with enormous potential who remain stuck in their initial quadrant, and no one, neither they nor their leaders, walks far enough to see what lies beyond.
Quantophrenia is the obsession with measuring everything. Sociologist Pitirim Sorokin coined the term in 1956. How it shows up in tech teams and what gets lost when only what fits in a spreadsheet counts.
We build features as if that were the goal… but what if we’re not generating any real impact?
A Talks by Pomelo session about how the Pomelo dashboard went from a monorepo to microfrontends integrated at runtime, and why the hardest part in the end wasn't the technical one.
The Dunning-Kruger effect is when people who know the least overrate their skill. On engineering teams it shows up as sure decisions from people still learning.
The McNamara fallacy says that what you cannot measure does not matter. Engineering teams then ignore quality and judgment that never show up on a dashboard.
Brooks's law says adding people to a late software project makes it later: ramp-up and coordination cost more than the extra hands on the team.
When a measure becomes a target, it stops being a good measure. Engineering teams then chase the number and miss the outcome it was there to track.
Parkinson's law says work expands to fill the time available for it. Engineering teams with loose estimates ship later, even when the problem itself was small.
Vanity metrics look strong and almost never change a decision. Engineering teams that chase them celebrate activity while the outcome that matters stays flat.
Micromanagement is controlling every detail of someone else's work. Engineering teams slow down when a lead reviews the how instead of the outcome.
The Peter principle says people rise until the role is past what they do well. Engineering teams feel it when a strong developer becomes a lead too soon.
Burnout syndrome is exhaustion, detachment, and the sense that effort no longer matters. Engineering teams usually design it in through load, not weak people.
Impostor syndrome is believing you do not deserve your role and will be found out. It hits engineering teams hardest as someone grows into harder work.