Chemaclass - leadership

Working With the Garage Door Open

2026-07-14T00:00:00+00:00

Most people work with the garage door closed. They work in private and raise it only when the car is polished and parked. The neighbors see a finished thing. Never the work.

The phrase comes from writer Robin Sloan. Researcher Andy Matuschak turned it into a practice: notes and half-baked ideas visible to anyone walking past.

Open the door.

It means showing the work while it’s still in progress. The draft with the ugly variable names. The experiment you’re halfway through. Not the demo. The middle.

Why we keep it closed #

Fear, mostly. A closed door protects you. Nobody judges a mess they can’t see.

So we hide the drafts. We only push code once it’s clean enough to survive review. By the time anyone sees the work, every real decision was made in private.

That instinct feels safe. It costs you the exact moments where help was still possible.

A finished result can only be admired. A work in progress can be shaped.

What the open door gives you #

When people see the middle, they can change it. A teammate spots the dead-end approach before you sink another day into it. A junior asks the “dumb” question that turns out to be the real problem. Pair programming is this at its purest: the door open, live.

The open door also kills the myth that seniors don’t struggle. When a junior watches you get stuck and google an error you “should” know, they learn what real work looks like. Not the highlight reel.

I lived this with bashunit, my bash testing library. I shipped it imperfect. Everyone who looked inside the garage shaped it: bug reports, feature requests, pull requests. Same with Phel and my public .claude folder. The open-source way.

But an open door isn’t enough #

Here’s the trap. You leave the door up, open a PR, write notes in a shared doc, and wait for help to arrive.

It doesn’t. Nobody wanders into your garage.

Visibility is passive. “Public by default” is the floor, not the goal.

Leaving the door open is not the same as inviting someone in.

The skill isn’t openness. It’s pushing the right signal to the right people, on purpose.

Push signal to the right room #

Every channel comes with an expectation of who reads it. Matching your update to it is the whole game. Post in the wrong room and you’re noise or invisible.

The whole company reads it. #general. Post only what matters to everyone.
The tech team reads it. #engineering. Where a work-in-progress update belongs.
Interested people opt in. #insights: industry news, customer signals. Useful, but nobody has to read it.
Nobody has to read it. #random. Say whatever.

Same update, four different outcomes depending on where it lands. Learn the map before you broadcast.

What a good signal looks like #

A good update is not “hey, I pushed something.” It carries enough context that a reader can engage without asking you a single question.

Say I’m halfway through a pilot: a new way to slice and review pull requests, tested on one team. I don’t wait for the end. A short update goes to #engineering: where I’m stuck, plus one explicit ask. “Has anyone tried this with a monorepo?” gets answers.

When the pilot ends, the result goes to the same room:

What I tried and why it mattered.
What worked, with a concrete before and after.
What didn’t, honestly. The failed part is the most useful part.
What you’d do to try it yourself.

Both are signals, not statuses. They turn one team’s experiment into something the whole org can copy or shoot down. This is Ship, Show, Ask applied past the pull request.

Start small #

Pick one thing this week. One experiment, one draft, one stuck moment. Do two things: leave the door open, then walk out and tell the right room it’s there.

You’ll get help you didn’t expect. You’ll teach someone without meaning to. And the fear that kept the door down will look smaller from the other side.

The polished result impresses people. The pushed signal is how the work gets better.

Open the door. Then point at it.

The Levels of AI Adoption

2026-05-01T00:00:00+00:00

Most companies use AI today, but few know where they stand on the AI adoption ladder. At one end, you paste code into ChatGPT. At the other, agents open PRs while you sleep. Beyond that, AI reaches people who never touched a terminal. This post maps the path.

Where we started #

Using AI to code meant a second tab. Write a function, get stuck, paste the error into chat, paste the answer back, and hope it works. It was slow, messy, and disconnected from your code.

GitHub Copilot, built on OpenAI’s early Codex, added suggestions inside the editor, often confidently wrong. It was trained on public code, and most public code isn’t great. It also knew nothing about your domain, your conventions, your architecture. It was autocomplete that sometimes guessed right.

The first generation of AI coding tools gave you a parrot trained on the whole internet. Fluent, confident, and often saying things that made no sense in your codebase.

This was vibe-coding in its first form: you gave the vibe by pasting context, and the AI filled in code that looked right. It compiled often enough to feel useful, and broke often enough to feel dangerous.

The IDE generation #

The next step was obvious: if the AI needs context, give it the whole editor.

Cursor, Windsurf, and similar IDEs moved the model inside your coding flow. The assistant could read files, follow imports, and see more than one function at a time. Vibe-coding became a conversation with your project, and productivity jumped. For a moment, it felt like the endgame.

It wasn’t. Editing files is only part of the job. The rest is running tests, reading logs, opening branches, reviewing diffs, and understanding what the codebase already does. Editor-only assistants helped you type faster, but they couldn’t take a task from “fix this bug” to “PR ready for review.”

The agentic shift #

OpenAI launched Codex as a cloud agent: give it a task, it works on a branch, and you come back to a PR. Anthropic shipped Claude Code, a CLI agent in your terminal, on your repo, with your tools.

This was the big shift, and not because the models were smarter. The unit of work changed. You stopped prompting line by line and started delegating tasks: read the ticket, write the change, run the tests, explain what you did. An agent doesn’t need hand-holding. It needs a goal and the right context.

The jump from assistant to agent is not a speed improvement. It’s a change of job description. You move from typing code to directing work.

Claude Code needs almost no setup. No editor lock-in. Point it at your repo, drop a .claude folder with rules and conventions, and it adapts. I covered that in Inside the .claude Folder.

The model you pick matters more than before. Today’s frontier models are way ahead of where they were a year ago. The gap between “can draft a function” and “can refactor a module with judgment” closed faster than expected, and it keeps closing as Claude, Codex, and Gemini push each other forward every month. Prices are getting closer too, which is a polite way of saying everyone copies whoever figures out the sustainable version first.

Agents with their own home #

The next leap wasn’t smarter models, it was agents with their own machine.

OpenClaw is the clearest example. It’s an open-source gateway you run on your own hardware (Mac Mini, old laptop, VPS), an always-on agent connected to your messaging apps, files, and calendar. You bring your own brain: Opus, GPT, or a local model via Ollama. When a provider tightens limits or raises prices, you switch. You own the setup.

A coding agent lives inside one repo for a task. An OpenClaw-style agent lives in your life, across days and tools. Sauron is mine. It reviews my PRs, opens issues, drafts code, ships open source contributions, and pushes back when I’m about to tunnel on something. Anything I can do on a computer, it can do too, just faster. It stops being a tool you open and becomes a place you work in.

A coding agent is a coworker you invite to a task. A gateway agent is a coworker who lives on a machine and shows up every day.

Providers change their plans and limits faster than anyone tracks, so people build setups that aren’t tied to one vendor. The logo on the model matters less every quarter, and the architecture around it matters more.

AI beyond developers #

AI coding was the loudest story because developers are loud. The bigger story is agentic tools reaching people who never wrote a line of code.

ChatGPT agent mode and Claude’s Cowork are the obvious examples: an AI that reads your documents, fills your spreadsheets, drafts your slides, and runs code for you in the background. Claude Design launched on April 17 and dropped Figma’s stock over 7% on launch day. The pitch is simple: describe what you want, get a working prototype, hand it to Claude Code to ship. A workflow that used to need a designer, a PM, a frontend engineer, and three review rounds is squeezed into one conversation.

Lovable, v0, Canva, and Figma itself are all under pressure to rethink their positioning. Whether Claude Design “kills” any of them is the wrong question. The right one is what happens when making a usable prototype drops from “hire a designer” to “describe it out loud.”

The companies feeling this first aren’t the design tools. They’re the small businesses that couldn’t afford design work, the founders building a pitch deck at midnight, the PMs testing an idea before booking a meeting. There’s a minority of cases where someone would have paid a designer and now won’t, and that cost is real. But in most of them, AI didn’t replace anyone: it filled a space where no designer was ever going to exist.

The levels of AI adoption #

Every company I talk to sits somewhere on this ladder. The levels aren’t about how much you pay in licenses, but about how deeply AI is built into the way work gets done, and not just in engineering.

Level 0: Denial #

A company-level stance. No AI, officially. Some people use ChatGPT on personal laptops and don’t mention it. Leadership worries about IP leaks, or hasn’t made it a priority. The conversation stays at “we should look into this someday.”

The risk here isn’t technology, it’s time. Every month at Level 0 is a month your competitors grow their lead.

Level 1: Personal productivity #

Individual adoption. AI is allowed, maybe encouraged. Each person uses it their own way: ChatGPT in a tab, Copilot in the IDE, Claude for the tricky stuff, a design tool for mockups. Output goes up, but the know-how stays inside each person’s head. Two engineers, or two PMs, or two designers on the same team get very different results because they prompt differently.

Most companies are here in early 2026. It’s a real improvement over Level 0, and it’s where the myth of “AI gives you speed” gets born. As I argued before, speed without shared direction is faster chaos.

Level 2: Shared practices #

The team agrees on how to use AI: shared conventions, prompts people reuse, rules in the repo, a shared sense of when to trust the output and when to push back. Code reviews catch AI mistakes the same way they catch human ones, and design reviews do too. Tests are required whether a person or a model wrote the code.

This is the first level where AI becomes a team skill rather than a personal habit. Higher ceiling, higher floor. New people ramp up faster because the prompts and rules capture how the team works.

Level 3: Context-aware tooling #

The team invests in context: rules files, conventions, architecture docs agents can read, and MCP servers connecting agents to the databases, APIs, and internal tools they need. The AI stops being a generic assistant and becomes closer to a coworker who has read the onboarding docs.

At this level, quality depends less on the model and more on the context around it. A weaker model with great context beats a frontier model with none. Good docs and clean architecture pay off twice: they help both humans and agents.

Level 4: Agentic teams #

Instead of one assistant, you get a squad: a TDD coach, a clean code reviewer, a domain architect, a docs maintainer. Outside engineering, the same idea applies with research, design, and ops agents. I covered the developer side in Build Your Own Team of Agents, and the leverage is real.

Humans stop competing with AI on speed and start directing it. You review, decide, and set the bar. Agents handle typing, and increasingly the thinking. Pair programming with a person still wins on complex trade-offs, but an agent pair is always there for the rest.

At the company level, the org chart, roles, and processes are still the same. What changes is that each person produces a lot more, and the team’s output reflects it. Level 4 multiplies output inside the existing structure. Level 5 changes the structure.

Level 5: AI-native workflows #

The final shift is about how the company runs. Processes are designed around agents instead of just fitting them in. Tickets are written so an agent can act on them, and reviews assume part of the work was written by a machine. Architecture decisions take into account what agents do and don’t do well. Even hiring changes: a senior IC at Level 5 is closer to a tech lead leading people and agents than a classic individual contributor.

Few companies are fully here in 2026, but the direction is obvious enough that ignoring it is its own decision.

You don’t move up a level by buying better tools. You move up by changing how work is organized and reviewed.

AI is not stealing jobs #

I keep hearing people call this a layoff story, and that framing is lazy.

The industrial revolution didn’t end work. It ended specific kinds of work and created others. The people who lost the most refused to re-skill, and the people who gained the most learned to operate the new machines instead of competing with them.

Same pattern here. AI isn’t taking your job, it’s changing what your job is. A developer who learns to lead agents out-ships one who refuses. A designer making ten versions before lunch with Claude Design out-designs one still opening Figma from scratch. A PM who ships prototypes out-prioritizes one writing specs nobody reads.

AI doesn’t replace the skilled worker. It replaces the worker who thinks skill is a fixed asset instead of a moving target.

With the right training, model, and setup for your context, AI gives you 10x speed without losing quality. I’ve seen it, and it’s not marketing. But the 10x only shows up when you already know what good looks like. Without that foundation, AI happily produces 10x more mediocre work.

That’s the honest version of the promise: AI can produce crap ten times faster, and excellent work ten times faster. Which one you get is on you.

The shift in where your attention goes #

You stop thinking about details first and start thinking about direction: what are we building, who for, what shape, and which trade-offs. Agents then do most of the implementation while you protect quality and coherence.

This sounds like good news for anyone who prefers architecture to typing, and it is. But there’s a trap: you can only work at the high level if you know the low level well enough to catch drift. When the agent produces something subtly wrong (a test that passes for the wrong reason, a refactor that changes behavior under load, a design that breaks on mobile), you need to spot it instantly. If you can’t, you’re not directing, you’re signing off on whatever shows up.

AI lets you spend more time on direction, but only if you’ve already earned the right to ignore the details. You earn that by having mastered them first.

Why the ladder matters #

I see teams skip levels and fail. A team jumps from Level 1 to Level 4 because leadership read a blog post about agent squads, and the agents produce mountains of low-quality code because nobody agreed on what quality means. The agents aren’t the problem, the missing foundation is.

The ladder is an order that matters. Shared practices come before context engineering, context engineering before agent teams, and agent teams before AI-native workflows. Each level builds on the previous one, the same way clean code builds on naming, and naming builds on knowing what you’re modelling.

The companies that win the next few years aren’t the ones with the biggest AI budget. They’re the ones that climb this ladder deliberately, one level at a time, without skipping the parts that look boring.

Where to start #

At Level 0 or 1, the next move isn’t more licenses. It’s deciding, as a team, how to use these tools. Write it down, commit it to the repo, and review it every week or month as the tools evolve.

At Level 2 or 3, look at where context is missing. What does your AI not know about your codebase, product, or brand that a new hire would learn in week one? Write it down. An afternoon of rules and docs pays back for months.

Further along, the question flips. You stop asking “how do I use AI better?” and start asking “how does my team need to change so AI amplifies what we already do well?” That’s a leadership question, not a tooling one.

AI is moving fast, but the work of adoption is still slow and human. The tools are the easy part. The hard part is deciding what good looks like, writing it down, and holding the line.

AI can execute, but it doesn’t know where you’re going. It can produce, but it doesn’t know what’s worth producing. That part is still on us. Speed is a gift, and direction is a responsibility. From the solo engineer at Level 1 to the AI-native org at Level 5, the same truth holds: the human supervises, understands, and gives meaning. The machine does the rest.

When the hype settles (and it will), the question won’t be “did you use AI?” Everyone will. The question will be “at what level, and with what direction?”

Idealism vs Pragmatism

2026-03-01T00:00:00+00:00

You believe in clean architecture, comprehensive tests, disciplined processes. You also shipped an ugly fix at 11pm last month because the system was down and users were waiting.

Both of those are you. The tension between them isn’t a contradiction. It’s how this work actually gets done.

Two forces, one decision #

Idealism is the compass. Clean code, tested behavior, shared understanding, principled design. Without it, you drift. Every shortcut compounds, every hack breeds another hack, and eventually you’re maintaining a system nobody wants to touch. Poor software quality cost US companies $2.41 trillion in 2022, with technical debt as a major driver. That’s what “we’ll fix it later” looks like at scale.

Pragmatism is the engine. Deadlines, incomplete information, limited resources, shifting requirements. Without it, you never ship. You spend weeks perfecting an abstraction that the business abandoned two sprints ago.

The goal isn’t to pick a side. It’s to know when each one should lead.

Idealism without pragmatism produces beautiful code that nobody uses. Pragmatism without idealism produces a product that works today and collapses tomorrow.

TDD: the benefit and the cost #

I believe in test-driven development. Red, green, refactor. The rhythm forces you to think before you code, to specify what you want before building it. It produces better designs, shorter feedback loops, and code you can refactor with confidence.

That’s the ideal. And it’s not just a feeling. A study across four teams at Microsoft and IBM found TDD reduced defect density by 40-90%, with a 15-35% increase in development time. Both sides of the tension, measured.

The study covered four teams: three at Microsoft (Windows, MSN, Visual Studio) and one at IBM working on device drivers. Each TDD team was compared against a similar team on the same product, using the same languages and tools, under the same senior manager. The only difference was TDD.

The IBM team saw a 40% defect density reduction. The Microsoft teams ranged from 60% to 90%. As Nagappan noted, “over a development cycle of 12 months, 35 percent is another four months, which is huge.” Every manager still considered it worth it because the reduction in post-release maintenance costs more than compensated.

No one was forced into TDD. The teams adopted it voluntarily, which likely matters: people who choose a practice tend to apply it better than people who are told to.

TDD is a discipline, and discipline costs something. When you’re exploring a new domain and don’t yet know what the right abstractions are, writing tests first can feel like drawing a map before you’ve seen the territory. Sometimes you need to write throwaway code, spike a solution, feel your way through the problem space. Discovery doesn’t always follow a red-green-refactor rhythm.

There’s a difference between “I know what this should do and I’ll specify it first” and “I’m not sure what this should do yet.” TDD shines in the first scenario. In the second, a test-last approach (or even no tests during exploration) can be more honest.

The key is what happens after discovery. Once you understand the problem, go back and write the tests. Codify what you learned. The pragmatic detour doesn’t mean abandoning the ideal; it means reaching it through a different path.

As I discussed in TDD vs BDD, the power of TDD is its feedback loop. But a feedback loop requires knowing what feedback you’re looking for. When you’re still figuring that out, forcing the loop can slow you down more than it helps.

The mistake isn’t choosing test-first or test-last. The mistake is making it a religious decision instead of a contextual one. The idealist says “always test first.” The pragmatist says “test when it makes sense.” I say: test first when I can, test after when I must, but always test.

TDD is a compass, not a cage. Follow it when you can see the path. When you can’t, find the path first and mark it after.

Pair programming: the ideal and the overhead #

Effective pair programming is one of the best practices a team can adopt. Two people, one problem, continuous code review. Knowledge spreads, design improves, blind spots shrink.

That’s the ideal. And in many contexts, it’s the right call.

But pairing has a cost. It demands synchronous time, shared focus, and compatible energy levels. In a distributed team across time zones, finding overlap windows is already hard. Filling those windows with pairing sessions leaves little room for deep individual work. Some problems benefit from one person going deep for three hours, not two people going medium-deep for six.

There are multiple pairing patterns: Driver-Navigator, Ping-Pong, Tourist Guide. Each fits different contexts.

The anti-patterns matter too. The Silent Partner who lets the other person do all the work. The Dictator who won’t let go of the keyboard. The Philosophical Pair who spends the entire session debating naming conventions instead of writing code.

Pairing works best when both people are engaged, the problem benefits from two perspectives, and the session has a clear scope. When any of those conditions is missing, pairing becomes a ritual instead of a practice. And rituals without purpose are just overhead.

Pull requests and pair programming aren’t mutually exclusive. They serve different needs. Sometimes asynchronous review is enough. Sometimes you need the real-time back-and-forth. The pragmatic choice depends on the problem, the people, and the moment.

The goal of pairing isn’t to pair. It’s to build shared understanding and catch mistakes early. If another approach achieves that in your context, use it.

AI: from skeptic to squad leader #

A year ago, I was skeptical about AI coding assistants. My concern: an AI that doesn’t understand architecture, doesn’t care about maintainability, and optimizes for speed over quality will produce code that looks impressive and decays fast. I wrote about this in AI gives you speed, not quality, and I stand by the core message.

My concern didn’t change. What changed is how I use them, and what they’re capable of now.

The resistance #

The reactions from other engineers surprise me more than the technology. Fear, skepticism, flat-out rejection. I get it. I was there. Something you spent years mastering suddenly has a machine doing parts of it. That feels personal. But holding on to how things were doesn’t protect the craft. It just delays your own growth.

A team, not an assistant #

Most engineers treat AI agents like autocomplete on steroids. One assistant, one chat, one stream of generated code. I started treating them like a team. Not one chatty assistant. An actual squad. One thinks architecture. One writes the first draft. One reviews and spots bugs. One writes tests. When they collaborate, the output isn’t just faster. It’s structurally better.

Speed is the easy part, and everyone’s obsessing over it. AI can spit out a ton of code in seconds. It still doesn’t care about readability, edge cases, or what the codebase looks like in six months. You’re still the one who has to own it, understand it, and feel good pushing it live.

I used to think AI couldn’t write clean code. Then I tried it on my terms: proper context, rules, conventions, specialized roles, quality gates. With the right setup, AI can write genuinely good code. Sometimes it needs a few iterations, but so do we.

The difference is that AI gets there faster, and it doesn’t get tired between iterations. Given good context and clear constraints, the results have been better than I expected. Often better than what I’d produce solo under time pressure.

But none of this works if you don’t know what good architecture looks like. You have to have read the books, experimented, failed, learned. You need to understand what high and low level design decisions mean for your project. AI amplifies whatever you bring to the table. If you bring solid foundations, you get solid output. If you don’t, you get confident-looking garbage that you won’t even recognize as garbage.

We are still the ones responsible for keeping the system in good shape. AI helps us get there. But only if we hold up our end.

Where idealism meets AI #

AI made me more idealistic, not less. The practices I described earlier, TDD and pair programming, used to compete with deadlines. Now they don’t have to.

I like to practice TDD, but recently I experimented with a dedicated agent to help me with tests, and it’s surprisingly good. A TDD coach that guides the red-green-refactor cycle. An explorer that reads the codebase before I touch it. A clean code reviewer, a domain architect, a React reviewer, a docs maintainer. Each one specialized, each one supporting my way of thinking and my flow. If new logic gets added without coverage, the TDD agent catches it. 100% code coverage used to be the kind of goal you’d set in a retro and quietly abandon by sprint three. With a dedicated agent enforcing it, it’s just how the project works.

I still practice pair programming with real people for complex topics. The human back-and-forth has depth that AI doesn’t reach, especially when you’re navigating trade-offs that require experience and judgment. But on the daily basis, I always have a pair buddy agent with me. I bounce ideas off it, challenge an approach, talk through edge cases, explore a design before committing to it. It supports my thoughts, speeds up the progress, and keeps the quality bar where I want it.

The pragmatist in me used to drop TDD when deadlines got tight. The pragmatist in me with the right AI setup keeps it running.

I use Claude for everything. Claude Code with Opus or Sonnet as the agentic coder: full development workflows, reading the codebase, following conventions, running tests, creating PRs. Claude app and Claude as a coworker for the chat side: brainstorming, architecture discussions, explaining code, drafting documentation. For inline assistance, the plugins I already have in my IDE are enough. I tried Copilot and Cursor, they’re not for me. Claude covers what I need.

Different modes for different tasks. An agentic assistant following my TDD commands is a different workflow from chatting about design patterns. Both are useful. Neither replaces the other.

The market right now is intense. Claude, Codex, Gemini and others are strong players with similar products, and they’re all getting better on a monthly basis. The results are impressive and only accelerating. That’s the beauty of competition: it forces everyone to improve or become irrelevant, and the consumer wins either way. As of today, Claude Code seems to be the strongest option for how I work. But I have no loyalty to a brand. If Anthropic stopped pushing forward and a competitor became clearly better, I’d switch without hesitation. What matters is the capability, not the logo.

I was wrong about AI in the way that idealists are often wrong: I measured the tool against the ideal outcome and found it lacking, instead of measuring it against the realistic alternative.

The alternative to AI-assisted development isn’t a team of senior architects writing perfect code. It’s the same team writing the same imperfect code, just slower.

The engineers who learn to lead agents instead of racing against them will have a real advantage. And this is still early.

The question was never “can AI write perfect code?” It was “can I lead AI to write better code, faster?” And the answer, with the right setup, is yes.

The whole game #

Every practice in this post follows the same pattern. The ideal version exists in books. The pragmatic version exists in your codebase under pressure. You need both.

Next time you’re shipping that 11pm fix, you’ll know which corners you cut and why. That’s the whole game. Not perfection. Not speed. Knowing which one should lead.

Build Your Own Team of Agents

2026-02-07T00:00:00+00:00

Most people use AI coding assistants as a single conversation partner. You open a chat, describe what you need, and get an answer. It works. But it’s like hiring one generalist to handle everything: frontend, backend, testing, documentation, deployment. No real team works that way.

The real leverage comes when you organize AI as a team: onboarding, standard procedures, specialists, and parallel execution.

In the MCP post, I covered how to give your AI agent access to your environment. In AI gives you speed, not quality, why human judgment still matters. This post covers the missing piece: how to organize that access into a coordinated workflow.

The onboarding doc #

Every good team starts with onboarding. AI agents need the same.

Project rules #

In Claude Code, the CLAUDE.md file at the root of your project is the onboarding doc. The agent reads it every time it starts working: project structure, coding conventions, style guides, tool configurations.

But CLAUDE.md is just the entry point. You can split rules into focused files under .claude/rules/, each targeting specific parts of your codebase via glob patterns. The agent doesn’t just know your conventions, it’s constrained by them. Layer boundaries, naming patterns, dependency directions. All versioned alongside the code they protect. And since .claude/ lives in the repo, every human teammate gets the same setup when they join the project.

modules/*/Domain/**/*.php: No framework imports, no infrastructure dependencies, only plain PHP.
modules/*/Infrastructure/**/*.php: Controllers stay thin, Eloquent models stay in their place.
resources/js/**/*.tsx: Component conventions, TypeScript strictness, styling patterns.

Each rule file is scoped to the files it cares about. Domain rules don’t fire when editing a controller.

Personal preferences #

There’s also a global ~/.claude/CLAUDE.md that applies across all your projects. Commit message conventions, communication style, formatting habits. The project file says how this codebase works. The global file says how I work.

A well-written CLAUDE.md is like a good onboarding doc. The better it is, the less you repeat yourself.

Standard operating procedures #

Every team has recurring workflows that live in wikis, runbooks, or someone’s head. When they live in someone’s head, they’re fragile.

Custom slash commands in .claude/commands/ turn these workflows into executable instructions. Each command is a markdown file describing a multi-step procedure. In one of my projects, every creation command starts with tests. TDD is baked into the procedure, not left to discipline.

Creation (TDD-first):

/create-module: Scaffolds a hexagonal module with domain, application, and infrastructure layers.
/create-entity: Domain entities with value objects and test files.
/create-use-case: Command/query handlers with mocked tests.
/create-page: React pages with factories and smoke tests.

Quality & workflow:

/refactor-check: Analyzes code against SOLID principles.
/test: Runs the suite with module filtering.
/fix: Auto-applies linting and static analysis corrections.
/gh-issue: From GitHub issue to implementation to PR in one command.

The key insight: commands turn tribal knowledge into executable instructions. What used to be “ask Sarah how we set up a new module” becomes a command anyone can run, human or agent.

Specialists, not generalists #

Commands are your procedures. They encode how your team does things. But there’s another layer: skills and agents.

Skills as knowledge bases #

Skills are structured knowledge the agent can draw from. In one of my projects, I have skills for SOLID principles, hexagonal architecture, TDD workflows, and React/Inertia patterns.

Rules constrain: “don’t do this, always do that.” Skills teach: “here’s the pattern, here’s why, here are the common mistakes.” Rules are guardrails. Skills are expertise.

Agents as specialized roles #

Instead of one generalist, you define specialized agents with a clear role, specific tools, and even a different model based on the complexity of their job. You don’t need your most senior architect to rename a variable.

Explorer (lightweight model): Read-only reconnaissance. Searches the codebase, finds files, understands structure. Access to read and search tools, nothing else.
Clean code reviewer (mid-tier model): Checks for SOLID violations, code smells, and naming inconsistencies. Read and grep access only.
TDD coach (mid-tier model): Guides the red-green-refactor cycle. Can edit files and run tests.
React reviewer (mid-tier model): Frontend patterns: component structure, TypeScript strictness, dark mode support, accessibility.
Domain architect (most capable model): Complex architectural decisions, module boundaries, and DDD patterns.

The right model for the right job. Fast and cheap for exploration. Capable and thorough for architecture.

Let them work together #

This is where the team metaphor becomes literal. A single agent following instructions is useful. Multiple agents working from a shared plan is a team.

Subagents vs agent teams #

Not all multi-agent setups are the same. There are two distinct coordination models, and choosing the right one matters.

Subagents run within a single session. They do focused work and report results back to the main agent. They can’t talk to each other. The main agent manages everything.

Agent teams are different. Each teammate is a fully independent Claude Code session with its own context window. They communicate through a shared mailbox, claim tasks from a shared task list, and coordinate without going through a central bottleneck.

The architecture has four components:

Team lead: the main session that creates the team and orchestrates work
Teammates: separate Claude Code instances, each owning specific tasks
Task list: shared work items with dependency tracking. Blocked tasks automatically unblock when dependencies complete
Mailbox: direct messaging between agents, including broadcasts to the entire team

Subagents are workers that report back. Agent teams are collaborators that think together.

Use subagents when only the result matters. Use agent teams when teammates need to share findings, challenge each other, and coordinate on their own.

Getting started with agent teams #

Agent teams are still experimental. Enable them by adding this to ~/.claude/settings.json:

{
 "env": {
 "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
 }
}

Creating a team is conversational. Describe what you want: “Create an agent team to refactor the auth module. Spawn three teammates: one for backend API changes, one for frontend components, one for writing tests.” Claude sets up the task list, spawns the teammates, and coordinates their work.

You can view the team in-process (single terminal, navigate with Shift+Up/Down) or split across panes (each teammate in a separate tmux or iTerm2 window). Use Shift+Tab to activate delegate mode, which restricts the lead to coordination only.

Token consumption warning. Agent teams burn through tokens fast. Each teammate has its own context window, and every message between agents adds up. Start with research and review tasks before moving to implementation. Three teammates exploring in parallel costs roughly 3x. Make sure the parallelism pays for itself.

Teammates load your project context automatically (CLAUDE.md, MCP servers, skills) but don’t inherit the lead’s conversation history. When spawning a teammate, be specific about which files to focus on and what constraints apply. A vague spawn prompt produces vague work.

Plan first, execute after #

Good teams don’t just start coding. They discuss the approach, identify dependencies, agree on a plan. Claude Code’s plan mode works the same way.

You describe the problem. The agent explores the codebase, maps dependencies, and proposes an approach before changing anything. You approve, modify, or reject. Think first, code second.

With agent teams, plan approval lets you require teammates to design their approach before implementing. The teammate works in read-only mode until the lead approves. You can shape the lead’s criteria: “only approve plans that include test coverage” or “reject plans that modify the database schema.”

Delegate mode restricts the lead to coordination only. Without it, the lead sometimes starts implementing instead of waiting for teammates. Delegate mode keeps it focused on orchestration, not execution.

Competing hypotheses #

This is the most compelling agent-team pattern for debugging. When the root cause is unclear, a single agent tends to find one plausible explanation and stop looking. Agent teams fight this by making teammates adversarial. Each one investigates its own theory while actively trying to disprove the others.

Sequential investigation suffers from anchoring: once one theory is explored, subsequent investigation is biased toward it. With multiple independent investigators challenging each other, the theory that survives is much more likely to be the actual root cause.

Size tasks for parallel work #

Not all work benefits from parallelism. The key question: can the teammates work independently?

Too small: coordination overhead exceeds the benefit
Too large: teammates work too long without check-ins, increasing wasted effort
Just right: self-contained units that produce a clear deliverable. A function, a test file, a review

Having 5-6 tasks per teammate keeps everyone productive. Break the work so each teammate owns a different set of files. Without isolation, two teammates editing the same file leads to overwrites. Worktrees change this.

Say you’re building a new feature that touches both backend and frontend. After planning:

A backend agent scaffolds the domain layer: entities, value objects, repository interfaces, use case handlers. All following hexagonal architecture, all test-first.
A frontend agent builds the React page, components, hooks, and factories. Each follows its own rules, draws from its own skills, and operates independently.

They don’t step on each other because the plan already defined the boundaries. Clear ownership. No merge conflicts. No waiting.

Worktree isolation #

The biggest friction with parallel agents was file conflicts. Two agents editing the same file meant overwrites and lost work. Git worktrees eliminate this by giving each agent its own working copy of the repository.

Start Claude Code with --worktree to run in an isolated worktree. Multiple sessions, same repo, no clobbering. Add --tmux to launch it in its own tmux session.

claude --worktree --tmux

Subagents support worktrees too. Ask Claude to use worktrees for its agents, or set isolation: worktree in your custom agent frontmatter to make it the default.

---
isolation: worktree
---

The Desktop app has the same feature: enable worktree mode in the Code tab.

For non-git source control (Mercurial, Perforce, SVN), define worktree hooks to get the same isolation benefits without switching to git.

Worktrees turn “clear file ownership” from a planning constraint into an infrastructure guarantee. Agents can overlap on the same files without stepping on each other.

Review after execution #

After implementation, review agents take over. Instead of one reviewer catching everything, you have specialists: SOLID violations, component patterns, test quality, module boundaries.

A single agent is an assistant. Multiple agents working from a shared plan is a team.

You are still the lead #

No matter how well configured, the agents work for you. You set the standards, write the rules, review the plans, and approve the output before it ships. You can message any teammate mid-work to redirect their approach or add constraints. If someone’s heading down the wrong path, you intervene directly.

As I wrote in AI gives you speed, not quality, the code the agent produces is your responsibility. Agents still make mistakes, context windows have limits, and coordination isn’t perfect. More parallelism without oversight is just more chaos, faster.

Quality gates #

Hooks and git hooks act as the final safety net. In my setup, nothing gets committed unless the full suite is green and coverage is above 90%. The agent doesn’t get to skip this. Neither does anyone else.

Agent teams add their own hooks: TeammateIdle keeps idle teammates working, TaskCompleted prevents premature task completion. Automated policies no team member can bypass.

Git hooks run linters, static analysis, and tests before every commit. Claude Code adds its own hooks (.claude/hooks/): shell commands that trigger on agent events like tool calls or file writes.

.claude/settings.json controls what agents can execute. Whitelist specific tools and commands, deny destructive operations. You control not just what agents know (rules, skills) but what they can do (permissions). Rules set the culture. Permissions set the boundaries.

The foundation matters #

The agents will help you get there faster, but “there” has to be well-defined. If you don’t know what hexagonal architecture looks like, agents won’t discover it for you.

You don’t build all of this on day one. You start with a CLAUDE.md. Then you notice you’re repeating instructions, so you write a command. An agent breaks a convention, so you add a rule. Reviews take too long, so you create a reviewer agent. The setup grows organically from real friction, not from upfront design. Each addition solves a problem you actually had. Same with agent teams: start with tasks that don’t require writing code. Review a PR from multiple angles, research a library, investigate a bug. Learn the coordination model before throwing parallel implementation at it.

If you want a starting point, I put together laravel-claude-toolkit: a Laravel starter kit with rules, commands, skills, agents, hooks, and permissions already configured. Use it as a reference or fork it for your own setup.

You’re not just using AI. You’re building a team. And like any team, the quality of its output reflects the quality of its leadership.

Resources #

Claude Code | claude.com
Claude Code: Agent Teams | claude.com
Claude Code Tips: Workflow Boosters | rfrolov.me

AI Gives You Speed, Not Quality

2025-10-10T00:00:00+00:00

I’ve been using AI coding assistants extensively: ChatGPT, Codex, Claude with Sonnet and Opus. They’re incredibly helpful. They give you speed like nothing else.

But speed isn’t quality.

The vibe-coding trap #

AI models are excellent at imitating their surroundings. Give them context, and they’ll do whatever it takes to complete the task. This has become known as “vibe-coding”: you describe what you want, and the AI produces something that works. Fast.

The problem? AI will happily generate messy code if that’s what gets the job done. It doesn’t care about maintainability. It doesn’t think about what happens when requirements change next month. It just produces output.

AI is a mirror that reflects the context you give it. If your codebase is messy, it will generate more mess. If your prompts are vague, it will make assumptions.

Without careful guidance, you end up with patches on top of patches. Freshly created legacy code. A codebase where every change feels risky and the team spends more time fighting the code than building features.

The art of asking #

Remember Stack Overflow? Google searches that led you to forum threads from 2011 where someone had the exact same problem?

Ten years ago, being a developer meant learning how to ask good questions. You’d craft your Stack Overflow post carefully: describe the problem, show what you tried, explain what you expected versus what happened. If your question was vague or lazy, the community would let you know. Sometimes harshly.

But that friction taught us something valuable: the quality of your answer depends on the quality of your question.

The same principle applies to AI. A vague prompt gets a vague response. A well-structured prompt with clear context, constraints, and examples gets something useful. The skill of formulating good questions didn’t become obsolete. It became more important.

Learning to prompt AI effectively is the modern equivalent of learning to search Google and ask Stack Overflow. The developers who master this will get better results.

Even when AI gives you a fast, impressive-looking answer, never accept code you don’t fully understand. It’s tempting. The response appears in seconds, it looks professional, it might even work. But if you can’t explain what it does and why, you’re planting a time bomb in your codebase. And when it breaks at 2am, you’ll be debugging code you didn’t write with no mental model of why it exists.

Challenge the output. Ask: “Can you simplify this?” or “Is there boilerplate here we can remove?” AI’s default is to add, not to improve. It will generate abstractions, helper functions, and patterns you didn’t ask for. It won’t refactor unless you tell it to. Push back.

This is especially critical with tests. Ask AI to generate tests and you’ll often get tests that mirror implementation details rather than behavior. They’ll break the moment you refactor, even if the logic stays the same. If you want tests that verify behavior, you need to explicitly say so. AI won’t make that choice for you.

Don’t be seduced by speed. Sometimes, a fast answer you don’t understand is worse than a slow answer you do.

The human factor #

AI can write code fast, but it can’t understand overall architecture. It doesn’t know why certain decisions were made months ago. It can’t see the bigger picture of where the product is heading. It only sees what you show it, making local decisions without understanding global implications. That’s our job.

As I explored in different beliefs about software quality, teams often have varying standards for what “good enough” means. When you add AI to the mix, maintaining that shared understanding becomes even more critical. The AI doesn’t share your team’s values. It just generates code.

The discipline to maintain clean architecture, to say “no” to quick hacks, to refactor before things get worse. That’s uniquely human.

Books like Clean Code and Clean Architecture aren’t less relevant in the AI age. They’re more relevant. They help you spot when AI is heading in the wrong direction.

Collaboration over automation #

There’s something else AI can’t replace: the team.

A conversation with a colleague about “should we extract this into a service?” often leads to insights that no AI prompt would surface. That back-and-forth, the pushback, the “what if we tried this instead”. That’s where real understanding happens.

Extreme Programming Explained emphasizes practices like pair programming and collective code ownership for good reason. These aren’t inefficiencies to be automated away. They’re how teams build quality into their process.

When you skip the human discussion and just let AI generate solutions, you lose the opportunity to learn, to challenge assumptions, and to grow as a team.

You own the code #

When AI writes code and you commit it, review it, approve it, merge it, and deploy it, it’s your code. You can’t blame the AI when something breaks in production. You can’t point at Claude or Copilot when the architecture becomes unmaintainable.

As I wrote about the art of testing, quality is a choice we make at every step. Every commit is a decision. Every review is an opportunity to catch problems. Every merge is an endorsement of the code’s quality.

We are the ultimate responsible party for the code AI writes. The commit, the review, the approval, the merge, the deploy. That’s all us.

Moving fast in the wrong direction just gets you lost faster. Lines of code appearing on screen isn’t progress. The value we bring as developers isn’t typing speed. Our value is in understanding where we’re going, maintaining discipline over chaos, and ensuring that the code we ship today doesn’t become tomorrow’s nightmare.

Use AI. Embrace the speed. But never forget: you’re the one steering. If you let go of the wheel, you’ll end up in a pile of unmaintainable code faster than you expected.

And when that happens, there’s no one else to blame.

What Success Means to Me

2025-09-15T00:00:00+00:00

For the longest time, I thought success was about hitting certain milestones. Getting that promotion. Earning a specific salary. Building something that people would recognize.

But I’ve realized that’s not what gets me out of bed in the morning.

The real measure #

Success, for me, is straightforward now: waking up knowing that what I do makes the people around me, and myself, happier.

It took me a while to get here. This definition might not feel simple to everyone, and that’s okay. But for me, it clarified everything.

No complex formula. No checklist of achievements.

Success is about those small moments when you help a colleague solve a tricky problem, when you share something that makes someone smile, or when you finish the day feeling like you actually added some good to the world.

This applies whether you’re leading a team or just showing up as yourself. As I wrote about great leadership, real leadership starts with your own life and behavior. It’s fundamentally about making the people around you better, not just achieving targets.

Why happiness matters #

I used to think that focusing on happiness was somehow trivial. Like it wasn’t “serious” enough as a goal. But I’ve learned that making people happy, genuinely happy, is one of the hardest and most rewarding things you can do.

What does this mean in practice? #

Being present when someone needs you
Creating things that solve real problems
Choosing kindness over being right
Finding joy in what you do, even on tough days

When you focus on making others happier, you usually end up happier yourself. It’s not zero-sum. It compounds.

This connects deeply with understanding people and how they think. When you truly understand that everyone processes the world differently, you become better at creating genuine happiness, not just what you think should make them happy.

The daily practice #

How does this look in daily life? #

For me, it’s about checking in with myself regularly: “Did what I do today make things better?” Not perfect. Not revolutionary. Just better.

Sometimes that’s writing code that helps a team work more smoothly. Sometimes it’s taking time to really listen to someone. Sometimes it’s just being patient when everything feels chaotic.

It’s not always easy. Some days you miss the mark. But having this simple definition of success makes decisions clearer. When you’re wondering whether to take on a project, accept an opportunity, or say no to something, you can ask yourself: “Will this make me and the people around me happier?”

Consistency over perfectionism #

Here’s something I’ve learned the hard way: success is built through consistency, not perfection.

Perfectionism will paralyze you. It whispers that nothing is good enough, that you should wait until conditions are ideal, that one mistake invalidates everything. It’s a trap.

What actually works? Showing up. Day after day. Building small habits that compound over time.

As James Clear explains in Atomic Habits, real change comes from the compound effect of hundreds of small decisions. You don’t need to be perfect. You need to be consistent.

Don’t try to make a habit perfect, just repeat it.

This means:

Writing a few lines of code every day beats waiting for the perfect architecture
Having a short, genuine conversation beats waiting for the perfect moment
Making small improvements consistently beats waiting for the big breakthrough

The goal isn’t to never fail. It’s to build habits that align with making yourself and others happier, and to keep showing up even when you stumble.

This is where the process itself becomes the goal. It’s not about reaching some final destination of “being successful”, it’s about building daily habits and practices that align with what actually matters to you.

Success is personal #

Your definition of success will probably be different from mine, and that’s not just okay, it’s necessary.

“Have I always been like this?” The answer is no. I certainly wasn’t. Our understanding of what matters evolves as we grow. That’s part of the journey.

If you’re feeling stuck or unsure about what you’re working toward, try this: figure out what truly makes you and the people you care about happier. Not what you think should make you happy. Not what looks impressive from the outside.

Just what actually works for you.

And be ready to embrace the change when your definition shifts, because it will. What success means to you today might look different tomorrow. That’s not failure. That’s growth.

At the end of the day, if you wake up knowing that what you do brings more happiness into the world, including your own, you’re probably doing something right.

That feels like success to me.

Thanks to my friend Toni, for bringing up this question and inspiring this reflection.

Man's Search for Meaning

2024-11-29T00:00:00+00:00

In “Man’s Search for Meaning,” Frankl not only shares his harrowing experiences from the Holocaust but also presents a profound philosophy on the human condition. This book is a testament to the resilience of the human spirit, exploring how even in the darkest of times, individuals can find purpose and meaning.

Frankl’s insights into the psychology of survival and his development of logotherapy offer a unique lens through which we can view our own lives. As we delve into the depths of his narrative, we are invited to reflect on our personal search for meaning, challenging us to consider how we find purpose amidst life’s trials and tribulations.

Part 1: Experiences in a Concentration Camp #

Frankl, an Austrian psychiatrist, recounts his experiences in Nazi concentration camps, including Auschwitz and Dachau, during World War II.

He describes the psychological stages prisoners went through: shock upon arrival, apathy where they became emotionally numb to survive, and finally, the phase of disillusionment or bitterness if they were liberated.

Frankl emphasizes that even in the most horrific conditions, finding a purpose or meaning can provide the strength to survive. He notes that those who had something to live for, like a loved one or a personal project, were more likely to endure.

Part 2: Logotherapy in a Nutshell #

This section introduces Frankl’s psychotherapeutic method, which he developed based on his experiences. Logotherapy focuses on the meaning of human existence as well as on man’s search for such a meaning.

Unlike Freud’s “will to pleasure” or Adler’s “will to power,” Frankl proposes the “will to meaning” as the primary motivational force in humans.

Three Paths to Meaning:

Achievement: Doing a deed or creating work.
Experience: Experiencing something or encountering someone (love).
Attitude: The attitude we take toward unavoidable suffering.

Even in extreme situations, Frankl asserts that one can choose one’s attitude towards the situation, which can be a significant source of meaning.

He discusses this concept as the feeling of meaninglessness in modern society, leading to various psychological issues. Logotherapy aims to guide individuals to find personal meaning.

Key Takeaways #

Meaning of Life #

Frankl argues there is no one universal meaning to life; rather, meaning is unique to each individual and can shift over time.

Suffering and Meaning #

Not all suffering must be devoid of meaning; it can be a path to finding or reaffirming meaning.

Responsibility #

Each person has the responsibility to find their own meaning, which also entails the freedom to choose one’s path.

Frankl’s book is not just a memoir but a testament to human resilience and the power of the human spirit to transcend even the worst circumstances through the discovery of meaning.

Quotes #

“Ultimately, man should not ask what the meaning of his life is, but rather he must recognize that it is he who is asked.”

“We needed to stop asking about the meaning of life, and instead to think of ourselves as those who were being questioned by life, daily and hourly.”

“Everything can be taken from a man but one thing: the last of the human freedoms, to choose one’s attitude in any given set of circumstances, to choose one’s own way.”

“Freedom, however, is not the last word. Freedom is only part of the story and half of the truth. Freedom is but the negative aspect of the whole phenomenon whose positive aspect is responsibleness.”

Personal notes #

My favorite aspect of the book is its portrayal of life as an ongoing shift in perspectives, both from within oneself and in relation to the external world. It’s like adjusting a camera lens, zooming in or out based on context, recognizing that we are simultaneously individual entities and part of a larger collective.

This approach helps you gain a broader perspective, allowing awareness of both your limitations and your significance within any given scenario. Consequently, life doesn’t inherently possess meaning; rather, it’s the meaning we choose to attribute to it that shapes our existence.

Animated book summary #

People Skills

2024-09-02T00:00:00+00:00

So, you’re a software developer, and you’ve mastered coding languages, algorithms, and all the tech stuff. That’s awesome! But here’s the deal: technical skills alone won’t get you as far as you might think.

If you can’t work well with others, it doesn’t matter how great your code is, nobody will want to work with you.

Why People Skills Matter in Software #

In software development, collaboration is everything. Projects aren’t just solo endeavors. You will be part of a team, with other developers, designers, or even non-tech folks like managers and clients. How you communicate, collaborate, and handle feedback can make or break your success.

The Brilliant but Difficult Teammate #

Think about it. Have you ever had that one teammate who’s brilliant but hard or nearly impossible to work with? Maybe they don’t listen, get all the credit, or make everything more complicated than it needs to be. No one likes working with that person, right? It’s the same for you. If you can’t get along with your team, it doesn’t matter how good your code is.

What Being a Good Team Player Means #

Being a good team player means listening to others, being open to feedback, sharing ideas, and, most importantly, being respectful and considerate. You want people to enjoy working with you, not avoid it.

Good people skills help you build strong working relationships, solve problems faster, and create a better work environment for everyone. Don’t just aim to be a coding expert, ensure you’re also great to work with.

The Long-Term Impact #

In the long run, your people skills can boost your success as much, if not more, than your technical abilities. They play a vital role in a team’s success and make the work experience enjoyable for everyone involved.

People skills are as necessary as technical skills. No one will want to work with you if you are not a good team player.

What are people skills? #

The competencies that enable you to interact effectively and smoothly with others.

Core Communication Skills #

Communication: The ability to clearly convey ideas, listen actively, and engage in meaningful conversations. This includes both verbal and non-verbal communication.
Empathy: Understanding and being sensitive to the feelings, thoughts, and experiences of others. It involves seeing things from someone else’s perspective.
Emotional intelligence: Recognizing and managing your own emotions and understanding and influencing the emotions of others.

Collaboration Skills #

Teamwork: Working well with others to achieve common goals. This includes collaboration, sharing responsibilities, and supporting colleagues.
Conflict resolution: The ability to handle disagreements and disputes constructively, finding solutions that satisfy all parties involved.
Negotiation: Finding mutually acceptable solutions or compromises during discussions or disagreements.

Growth and Influence #

Adaptability: Being flexible and open to change, adjusting your approach as needed to meet different situations or personalities.
Leadership: Inspiring and guiding others, providing direction, and fostering a positive environment.
Networking: Building and maintaining professional relationships that can provide support, opportunities, and resources.

These skills are essential in almost every job and help build strong relationships, enhance teamwork, and create a positive work environment.

Why They’re Harder Than You Think #

These are often called interpersonal or soft skills, but mastering them can be surprisingly challenging, perhaps even more so than many technical skills. Unlike “hard skills,” which are tangible and can often be learned through a few hours or days of study, people skills involve navigating the intricate web of human emotions, experiences, and expectations.

While technical skills might require you to dive into documentation, run experiments, and refine your approach, understanding and relating to people is far more complex.

Humans bring their feelings, backgrounds, and routines into interactions, adding layers of complexity beyond machines’ straightforward logic. These personal details shape the reality we perceive, making interpersonal skills an essential yet complex part of effective communication and collaboration.

The Phoenix Project

2024-05-31T00:00:00+00:00

This is a story about an impossible project in which the people around are constantly playing politics, busy fixing critical bugs and wasting constant efforts on quick patches instead of helping the business thrive.

If IT fails, the business fails.

DevOps Principles: Flow, Feedback, and Continual Learning and Experimentation. These guiding concepts promote advancements in responsiveness, dependability, and teamwork.

Summary #

The book starts with the promotion of Bill as VP of IT, and with that the responsibility of delivering an imposible (Phoenix) project. The CEO warns him that if the project does not deliver in time, then the entire IT department will be outsourced and the current IT employees will be fired.

Bill tries to understand the status quo, and finds out that the people are too busy firefighting constantly and dealing with too many responsibilities (in addition, they are understaffed). Everything is urgent and needs to be done asap. The deadline was already setup from above, and there is no planning or discussions with other departments. TL;DR: Corporate chaos, politics and bloodbath meetings.

However, Bill gets to know one person in the company that helps him improve the status quo, not by telling him what to do but by asking him questions to help find the solution.

For example, the first question: “What are the four types of work that IT does?” which is not answered immediately but during the story:

Business projects: these are the projects that directly affect business goals. They generate revenue and deliver value to customers.
Internal projects: these are regular tasks that keep the system working. Like system upgrades, security patches, etc. It tends to be invisible and can become a bottleneck for IT departments.
Changes: the result of the previous business and internal projects, to know what to change with and within them.
Unplanned work: this is the real productivity killer. This is related to all operational issues resulted from the previous three types of work.

What Kills Agility?

2024-05-30T00:00:00+00:00

Dozens of documents and spreadsheets, meetings over meetings, and yet without much impact, result in team misalignments, realized too late.

How we manage an organization defines its quality. Excellent management is crucial to avoid the Waterfall trap if we aim to build an Agile environment. But why would we want that? What’s wrong with the way we already work?

If you are already happy with how you and your team work together, that’s okay. However, what about reevaluating how you work to look for potential improvements?

I am referring to evaluating your system and how you and the people around you act within it. What worked months or years ago might differ from what we could discover today, as part of continuous improvement.

I dislike politics in the workplace, where each team looks out for themselves instead of having a bigger shared direction. This results in daily work filled with fear from above, passed down to the people below, maintaining an unhealthy working environment. Game of Thrones is great as a fictional series, but not something to deal with in daily business.

Agile was born precisely as a response to the excessive waste generated by politics and organizational micromanagement.

Controlling and “slow performance” needed a more flexible approach. When people adopt a fixed mindset, they resist change, fear failure, and prioritize rigid processes and hierarchies. This conflicts with Agile’s core ideas of embracing change, continuous delivery with iterative development, flexible planning, and fostering collaboration and innovation.

A fixed mindset leads to fear of experimentation and a reluctance to challenge the status quo, reducing progress and the potential for learning and growth.

What kills agility? #

Fixed mindset: Resistance to change, fear of failure, and prioritizing rigid processes over learning and adaptation strangle innovation and flexibility.
Excessive bureaucracy: Complex processes and excessive documentation slow down decision-making and responsiveness.
Micromanagement: Over-controlling leadership undermines team autonomy.
Lack of collaboration: Poor communication and teamwork hinder progress.
Ineffective feedback loops: Prevent adjustments and continuous improvement.
Fear of experimentation: A culture that punishes failure discourages experimentation and learning from mistakes.
Inflexible processes: Strict adherence without adapting to project needs.
Misaligned goals: Conflicting priorities reduce efficiency.
Lack of leadership’s support: Without backing from upper management, Agile initiatives can struggle to gain the necessary resources and commitment.
Poor technical practices: Neglecting technical excellence and good design can lead to a fragile codebase that is difficult to adapt and extend.

What can you do about it? #

Learn the basics of Extreme Programming (XP) and Lean Software Development.

XP: Focused on software development practices and technical excellence, with specific practices like pair programming and Test-Driven Development (TDD).
Lean: Takes a broader approach, focusing on removing waste, optimizing flow, and improving processes across the organization.

Radical Candor

2024-04-17T00:00:00+00:00

Radical Candor is a management philosophy developed by Kim Scott, a former Google leader. It’s a crash course on how to be a great manager, focusing on being empathetic and results-oriented. The core idea is to create a stress-free environment where people feel safe to speak their minds, get their jobs done, and feel respected.

Key Insights #

Command and control can hinder innovation and harm a team’s efficiency. Collaboration and innovation flourish when human relationships replace bullying and bureaucracy.
The goal of Radical Candor is to help managers and leaders achieve collaboratively what they cannot achieve individually, by caring about the people they work with.
Radical Candor is about being radically honest and open, while still being kind and respectful.

The Two Dimensions of Radical Candor #

Care Personally: This dimension involves showing genuine interest in people’s lives, well-being, and goals. It’s about being human and empathetic.
Challenge Directly: This dimension involves giving specific, timely, and actionable feedback that is both kind and clear. It’s about being straightforward and results-oriented.

Avoiding the Three Behaviors #

Obnoxious Aggression: Being overly critical or aggressive.
Ruinous Empathy: Being overly sympathetic or enabling.
Manipulative Insincerity: Being insincere or manipulative in your feedback.

Radical Candor in Action #

Give specific and sincere praise and kind and clear criticism.
Create a stress-free environment where people feel safe to speak their minds.
Focus on collaboration and innovation, rather than command and control.
Care about the people you work with and challenge them to do their best work.

By applying Radical Candor, managers and leaders can build strong relationships, motivate their teams, and achieve better results.

Deployments on Fridays

2024-02-25T00:00:00+00:00

I have heard multiple times, from various people, the idea of panic towards deploying on Fridays. How good is that idea of banning the day before weekend from delivering new value to our clients or customers?

The main argument in favor of NOT deploying on Friday is based on the idea that we “should be paranoid” with our software and that it could fail when we touch it. So, we “should assume” the worst whenever we deploy a new release version of our system.

However, the critical factor here is Why? Why should we not deploy on Fridays? Is it OK to be afraid of our own software system, that we live in a constant panic of breaking it the day after we have done a deployment? How much impact should our releases have? How can we make sure the deployment won’t break the live system?

Your Continuous Integration/Delivery pipelines, end-to-end and other types of tests in place, automated scaling policies, a previous staging sandbox to perform even manual tests if necessary, etc., will determine the security and confidence for any of your releases. However, the quality of these topics is a deal-breaker to have enough confidence on how, when and why would it make sense to release to production.

The goal is build a system where deployments to production should be as often, smooth and easy as possible; any time, any day. Being afraid of your system should not be the aim. On the contrary, it should be something to work towards to fix it.

The team dynamics are also an essential factor here. If we establish fear of deployments on Fridays, and fear of our system, that will end up in lack of accountability by default. This reminds me of The Five Dysfunctions of a Team.

If you deploy small and frequent changes as soon as they can guarantee 100% quality value success, why delay such an incremental improvement to your system?

Coming back to “Why should we not deploy on Fridays?” The only reason I can think of is being afraid that we have to work on Saturday on the broken thing we delivered on Friday. However, I wonder if any option was available, so we could have identified such a broken thing during the working Friday itself.

Monitoring your live system is crucial to guarantee the health after each deployment. This is essential to ensure everything is working fine and smoothly. To build a resilience system, this should trigger alarms to notify someone responsible for addressing the issue, disable or revert the latest “broken” feature… there are many techniques to create awareness and act on them.

In case of doubt, you could use feature flags to disable the feature you will deploy. Still, you prefer not to enable it during the weekend while keeping the option of adding value and deploying anytime always open.

I believe frequent and small releases to production are key; any time, any date, as far as it makes sense, and there is a clear path to bringing value soon to the customer to get feedback ASAP.

Deliver quality value in small increments, as frequently as possible.

Being able to deploy on Fridays (if needed or wanted) impacts the team’s confidence. Similarly, forbidding deployments on Fridays impacts the team’s self-esteem as well.

The Lean Startup

2024-01-26T00:00:00+00:00

Most startups fail. But many of those failures are preventable. The Lean Startup is a new approach being adopted across the globe, changing the way companies are built and new products are launched.

Eric Ries defines a startup as an organization dedicated to creating something new under conditions of extreme uncertainty. This is just as true for one person in a garage or a group of seasoned professionals in a Fortune 500 boardroom. What they have in common is a mission to penetrate that fog of uncertainty to discover a successful path to a sustainable business.

Key Takeaways #

Test frequently and learn quickly
Observe and measure real customer behaviour
Focus exclusively on capturing actionable Metrics
Be comfortable pivoting based on key learnings
Embrace new accounting methods
Learn what is not working and apply changes immediately: stay lean

Summary #

Forming, Storming, Norming and Performing

2023-11-25T00:00:00+00:00

In 1965, psychologist Bruce Tuckman developed a model (Tuckman’s Model) that describes the stages of group development, forming and maturing into a cohesive and effective team.

The model initially consisted of four stages: “forming, storming, norming, and performing,” adding one additional “adjourning” in 1977.

It’s important to note that teams may not always progress through these stages linearly, and they might revert to a previous stage under certain circumstances.

Forming #

In this initial stage, team members are polite, tentative, and unsure about their roles. There is a reliance on the leader for guidance.

Goal: Members are getting to know each other, and there is a focus on defining the team’s purpose, goals, and roles.

Leadership approach #

Provide clear direction and guidance
Clearly define team goals, roles, and expectations
Act as a facilitator, encouraging open communication and helping team members get to know each other.

Storming #

Conflict and disagreement emerge as team members start to express their individuality. There may be power struggles and challenges to the leader’s authority.

Goal: The team clarifies its goals, members learn to resolve conflicts and address differences constructively.

Leadership approach #

Facilitate conflict resolution
Acknowledge and address conflicts constructively
Encourage open and honest communication while guiding the team through the process of understanding and appreciating diverse perspectives

Norming #

Cohesion begins to develop, and team members establish norms and values. Roles become clearer, and there is a sense of unity.

Goal: The team strives to establish norms, values, and a shared understanding. Members learn to appreciate each other’s strengths and weaknesses.

Leadership approach #

Foster collaboration and inclusivity
Encourage team members to establish norms and values collectively
Recognize and celebrate individual strengths, fostering a sense of unity and mutual respect

Performing #

The team is highly functional, with a focus on achieving its goals. Members work collaboratively, trust each other, and are mutually supportive.

Goal: The team is committed to its common purpose and operates at a high level of efficiency and effectiveness.

Leadership approach #

Empower autonomy and trust
Provide opportunities for team members to take ownership of tasks and projects
Foster an environment where individuals feel confident in their abilities and can collaborate seamlessly

Adjourning (or Mourning) #

This stage involves the completion of the task or project. Team members may experience a sense of loss as the group disbands.

Goal: Acknowledge and celebrate the team’s achievements, provide closure, and reflect on the overall experience.

Leadership approach #

Acknowledge achievements and provide closure
Recognize the team’s accomplishments and express gratitude for individual contributions
Facilitate a reflective session to capture lessons learned and create a positive closure experience

To develop a team to a high-performance level using Tuckman’s Model, leaders should be aware of the stages and adapt their leadership style accordingly.

This involves providing guidance and structure during the forming stage, facilitating conflict resolution during storming, fostering collaboration and communication during norming, empowering autonomy during performing, and recognizing achievements during adjourning.

Regular communication, team-building activities, and constructively addressing conflicts are crucial throughout the process.

Video summary #

Crucial Conversations

2023-10-31T00:00:00+00:00

When stakes are high, opinions vary, and emotions run strong, you have three choices: Avoid a crucial conversation and suffer the consequences; handle the conversation badly and suffer the consequences; or read Crucial Conversations and discover how to communicate best when it matters most.

If you don’t talk it out, then you’ll act it out.

Chapters #

Know your heart
Ensure safety
Beware of reverting to your style under stress
Make the content safe
Control your emotions
Share your stories
Move from conversation to results

Key takeaways #

A crucial conversation is a confrontation you need to handle with care, which usually is characterized by three factors:

Stakes are high
Opinions vary
The parties involved have strong emotions

Examples:

Calling a client who didn’t pay their invoices
Talk to your boss about a promised promotion that is being delayed
Confronting a teammate who is not doing their share of the project
Talking to your siblings about your parent’s inheritance

Navigating through a crucial conversation is like defusing a bomb. Touch the wrong button or hit the wrong wire, and you create an explosion of emotions. The key is to have an honest and productive dialog to work out the situation.

These are unplanned conversations, and we tend to avoid them because we believe that we are going to make it worse. We tend to react negatively because we are humans, and human beings “behave their worst at the most critical moments.”

The “Story” #

Everybody walks into a crucial conversation with a story. Examples:

My mate doesn’t care about the project because they don’t come to the meetings
My boss doesn’t care about my career because they haven’t given me a promotion

If you approach a crucial conversation with a story in mind, there is no room for dialog, because your mind already made it up.

When… I… framework #

To create the space for a dialog, you need to start assuming you don’t know the whole story, and that you need the help of the person you are talking to. You can use: When... I... Example:

When [you don’t show up to team meetings], I [fear you don’t care about this project].

Invite them to share their own When...I..., so you can discover together what might be the issue, misunderstanding, or misalignment between you two.

The key is to avoid being passive/aggressive, but rather assertive, and honest with facts. This will help reduce the chance of being defensive and willing to help clarify the situation.

Common goal #

To avoid a confronting hit and get back to a productive dialog, you need to convince the person you’re talking to that you’re not their opponent or enemy, you are on the same side. To do this, you must communicate a common goal, value, or purpose.

I don’t want to fight. I just want to find a way for both of us to get [common goal/purpose].

I know we both care about [common value], let’s see if we can both get what we want.

Make a good-faith guess. The more you engage in productive dialog, the more chance you have to find agreements, and the more luckily you will work together to resolve the problem at the heart of a crucial conversation.

Keynote: Mastering The Art of Crucial Conversations #

Video Summary #

Unhealthy Working Environment

2023-10-11T00:00:00+00:00

An unhealthy working environment can have various symptoms that negatively impact employees’ physical and mental well-being.

While writing about The Peter Principle, I mentioned: “Talk to each other. If you feel you can’t, that’s a symptom of a non-healthy working environment, and that’s something more significant to deal with.” But what are those symptoms?

Symptoms #

From all possible symptoms, these are the ones that I would highlight: High stress, poor communication, lack of recognition, micromanagement, lack of work-life balance, unfair treatment, lack of growth opportunities, unhealthy conflicts among colleagues, lack of clear goals and expectations, high turnover rates, low morale and motivation, and constant physical or emotional tiredness.

Let’s go one by one.

High stress #

Excessive stress and pressure. This can be due to heavy workloads, unrealistic expectations, or a lack of support.

Poor communication #

Ineffective communication, whether it’s between colleagues, teams, or between management and employees, can lead to misunderstandings, frustration, and unhealthy conflicts.

Lack of recognition #

When employees feel that their efforts are not acknowledged or rewarded, it can lead to feelings of demotivation and reduced job satisfaction.

Micromanagement #

Overly controlling management styles can stifle creativity and autonomy, leading to frustration and decreased job satisfaction.

Lack of work-life balance #

A healthy work-life balance is essential for employee well-being. Long working hours, excessive overtime, or unrealistic expectations can lead to burnout and reduced productivity.

Unfair treatment #

Discrimination, favoritism, or unequal opportunities can create a toxic and divisive atmosphere among employees.

Lack of growth opportunities #

When employees feel that there is no room for advancement or professional growth, they may become disengaged and unfulfilled in their roles.

Unhealthy conflicts among colleagues #

Constant disagreements, conflicts, or a hostile atmosphere among colleagues can create a toxic working environment.

Lack of clear goals and expectations #

Employees need clear guidance on their roles, responsibilities, and performance expectations. Unclear or constantly changing goals can lead to confusion and frustration.

High turnover rates #

If there is a constant stream of employees leaving the company, it may be a sign that the working environment is not conducive to long-term employment.

Low morale and motivation #

When employees are consistently demotivated or have low morale, it can lead to decreased productivity and a negative atmosphere.

Constant physical or emotional tiredness #

Prolonged exposure to a non-healthy work environment can lead to physical and emotional exhaustion or even mental health issues.

It’s important to note that these symptoms can vary from one workplace to another. Addressing these issues promptly and effectively is crucial to create a healthy and productive environment.

What can you do about it? #

Yourself #

Embrace the change Who moved my cheese?
The process itself is the goal How to focus and have self-discipline
Have you always been like this? How to find a balance of growth and happiness

Your managers and leaders #

Great leadership Leadership starts within your own life and behaviour
Understanding people Misunderstandings, effective communication, and self-reflection

The Peter Principle

2023-09-30T00:00:00+00:00

A person who is competent at their job will get promoted to a position that requires other skills. If they lack the skills for the new role, they will be incompetent at the new level, and will not be promoted again.

If the person is competent in the new role, they will be promoted again and will continue to be promoted until reaching a level at which they are incompetent. Being incompetent, the individual will not qualify for promotion again, and so will remain stuck at this final placement or Peter’s plateau.

There are incentives at play. People work hard to reach a particular position or salary. Once they achieve that, some get lazy. Once people lose passion, they stop learning. They might fail to keep up with new developments, which might lead to poor work quality. To protect their comfort zone, they challenge any new idea or person that could make their life unconformable. Incompetent employees are often unhappy.

Have you experienced the Peter Principle? #

I’ve seen this several times during my 10-year career, working in different companies with people in various departments at different levels. It’s indeed more dangerous than it seems because it can kill the spirit of a healthy environment and company.

Creating awareness about this can help you to be cautious to avoid this from happening to yourself, or at least trigger warnings when you feel this might be happening to you.

What can you do about it? #

If you can recognize this situation within your company, I recommend helping to create awareness about it. Talk to each other. If you feel you can’t, that’s a symptom of an unhealthy working environment, and that’s something more significant to deal with.

If you are the one experiencing this in “first person,” I would recommend you:

Talk to your manager; ask for training, mentoring, or whatever you need to get the skills you lack, from confidence, communication, or anything that could help your new role. Maybe you didn’t get enough or proper training for the new job, which requires different skills.
Consider pivoting back where you were good and keep mastering that, helping and inspiring those next to you. Not everybody has to be promoted all the time.

It's Your Ship

2023-09-20T00:00:00+00:00

“It’s Your Ship” is a leadership book written by D. Michael Abrashoff, a former commander of the USS Benfold, a guided missile destroyer. The book focuses on Abrashoff’s experiences and the leadership principles he applied to transform the performance and culture of his ship.

Key takeaways #

Empowerment: Abrashoff emphasizes the importance of empowering team members. He believes that when people feel trusted and empowered, they take ownership of their work and perform at a higher level.
Listen and Communicate: He highlights the significance of active listening and open communication. He made an effort to listen to his crew members, seek their input, and address their concerns. This helped build trust and fostered a culture of open dialogue.
Lead by Example: Leaders should set the standard through their own actions. He worked hard to be a positive role model for his crew, demonstrating the behavior and work ethic he expected from them.
Delegate Responsibility: Abrashoff encourages leaders to delegate authority and responsibility. By giving his crew members more control over their areas of expertise, he allowed them to take ownership of their roles.
Foster a Culture of Innovation: Abrashoff promoted a culture of continuous improvement and innovation. He encouraged his crew to suggest and implement changes that would enhance efficiency and effectiveness.
Celebrate Achievements: It is important to recognize and celebrate the achievements and contributions of team members. This recognition serves as positive reinforcement and motivates individuals to continue performing at a high level.
Take Calculated Risks: Abrashoff was not afraid to take calculated risks in order to achieve better results. He was willing to challenge established procedures and norms when he believed it would lead to improvements.
Build Trust and Respect: Trust and respect are foundational elements of effective leadership. Abrashoff worked to build strong relationships with his crew members, which created a sense of camaraderie and mutual trust.
Adaptability and Flexibility: In a rapidly changing environment, leaders need to be adaptable and flexible. Being able to adjust to new circumstances and make quick decisions is crucial for success.
Continuous Learning and Improvement: A mindset of continuous learning and improvement is crucial. He encouraged his crew to seek out opportunities for professional development and to always strive for excellence.

Overall, “It’s Your Ship” provides valuable insights into leadership principles that can be applied in various organizational settings.

Abrashoff’s approach emphasizes the importance of empowering and valuing team members, fostering open communication, and constantly seeking ways to improve performance.

How Do You Get Everyone on Board?

2023-08-02T00:00:00+00:00

I was invited to the WeAreDevelopers World Congress to give a tech talk about my experience with XP and the profound benefits of embracing change in your work and life.

With more than 12k attendees, 300 speakers, and ~10 tracks in parallel, I was invited to give not one but two talks. One is about my experience with Extreme Programming and the profound benefits of embracing change in your work and life.

I especially enjoyed the audience engagement and feedback they gave me after each talk. In particular, a question I had faced many times during my career: “How do you deal with people reluctant to change?”

This is one of the most complex topics affecting any team, regardless of their profession. But, especially in our constantly changing software industry, if you are reluctant to embrace change, you will do more harm than good to your team, career, and yourself.

As stated in Peopleware, “our software profession is less about computers and more about humans and their interactions”. This is usually the root problem for people; it’s a human problem first.

To become truly agile, you must have a good foundation of trust among your peers. Without trust, there is no team, and the primary responsibility of a good leader is to help create a trusted environment without fear of healthy conflicts. Everyone feels they can speak and express freely in a safe environment.

A safe environment means you don’t need to carry on armor the whole day to protect yourself from others, so you will have more energy to drive excellence in your workplace.

But still, despite your effort to create a trustable and safe environment, you might encounter people reluctant to change. For those, you might need to try different approaches. How can you help create trust among everyone?

Don’t be afraid of failure; instead, think that everything you do is an experiment from which you will learn something. And anything that brings you closer to a better state is better than nothing.

The key here is to find a way to connect with people by understanding how they understand their potential so you can empower them and help them grow.

Grant time for reading #

1:1 meetings are ideal for establishing personal connections with your peers. However, you might feel that the situation requires an additional push, especially if you have someone who doesn’t like to speak about themselves, and it is hard to know what they think about what’s happening.

Here is an idea you could try:

Give them a book containing ideas or knowledge that could benefit the whole.
Allow reading this book during work time, eg: on Fridays after lunch. This is a company investment for the development of your team.
The book should be read in 3-4 hours, or a couple of Fridays, depending on the number of pages.
Don’t wait until the book is finished to talk about it. Follow the progress.
You will have great topics to discuss during your next 1:1.

You could use any book for this exercise #

Any book would be fine. Still, if you are looking for great examples, these are my favourite three to start thriving a conversation:

Who moved my cheese? is a metaphor of the different attitudes that people adopt as part of their identity in life when they have to confront any change.
Extreme Programming Explained contains a compilation of values, principles, and practices highly related to the human touch in our software industry. Focusing on the team aspect, collaboration with your peers, and creating a sense of mastery and purpose in our craft.
Start with Why addresses the importance of starting with “Why?” in order to define a purpose for anything we do.

Experiment with any book, timeframe, person, or group to create a shared understanding of the team’s foundational values and motivations. The goal is to engage in active knowledge-sharing while cultivating a team that feels they belong, fostering passion at work. This will help create trust, and you can start building on top of it.

If you are looking for books to help scale up your leadership skills, there you go: “Great Leadership”.

You cannot force people to change. On the contrary, the more you try to force it, the harder they will make it for you. Instead, focus on understanding them by acknowledging what they feel and thinking about what they do to create a common ground of understanding each other.

Photos from me at WeAreDevelopers World Congress, Berlin 2023.

The Blocksize War

2023-06-20T00:00:00+00:00

This book covers Bitcoin’s blocksize war, which was waged from August 2015 to November 2017. On the surface the battle was about the amount of data allowed in each Bitcoin block, however it exposed much deeper issues, such as who controls Bitcoin’s protocol rules.

This book explores some of the major characters in the conflict and includes coverage, from both the front lines and behind the scenes, during some of the most acute phases of the struggle.

The account in this book includes discussions with the key players from both sides during the war, exploring their motivations, strategy and thought processes as the exhausting campaign progressed and developed.

Chapters #

First strike
March to war
Scaling I - Montreal
Scaling II - Hong Kong
SegWit
Lightning network
Bitcoin Classic
Hong Kong Round table
Faketoshi
The DAO
Scaling III - Milan
Bitcoin unlimited
Exchanges
ASICBoost
Dragons’s Den
Litecoin
User - Activated softfork
New York agreement
Bitcoin Cash
SegWit2x
Victory

Summary #

Effective Remote Work

2023-04-17T00:00:00+00:00

An effective remote work environment is about treating everyone as remote, with everyone in mind having the same level, equality, and information.

Part 1 - Getting oriented for remote work #

It covers the foundation for a possible remote work environment. It seems a bit common sense nowadays, especially after the covid hit, where we had no choice but to work remotely for more than a year. But I think it’s still good to see this foundational knowledge written to polish assumptions in the following chapters of the book.

Chapters #

A remote future: A brief history of the future. Lockdown. Remote is here to stay. Time to get set up.
Getting set up: The office: what we want and what we don’t. The basics, briefly. In the real world. Installing mental scaffolding. The golden rule.

Part 2 - Building effective remote teams #

Most likely, we all had the experience of casual remote work (before remote work was even a trend) when we felt that we were apart from the team dynamics when we were doing remote work for some reason. This is precisely why “treat everyone as remote” is so important - when at least one person works remotely.

There are different ways to communicate depending on the urgency, intention, and how long and easy that message should be accessible. It’s about sync/async communication with our peers.

Highly related to the previous paragraph, the quality of our messages should be considered when aiming for effective communication. We need to consider the right tools. A phone call is different from a chat message or an email. Use the right tools for the right messages within the proper context.

Chapters #

Treat everyone as remote: Out of sight, out of mind. A principle for cultural change. Taking practical action. Let’s build a model!
The spectrum of synchronousness: Synchronousness. Permanence. Restoring your humanity. Onward to Hyrule.
The same but different: A normal day in the office. Through the magic mirror. Conquering the dark world. Let’s discover some artifacts.
Artifacts for a better future: Comparing artifacts. Written artifacts. Codebase and recorded artifacts. Getting on board with onboarding.
Onboarding and orientation: The contribution curve. The onboarding equation. And here’s the trick. Considering communication.
Effective communication techniques: Why humans communicate. Principles for better remote communication. Techniques to improve interactions. The right tools and when to use them. Turning inwards.
Managing yourself: An organizational bedrock. On being unobserved. Riding peaks and troughs. From yourself to teams.
Managing teams: The output equation revisited. Shrinking the scale factor. Supercharging the scale factor. Time to take it up a level.

Part 3 - Creating a world-class remote culture #

Even though a fully remote company might not be possible for some reasons out of our control, if the company claims to be remote-friendly, there are some aspects that we can consider:

Do you treat everyone as remote?
Do you provide a remote work-space setup?
Do you spend money equally on in-office and remote staff?
Do you optimize for asynchronous communication?
Do you create artifacts from synchronous interactions?
Do you measure staff by their impact?
Do you allow staff to choose flexible hours?
Are the members of the executive team remote workers?
Do you use the best collaborative tools that money can buy?
Do you hire staff anywhere in the world?
Do you support families as well as employees?
Do you give back to an employee’s local community?

This is a “Joel Test version for a remote working environment”. The Joel Test originated in the year 2000, during the dot-com bubble; a test to rate the quality of teams with “yes/no” questions. If a team can answer each question wit a yes, they’re likely a productive team. Read more about the original Joel Test.

Chapters #

The remote working test: The joel test. Twelve questions about remote working. Making changes in your company. Something to guide us.
Creating a handbook: The GitLab handbook. Creating a handbook for your team. A handbook for the company. Fully making the shift.
Becoming fully remote: The spectrum of remoteness. The challenge of retrofitting fully remote culture. The triangle of transition. Learning from trailblazers. Now the difficult stuff.
The hard parts: Walking the curves. The physical and mental impact of working remotely. Supporting other remotely.
The path to equality is remote: Diversity and inclusion. Remote: The great leveler. This is just the beginning.

Book summary #

Great Leadership

2023-02-27T00:00:00+00:00

As business scales, the leaders’ primary focus must shift from customers to employees. Therefore, I would like to share what I consider critical points that any leader should address and focus on regularly.

For each key point, you will have book recommendations that go deeper into the matter, giving you references from real experts behind them.

I already wrote about the beauty of leadership, and as a quick recap, to become a leader, you need specific skills:

Excellent communication, giving support, and enabling your people
Leading by example, especially to become a better self
Passion for sharing your leadership skills, so you build other leaders

To extend the previous post providing resources and examples, in this one, you will find books about the following topics:

Motivation
Leading through change
Empowering your people
Effective communication
Persuasion
Team dysfunctions
Management principles
CEO Mindset
Engineering leadership

For “starting” leaders #

Motivation #

First of all, you need to define a purpose for your leadership. I would recommend “Start with Why”, as this can help you clarify the difference between great leaders and those who are not.

“The ability to inspire those around you and to achieve remarkable things starts with WHY.” - Start with Why

You need to be aware that leadership is not about being the boss of anyone but serving others. It would help if you were a role example that your people would copy and follow, especially in hard times. This is a leadership philosophy in which the leader aims to serve. “Leaders Eat Last” goes deeper into this topic.

After reading the previous two books, if you are looking for more, the cherry on top is “The infinite game”, which is the third and last book (so far) by Simon Sinek. This book questions our daily mindset when confronting (business) problems. It’s about the need of a just cause, courageous leadership, trusting teams, and a worthy rival.

“There is no such thing as the one “right” organization. There are only organizations, each of which has distinct strengths, distinct limitations, and specific applications. An organization is not absolute. It is a tool for making people productive in working together.“ - The infinite game

Leading through change #

Leading through change is something you have to face in many moments in your life, whether you like it or not. “Who moved my cheese?” is a tale about the different attitudes people adopt as part of their identity when confronting change.

How do you eliminate bad habits and start creating good ones? “The Power of Habit” and “Atomic Habits” are great books that help you understand that habits are like a muscle. You can train them.

“Change how you identify yourself. The environment is more important than being motivated. Reduce friction for good habits and increase friction for bad habits.” - Atomic Habits

Empowering your people #

It would be best if you empowered your people to become leaders themselves. A great book I recommend is “Turn the ship around!”, in which the author challenges the commonly accepted leaders vs. followers model into a leaders-to-leaders relationship.

“Leadership is communicating to people their worth so clearly that they are inspired to see it in themselves.” - Turn the ship around!

Effective communication #

Communication is one of the most challenging skills you need because you constantly communicate with other people; with different backgrounds, experiences, expectations, and even understanding of life. And the important key aspect is not just what you say but how you say it to ensure your desired message is correctly delivered to the receiver.

“Leadership is Language” challenges the industrial-age playbook (where leaders give commands and employees follow them), giving you strategies that can help you such as: control the clock, collaborate, commit, complete, and improve.

“Your words matter more than you think.” - Leadership is Language

It is important to recognize our emotions and not let them control our actions. Creating an open, honest, and safe environment is crucial to create trust among your peers.

“Dare to lead” addresses that leaders need to be more vulnerable. It shows that solid values guide you to do what is correct rather than easy. The importance of trust and difficult conversations even when they make you uncomfortable.

“Great leaders must be brave and always dare to provide constructive feedback, speak the truth, and be clear about their expectations.” - Dare to lead

Persuasion #

Regarding communication, you might need some good persuasion skills to convince others about your ideas. “Never split the difference” is a book about negotiation (from one FBI’s lead international kidnapping negotiator) that gives you great insides into how to negotiate effectively: negotiation begins with listening, using mirrors to encourage the other side to empathise, tactical empathy to getting an agreement, labelling emotions, among others.

“Negotiation begins with listening, making it about the other people, validating their emotions, and creating enough trust and safety for a real conversation to begin.” - Never split the difference

For “experienced” leaders #

Assuming you have read the books above (for “starting leaders”) I can give you more recommendations.

Team dysfunctions #

One of the most difficult areas from the communication layer is dealing effectively with conflicts; so “The Five Dysfunctions of a Team” is a great book which addresses the “absence of trust, fear of conflict, lack of commitment, avoidance of accountability and inattention to results” as a pyramid of dysfunctions that you need to pay attention.

Management principles #

Although leadership is not the same as management, I find it quite useful knowing some theory behind management, and for this “High Output Management” is a great starting point.

After that one, if you want more, I can recommend something more advance with “The Essential Drucker”, which addresses the essential principles of management.

“Management is about humans.” - The Essential Drucker

CEO Mindset #

Although not every leader might want to be a CEO, I find “The Great CEO Within” a great book because this can help you understand the responsibilities from any organization’s most abstract point of view.

Similarly, “Adapt or Die” is a great book that covers the fundamental aspects of overall responsibilities and capabilities to thrive in any business, addressing aspects such as Product, Strategy, Growth Engine, Financial Model, People, Operations, Process, and Leadership.

“Leadership is about helping people adapt and leading through change so the business and its people can thrive.” - Adapt or die

Engineering leadership #

Related to engineering and growing, I also recommend “The Manager Path”, and “The Art of Leadership”, both great books; easy to read and full of wisdom.

“Managers tell you where you are; leaders tell you where you are going.” - The Art of Leadership

I hope I got enough attention to create awareness about the key areas you must work on. I am aware that many other books could be included in this list. You might have others on your shelf. These are just a reference, not necessarily better or worse than others.

I still have many other books I want/will read over time. Still, I thought it would be interesting to compile these already, aiming to create value, sharing especially for those who don’t know where to start or how to become better leaders themselves.

However, these are the essential points to remember:

You need to have passion for your work and share this passion with the people around you. You cannot expect passion from your peers if you don’t have passion for what you do.
You need to empower your people, creating leaders instead of folks who follow orders from their superiors.
You need to learn how to create a safe environment, which is crucial for trust and honest relationships.
You need to help create agreements when dealing with conflict resolutions. Avoiding healthy conflicts doesn’t help long-term relationships.
You have to look for opportunities to grow everywhere and help our team grow with you.

Your primary responsibility is to help others improve, and this is only possible if you embrace the change and start with yourself.

All mentioned authors #

Simon Sinek: Start with Why, Leaders Eat Last, The infinite game
Spencer Johnson: Who moved my cheese?
Charles Duhigg: The Power of Habit
James Clear: Atomic Habits
L. David Marquet: Turn the ship around!, Leadership is Language
Brené Brown: Dare to lead
Chris Voss: Never split the difference
Patrick M. Lencioni: The Five Dysfunctions of a Team
Andrew S. Grove: High Output Management
Peter F. Drucker: The Essential Drucker
Matt Mochary: The Great CEO Within
Thomas H. Douglas: Adapt or Die
Camille Fournier: The Manager Path
Michael Lopp: The Art of Leadership

Extra: Leadership Guide for the Reluctant Leader #

Especially if you are a software developer, this video is for you.

“Leadership is for everybody. It is for all y’all.”

Adapt or die

2023-02-26T00:00:00+00:00

Told through the story of one bold company (People First IT), Adapt or Die takes readers through the unparalleled business system known as The Algorithm of Success that has the potential to inspire, ignite, and affect change for all aspects of an organization.

Each chapter reveals more of the winning formula that all small and midsize businesses absolutely must have to succeed. Through real examples, research, and practical tools, Adapt or Die unpacks exactly how to create innovation, solve people puzzles, and win in business.

“Leadership is about helping people adapt and leading through change so the business and its people can thrive.”

Why businesses fail? #

Businesses fail because they…

are unable or unwilling to have courageous conversations
focus on money too much or too soon instead of on people
can provide the value themselves but can’t make it scale
fail to focus on people as their primary responsibility
focus on people, but don’t have the necessary skills to make a difference
listen to respond instead of listening to hear
think that because their idea is unique and specific, so are their issues
live in the business and fail to spend time on the business
expect thing to happen without truly leading through change
fail to fall in love with the truth and fight the truth instead

How to help growing your teamwork #

“As a business scales, the primary focus of the owner and the leadership must shift from focusing on customers to focusing on employees.”

By having courageous conversions about the full spectrum of skills required to go to the next level, focusing on improving the personal and professional career experience for that person and the people around them.

These are the main points that everyone could develop:

Good communications
Focus & achieve goals & results
Everyone contributes
Offer each other support
Good leadership
Clear and good organization
Constructive conflict drives innovation

“People is not usually the root problem. The taxonomy is 3Ps: product, process, or people. And “people” is the final step because leaders need to look at product and process first. In other words, “people first” when it comes to values, but “people last” when it comes to blame.“

The Algorithm of Success #

As you can see in the diagram, all of this comes under leadership. If leadership is about helping others adapt to change, then it must be core to our organizations.

Product #

Promises
Solve a problem or need
Cash release triggers
The way we create value
Pain or Pleasure
Innovation
Connections: Logical, emotional and competitive

Strategy #

Target customer profile (Who)
Value Creation Strategy (VCS)
Core Values
Shared vision
Value loop
Key processes

The Growth Engine #

Unique selling proposition
Targeted marketing
Sales channels
Sales steps
Measuring the Growth Engine
Funnel & opportunity management
Return on Sales

The Financial Model #

Revenue management
Cost of goods sold (COGS)
Sales and marketing costs
General administration
EBITDA, ITDA, NOI
Categorization
Reporting

People #

Alignment
People elevators
Problem solving
People banks
Leadership code of conduct
Career plans
One-on-one’s
Income managements

Operations #

Identify the core operations
Responsibilities
Cadence management
Meetings
GSD (Get Shit Done)

Process #

Promises Kept
Downstream / Upstream
Accountability
Repeatable
Efficiencies

You can find the book in https://www.adaptordie.com/the-book/.

The infinite game

2023-01-29T00:00:00+00:00

How do we win a game that has no end? Finite games, like football or chess, have known players, fixed rules and a clear endpoint. The winners and losers are easily identified. Infinite games, games with no finish line, like business or politics, or life itself, have players who come and go. The rules of an infinite game are changeable while infinite games have no defined endpoint. There are no winners or losers: only ahead and behind.

Infinite-minded leaders understand that “best” is not a permanent state. Instead, they strive to be “better”. “Better” suggests a journey of constant improvement and makes us feel like we are being invited to contribute our talents and energies to make progress in that journey.

The question is, how do we play to succeed in the game we’re in? In this book, Simon Sinek offers a framework for leading with an infinite mindset:

Just Cause
Courageous leadership
Trusting teams
Worthy rival

#1 You have to have a Just Cause #

A Just Cause is the answer of Why your organization exists?

A cause so just that people will be willing to sacrifice themselves to see the advancement of that cause. Eg: working more hours, giving your best ideas, or rejecting another job offer and staying here because you believe in what you are doing.

In order to be happy, we need a sense of purpose or meaning; businesses are no different. When we look at developing a Just Cause, there are a few things that we need to articulate. Firstly, we must stand for something that’s inclusive, and exists primarily for the benefit of others.

In short, a Just Cause is a vision of a compelling future, making people want to be part of building this future, although they may never see it completed.

#2 You have to have courageous leadership #

Courageous leaders are the ones that are willing to sacrifice the sort term in order to advance the long term.

Leadership is the acceptance of the responsibility to create an environment in which people can work on their natural best.

The senior most people in an organisation are not responsible for the result. They are responsible for the people that are responsible for the result.

#3 You have to have trusting teams #

A trusting team is an environment in which people feel safe to raise their hand and say “I made a mistake. I don’t feel qualify to do the job you asked me to do, and I need more training. I need help. I am scared.” Without any fear of humiliation or punishment, whatsoever.

If you don’t have trusting teams, you have a group of people that work together lying and faking, and you’re forcing them to. It’s not their fault. You’re creating an environment in which people will not share mistakes because they think it will make them in trouble. Which means eventually things will compound and break.

It’s the responsibility of the leader to get the environment right. Get the environment right, you’ll get trusted teams. Get the environment wrong, you are forcing people to protect themselves from you.

#4 You have to have a worthy rival #

Although the only true competitor in an infinite game is yourself, what competition does is help to reveal your weaknesses.

The goal is not to be number one in the infinite game, because there is no such thing. It’s about building a strong foundation. It’s about looking long term.

Money is a result, not a purpose.

There is no such thing as the one “right” organization. There are only organizations, each of which has distinct strengths, distinct limitations, and specific applications. An organization is not absolute. It is a tool for making people productive in working together.

Leaders who embrace an infinite mindset build stronger, more innovative, more inspiring organizations. Ultimately, they are the ones who lead us into the future.

The Essential Drucker

2022-10-29T00:00:00+00:00

A twenty-six selections on management in the organization, management and the individual, and management and society.

It covers the basic principles of management and its problems, challenges, and opportunities, giving managers, executives, and professionals the tools to perform the tasks that the economy and society of tomorrow will demand of them.

4 Essential Principles Of Management #

Management is about humans
Management should define an organization’s values, objective, goals & mission
Management must enable the organization and members to grow and develop
Results only exist outside the organization

Dare to lead

2022-09-30T00:00:00+00:00

Leadership is not about titles, status, and power over people. Leaders are people who hold themselves accountable for recognising the potential in people and ideas and developing that potential. This book is for everyone ready to choose courage over comfort, make a difference, and lead.

Courage and vulnerability #

Leaders need to be more vulnerable #

The problem is that most people associate that vulnerability as a synonym for weakness, but that’s not true.

“Vulnerability is the universal human emotion we feel when we expose ourselves to others during times of risk or uncertainty.”

And this is what the core of leadership is about: the courage to act how we should despite fear, uncertainty, or danger in our way.

Values #

The modern workplace might feel like a “gladiator arena.” While it might not be a matter of a life-dead situation, it still requires bravery, and plenty of sweetness and tears, to the point that we can feel so overwhelmed that we are tempted to leave. So, according to Brené:

“One of the most significant sources of motivation for sticking it out is to be crystal clear about our core values.”

Values are the ideals that we have that bring purpose to what we do in our life. They guide us and give us something to hold on to during dark and difficult times. Strong values guide us to do what is correct rather than easy.

Honesty #

A great leader encourages potential in people and possesses the courage to guide this potential as it develops. One of the critical skills for doing this is courage and the ability to deliver honest and open feedback.

Unfortunately, many leaders are afraid to give tuff feedback and leave their employees in the dark. Yes, sometimes the truth hurts, but we often avoid difficult conversations because they make us uncomfortable.

“Great leaders must be brave and always dare to provide constructive feedback, speak the truth, and be clear about their expectations.”

In the long run, this is kinder and more productive.

Trust #

“Trust is an essential aspect of our working relationships.”

7 behaviours that encourage trust #

Expressed together with the acronym: BRAVING

Setting Boundaries - respect one another’s boundaries
Reliability - which means to follow-up words with actions
Accountability - being responsible and acknowledging mistakes
Vault - the ability to keep confidential information private
Integrity - choosing courage over comfort
Non-judgment - talk to one another without judgment
Generosity - assuming that people meet you with the best intentions

Failure #

The ability to fail and recover from it is an essential skill for any great leader. Fear of failure holds us back and stops us from achieving true greatness.

It is crucial to take off the armor of perfectionism and jump into the uncertainty of life. Only this way do we indeed gain the courage to succeed and lead.

Summary #

The Beauty of Leadership

2022-09-25T00:00:00+00:00

Leadership is not a synonym for management, it has nothing to do with titles or personal attributes. So, what is it? How can we become leaders? And most importantly, why?

While researching this topic, I found “What is leadership” by Kevin Kruse, which I liked particularly. I thought about sharing the key takeaways from that blog post as it expresses very well the general points about what is and what is not leadership.

What is not leadership? #

Leadership has nothing to do with titles. Just because you have a C-level title, doesn’t automatically make you a “leader”. You don’t need a leading title to become a leader.

Leadership has nothing to do with your personal attributes. Leadership is not an adjective. You don’t have to be an extroverted charismatic person to practice leadership.

Leadership and management are not synonymous. Management needs to plan, measure, monitor, coordinate, solve, hire, fire, etc. Managers manage things. Leaders lead people.

What is leadership? #

“A leader is someone who has followers.” Peter Drucker.

This definition is too simplistic and can be dangerous. Just because you have “under you” some people that do what you say simply “following orders” doesn’t mean that you are a leader. You might be a commander, but not necessarily a leader.

“The capacity to translate vision into reality.” Warren Bennis.

Every sprint, you envision fruits in your garden. And you work towards it and make that happen. This makes you a gardener, not a leader.

“Leaders will be those who empower others.” Bill Gates.

Empowering others is essential, but it’s missing the vision or common goal.

“Leadership is influence.” John Maxwell.

A manager has the power to fire team members, which provides a lot of influence. Same as a robber with a gun who has “influence” over their victims. We are missing the source of influence.

So, what about combining them all? #

“Leadership is a process of social influence, which maximizes the efforts of others toward the achievement of a goal.” Kevin Kruse

Key elements of this definition:

Leadership starts from social influence, not authority or power
Leadership requires others, not necessarily direct reports
It includes a goal
No mention of a title or attributes of any kind

End from the key takeaways by “What is leadership” by Kevin Kruse.

Why would anyone want to become a leader? #

We need to make clear that there are two different conceptions when asking that question, and we need to separate them from the beginning.

There is the “leader title” aspect, which is usually attached to the management position. I am not talking about that one. You can be a great manager and an appalling leader.

A leader is a person with the multiplier factor attitude that wants to develop specific skills (related to their social influence) to boost even more the value they produce.

So, can anyone become a leader? What are those skills that you need to be a leader?

Can everyone become a leader? #

Now that we found a definition of leadership, we can agree that this definition could have different degrees applied depending on the type of person and responsibilities they want.

However, to become a leader, you need specific skills. These are the ones I find the most important:

Excellent communication, giving support, and enabling the people around you
Leading by example, especially to become a better self
Passion for sharing your leadership skills, so you build other leaders

Leadership starts within your own life and behaviour.

I am aware that not everyone might want to accept the necessary changes to become a leader, but I truly believe everyone can grow certain leadership skills to some extent, which also means inspiring the people around you.

How to become a better leader? #

You can get inspiration from a lot of different sources. While it’s true that you can learn a lot from your own mistakes and successes, and even from the people around you, I think it’s very optimal to listen to the wisdom from other people’s experiences outside your circle. For example listening to podcasts, ted-talks, books, or even audiobooks.

The beauty of leadership is that it asks for no permission. No title, no promotion, no org chart. It begins the moment you decide to lift the people around you.

The Great CEO Within

2022-08-01T00:00:00+00:00

Matt Mochary coaches the CEOs of many of the fastest-scaling technology companies in Silicon Valley. He shares his highly effective leadership and business-operating tools with any CEO or manager in the world.

Learn how to efficiently scale your business from startup to corporation by implementing a system of accountability, effective problem-solving, and transparent feedback.

Reading, talking to other experts in a particular area, practicing, and teaching are the best ways to learn and improve yourself.

3 Key takeaways #

You need to learn how to manage yourself before you can manage your business.
Don’t ignore conflict. Be transparent, give and take feedback often, and be an active listener.
Be obsessed with learning about your customer. Do so by asking better questions.

Summary #

The team #

Do not create a 50/50 partnership, because despite it sounds ideal, it actually leads to real pain if there is no easy way to break a deadlock.
Find a partner who has complementary skills to yours. Give a large percentage of the company; it worth it.
Founding teams should never grow beyong six until there is a true product-market fit (PMF).
Metrics that PMF are important. For example revenue, renewal rates, …

Getting things done #

Read “Getting Things Done: The art of stress-free productivity”, by David Allen.

Inbox zero #

Keep your inbox clean as a single triage room at a hospital.
- It is important to distinguish the urgent cases from the ones that aren’t.

Top goal #

Schedule two hours each day to work on your top goal only.
The earlier in the day you schedule this top goal, the better.

On-time and present #

Don’t waste other people’s time.
If you know you’re going to be late, let the other people know as soon as possible.
Be present and focus on what’s being discussed.

When you say it twice write it down #

Write down all processes. In doubt, write everything.

Gratitude #

Focus on the positives.
We perform our best when we are having fun and feeling good.
Be appreciative. Tell people when they’ve done something good.

Energy audit #

Audit your time and figure out how much of it is spend on activities that energize you and what activities drain you.
- Delegate or outsouce the things that drain you as much as possible.

Health #

Your mental and physical health is the most important resource we all have.
- Take care of yourself and the people around you.

Decision-making #

Require that anyone who wants to discuss an issue write it up, along with the desired solution, ahead of time.
This method, thought time-consuming, yields extraordinarily thoughtful decisions in a very shrt amount of time.

Getting buy-in #

When people feel they are part of the decision and their input matters.
When people are given more influence, they feel more invested.

Issues and proposed solution #

Require that anyone who presents an issue at a team meeting do so in writing.
- It should include both a detailed description of the issue and their proposed solution. They cannot say “I don’t know.” They must at least present a guess.
All issues should be presented at the weekly team meeting.
Allow 5 min to discuss each proposed solution.
- If consensus is reached in that time - great.
- Otherwise, don’t spend more time debating, and use RAPID framework instead.

Loudest voice in the roomo #

Be aware of who is in the room when you have a group discussion.
Avoid influencing other people’s ideas by wriring down their vote or thoughts before you share your perspective.
Let juniors ask and speak first.

Sloppy agreements #

Sloppy agreements are when people don’t show up on time, or don’t complete the goals they declare.
The antidote is “impeccable agreements”:
- precisely defined
- fully agreed to by all relevant people
There must be consequences of breaking agreements.
If you can’t meet the agreement, then you have an obligation to let other members of the agreement circle know asap.

Transparency #

Don’t hide negative information.
Our imaginations are much more powerful than reality.
Share all relevant information with your team, both negative and positive.
- Let them adapt.

Conflict resolution #

Interpersonal conflict is almost due to people:
- Not fully sharing their thoughts and feelings
- Not feeling heard
Prove to people that you have heard them by summarizing what you just said back to you until they say “that’s right!”.

Issue identification #

Ask people to pretend they’re the CEO and answer:
- “What are the 3 most important issues for me to solve in the next 90 days?”
Ask people to write down their thoughts about the company when they feel their joy, excitement, sadness, anger and fear.

Conscious leadership #

Be more interested in learning than been right.

Customer obsession #

Focus on the outcome, not the output.
You are solving a customer problem, not just making a product.

Culture #

You don’t choose your values. You have them.
Use your values as a guide to who you hire and when you fire.
Don’t forget to celebrate. Make an effort to publicly acknowledge achievements.
Don’t measure hours. Measure output.
You prevent office politics by never allowing lobbying to be successful.

Company folder system and wiki #

Have a company wiki and make it mandatory that all new hires read it.
Whenever you find yourself doing something twice, write down exactly what it is that you did.
- Everyone on the team should contribute.

Goal tracking #

Never assign someone an action without them agreeing to it verbally or in writing.

Areas of responsibility #

When more than one person shares a responsibility, it often does not get done well, or at all.
One person is assigned to each function in the company.

No single point of failure #

Write down all processes.
Cross-train a second person for each role.

Key Performance Indicators (KPI) #

Known your 5-6 most significant KPIs and track them religiously. Make them visible to the entire team.

Collaboration #

Set vision and goals for the company, each dept, and each individual.
Communicate that vision and those goals to every team member.
Tracking and reporting progress towards those goals on a regular timetable (usually weekly).
Feedback on what’s going right and what needs to be adapted.

Objectives and Key Results (OKR) #

Target 3 objectives with 3 key results for each.
For the company, department, team, individual.
- Cascade them down so they are in alignment.
The objective = “where do we want to go?”. No necessarily measurable.
Key results = “how do we know that we’re getting there?”. It should be measurable.
Gather your leadership team and have everyone come to the meeting with their ideas for what the OKRs should be for the quarter.
- Let individuals come up with their own OKRs. They will be more invested.

Feedback #

Never give negative feedback using a one-way communication method
- Like email, text, or voicemail.

The problem with no giving feedback #

You won’t notice your company’s problems.
Communication will break down.
Your best talent will leave you.

4 A’s of seeking feedback #

Ask for it.
Acknowledge it - repeat what they said. Make them feel heard and understood.
Appreciate it.
Act on it.

How to give negative feedback #

Ask for permission.
State the behaviour (fact).
State how the behaviour makes you feel (feelings).
State your thoughts, opinions, and judgments around the situation (story).
Make a request - a change you’d lie to see in the future.
Ask if they accept the feedback.

Fundraising #

Pick a partner, not a enterprise.
When you need to speak to an investor, ask 3-5 people in your network who know that person to send an email of recommendation to them.
Stack the referrals close together (in the same week) so that you get noticed.
Talk about your company once you know that the investor likes and trust you.
Sell yourself, not the company.

Recruiting #

Spend as little time as possible with the candidates that you don’t hire, and as much time as possible with the candidates that you want to hire.
As the hiring manager, write out a 90 roadmap for the position you need to fill.

On-boarding #

Give onboarding even more attention, time and energy than you give to recruiting.
Assign each new team member a buddy with whom they’ll check in each day for 15 minutes for the first 2 weeks.

Firing #

Whe you make the announcement, praise the person’s contributions to the company, and take ownership yourself for the fact that you weren’t able to match their skills to the company’s needs.
Do not blame or criticise the person. Instead, take responsibility for the situation.

Effective sales #

Build trust.
Sell results, not features.
Identify customers’ pains.

Build trust #

Ask customers about them.
- Listen actively and reflect back what they say.
- At the second meeting show that you remember what they said at the first.
Be explicit about not talking about your company.
Ask for a limited amount of time.
Invite them to a purely social event.

Customer development #

Asking the right questions will help you identify customer’s specific challenges.
You need to understand their pain before presenting your solution.
1. What are their goals?
2. What are the challenges preventing them from reaching those goals?
3. What are their ideal solutions to overcoming those obstacles?

Sell results, not features #

Most people don’t care about your product functionality or features. They care about their business results.
Focus on the why.
Focus on painting the vision of a world where customer’s desires are fulfilled with the help of your product.

Building a sales team & pipeline #

Don’t hire sales people right away.
In most cases, sales people will never be able to sell better than the founders, and they won’t be able to sell the product if you are not able to.
Only hire a sales team if:
- You have found an initial version of product-market fit (this means that a significant proportion of your paying customers are renewing their contracts).
- You have figure out what you are selling and who you are selling to.

The structure of a sales team #

Generating leads and closing deals are distinct functions that must be split.
Senior salespeople are expensive, so their time is best spent focusing on the most high-value activity: closing deals.
Ideal sales team structure:
- Qualifiers - sales development reps: focus on generating leads.
- Closers - account executives: focus on closing leads.
- Farmers - customer success: focus on tending existing customers.

Lead generation #

Predictable leads is the first step to achieve predictable revenue.

Marketing #

Start by concentrating all of your efforts on the low-hanging fruit - the small customer segment that has a particular problem that your product solves 10x better than the competition.
Move on to the next customer segment only after you have the resources to do so.

Product market fit (PMF) #

Designing a significantly better solution to your target customers’ problem than existing in the marketplace.
How do you know when you have achieved PMF?
- Ask your customers. They will tell you by renewing their subscriptions, buying more product(s), etc.
B2B, PMF = long term contracts
B2C, PMF = second purchase, renewing subscription, sharing in social media.

Matt Mochary shares insights on developing his coaching method, understanding & overcoming primal fear, addressing imposter syndrome & more.

The Starfish and the Spider

2022-07-19T00:00:00+00:00

If you cut off a spider’s head, it dies; if you cut off a starfish’s leg it grows a new one, and that leg can grow into an entirely new starfish. Traditional top-down organizations are like spiders, but now starfish organizations are changing the face of business and the world.

What’s the hidden power behind the success of Wikipedia, craigslist, and Skype? What do eBay and General Electric have in common with the abolitionist and women’s rights movements? What fundamental choice put General Motors and Toyota on vastly different paths?

Ori Brafman and Rod Beckstrom have discovered some unexpected answers, gripping stories, and a tapestry of unlikely connections. The Starfish and the Spider explores what happens when starfish take on spiders and reveals how established companies and institutions, from IBM to Intuit to the U.S. government, are also learning how to incorporate starfish principles to achieve success.

In this talk, Rod Beckstrom, does a great overview of the main ideas of his book:

The Power of Authority and Obedience

2022-01-24T00:00:00+00:00

Milgram was interested in researching how far people would go in obeying an instruction if it involved harming another person, and how easily people could be influenced into committing atrocities. Eg: Germans in WWII.

The experiment #

During the 1960s, the psychologist Stanley Milgram conducted a series of obedience experiments directly related to the power of authority and obedience, even when they might end-up in fatal ending.

Milgram examined justifications for acts of genocide offered by those accused at the World War II, Nuremberg War Criminal trials. Their defence often was based on “obedience”, that they were just following orders from their superiors. Milgram came up with the experiment to answer this question:

Could it be that Eichmann and his million accomplices in the Holocaust were just following orders? Could we call them all accomplices?

The procedure #

The selected participants for his experiment were by newspaper advertising to take part in a study of learning at Yale University; 40 men were recruited, and in exchange for their participation, each person was paid $4.50.

The participant was paired with another person and they drew lots to find out who would be the “learner” and who would be the “teacher”. The draw was fixed, so that the participant was always the teacher, and the learner was one of Milgram’s confederate (pretending to be a real participant).

The learner was taken into a room and had electrodes attached to his arms, and the teacher and researcher went into a room next door that contained an electric shock generator and a row of switches marked from 15 volts (slight shock) to 300 volts (severe shock) to 450 volts (XXX).

The learner gave mainly wrong answers (on purpose), and for each of these, the teacher had to give him an electric shock. When the teacher refused to administer a shock, the researcher gave a series of orders to ensure they continued:

“Please continue.”
“The experiment requires that you continue.”
“It is absolutely essential that you continue.”
“You have no other choice; you must go on.”

Results #

65% of participants (teachers) continued to the highest level of 450 volts. All participants continued to 300 volts.

Milgram did more than just one experiment. He carried out 18 variations of this study. All he did was alter the situation to see how this affected obedience.

Conclusion #

The simple explanation would be that it was something about them as people that caused them to obey, but a more realistic explanation is that the situation they were in caused them to behave in the way that they did.

Some of the aspects of the situation that may have influenced their behaviour included the location, the behaviour of the researcher and the fact that it was an experiment for which they had volunteered and been paid.

People tend to obey orders from other people if they recognise their authority. This response to legitimate authority is learned in a variety of situations, for example in the family, school, and work.

Milgrams’ agency theory #

Milgram explained the behaviour of the participants by suggesting that people have two states of behaviour when they are in a social situation:

The autonomous state: people direct their own actions, and they take responsibility for the results of those actions.
The agentic state: people allow others to direct their actions and then pass off the responsibility for the consequences to the person giving the orders. They act as agents for another person’s will.

Two things must be in place for a person to enter the agentic state:

The person giving the orders is perceived as legitimate for that.
The person being ordered believe that the authority will accept responsibility for what happens.

For example, when participants were reminded that they had responsibility for their own actions, almost none of them were prepared to obey. In contrast, many participants who refused to go on did so if the researcher said that he would take responsibility.

Milgram experiment variations #

Among many others, these are some of the variations:

Uniform #

When the role of the researcher was taken over by an “ordinary person without a uniform” (always a confederate), the obedience dropped to 20%.

Change of location #

Obedience dropped to 47.5% when the experiment was moved to a set of offices instead of the impressive Yale University.

Two other participants (confederates) were also teachers but refused to obey. One at 150 volts, and the other at 210 volts. The presence of others who are seen to disobey the authority figure reduces the level of obedience to 10%.

Absent experimenter condition #

When the researcher instructed and prompted the teacher by telephone from another room, obedience fell to 20.5%. Many participants cheated and missed out shocks or gave less voltage than ordered. The proximity of authority figure affects obedience.

The moral questions Milgram raised #

Why did so many of the participants in this experiment perform a seemingly sadistic act when instructed by an authority figure? According to Milgram, there are some situational factors that can explain such high levels of obedience:

The physical presence of an authority figure increased compliance.
The fact that Yale (a trusted academic institution) sponsored the study led many participants to believe that the experiment must be safe.
The selection of teacher and learner status seemed random.
Participants assumed that the researcher was a competent expert.
The shocks were said to be painful, not dangerous.

Milgram’s experiment has become a classic in psychology, demonstrating the dangers of obedience. The research suggested that situational variables have a stronger sway than personality factors in determining obedience.

Often it is not so much the kind of person a man is as the kind of situation in which he finds himself that determines how he will act.

Stanley Milgram, 1974.

Resources #

Modern CTO

2022-01-23T00:00:00+00:00

Developers are not CTOs, but developers can learn how to be CTOs.

In Modern CTO, Joel Beasley provides readers with an in-depth road map on how to successfully navigate the unexplored and jagged transition between these two roles. Drawing from personal experience, Joel gives a refreshing take on the challenges, lessons, and things to avoid on this journey.

These are the topics you’ll find in the book:

A Modern CTO knows… #

Developers are not CTOs
The spaghetti code MVP epidemic
Over-engineering is a problem
Whether to hire, buy, or out-build their competitor
How not to scale prematurely
How to solve any problem
How to work with programers when you aren’t one
UX mistakes to watch out for
When to speak up
When to hire & fire consultants
How to analyze failure
How to bounce back from unforeseen constraints
Answer the question: “How difficult is it to code…?”
How to avoid the “bottom of the ninth” guy
When to respond to feedback
How to validate an expert in any field
How to effectively communicate complex ideas

Favorite quotes #

If I rest on past achievements, I’ll never grow.

LEVERAGE OTHERS’ EXPERIENCE Books condense a lifetime of experience into a few hours’ read. Powerful right?

There are only two reasons you write bad code:

1)You know how to write good code, but you choose to write bad code. 2)You don’t know how to write good code. And both suck.

As the CTO, you must have a business focus.

Always return to your core goals. […] I make sure each core goal has a clearly defined “why?” behind it, this way if I ever get lost, I go back to my “why.”

Reference to “Start with Why” by Simon Sinek.

When you’re the boss, remember this golden rule: Ask people what they think instead of telling them what to do.

If I can’t asses the human component, I can’t lead a team. […] Team composition carries as much or perhaps even greater weight than programming expertise.

As CTO, if you can’t explain value simply, it means you don’t understand the business value behind your technology.

Leaders Eat Last

2022-01-16T00:00:00+00:00

A company’s biggest strength doesn’t lie in its products or services. It always lies in its people, and in their ability to cooperate closely and rally behind the organization, especially during a crisis.

However, loyalty and commitment must be earned. Today, work has become a contractual, transactional relationship in many organizations. Intense competition and layoffs are the norm. Hardly anyone believes in loyalty to a company anymore, much less lifetime employment.

The 4 Chemicals (E.D.S.O.) #

Each of us is an individual and a part of social groups. We make daily decisions that require us to weigh our self-interests against group interests. This dilemma also happens in our bodies via 4 key chemicals:

Endorphins and dopamine drive us to satisfy our personal needs, e.g. to find food, develop solutions and persevere through problems. They help us to get things done, so we can survive.
Serotonin and oxytocin encourage us to work together with others. They build feelings of trust, loyalty and camaraderie, strengthen our social bonds and increase our inclination to cooperate with others to achieve what we can’t on our own.

Circles of Safety #

Traditionally, our family provides a Circle of Safety where we feel safe and supported. Inside the circle, we have a healthy balance of E.D.S.O. and low Cortisol levels. In organizations, Circles of Safety provide people with a sense of belonging and security. This facilitates communication, cooperation, problem-solving and innovation, allowing people to direct their attention to external threats and opportunities. In contrast, when people feel threatened by internal politics and infighting, they turn their attention inward to focus on self-preservation, making the group more vulnerable as a whole.

Leaders must earn others’ respect and loyalty by making the most sacrifices and being willing to eat last. They must give trust to earn trust.

A Society that’s Out of Balance #

Each of the 4 E.D.S.O. chemicals play important roles in our survival. When they’re in balance, people prosper the way they’re designed to, and their groups/organizations prosper too. Unfortunately, the modern workplace tends to be overflowed with Cortisol and dopamine addiction. We lack Circles of Safety and have become dangerously imbalanced. How did we get here?

Abstraction and Dehumanization: how management via numbers, global systems and virtual interactions can be dangerous and lead to careless acts.
Destructive Abundance: how humans respond to shortage vs excess, and why/how leaders have become so blinded by the commercial interest that they’ve forgotten who they’re supposed to serve.
Social Changes: how our societal norms and values have changed with the post-WWII Boomer Generation, followed by Gen-Xers and Gen-Ys, to become increasingly dopamine-addicted and imbalanced.

Simon Sinek offers many detailed examples and stories of leaders in all walks from the military to politics and businesses.

TED Talk: Why Leaders Eat Last #

The Five Dysfunctions of a Team

2021-12-07T00:00:00+00:00

This book is a leadership fable about a tech company that is struggling to get more customers. The C level is not working as a team, and they have a hard time coming to any agreements which result in negative morale. Until the new CEO, Catherine Petersen, joins the team, and she is able to recognize the problems and help the team overcome them by understanding the situation.

This is the first book I read from the author Patrick Lencioni, who is an American writer who writes books on business management. He is the founder and president of the Table group, a management consulting focused on organizational health.

Book summary #

Kathryn Petersen, Decision Tech’s CEO, faces the ultimate leadership crisis: Uniting a team in such disarray that it threatens to bring down the entire company. Will she succeed? Will she be fired? Will the company fail?

Throughout the story, Lencioni reveals the five dysfunctions which go to the very heart of why teams even the best ones-often struggle. He outlines a powerful model and actionable steps that can be used to overcome these common hurdles and build a cohesive, effective team.

The 5 dysfunction model #

1) Absence of trust #

The fear of being vulnerable prevents team members from building trust with each other.

This occurs when team members are reluctant to be vulnerable with one another and are unwilling to admit their mistakes, weaknesses or needs for help. Without a certain comfort level among team members, a foundation of trust is impossible.

2) Fear of conflict #

The desire to preserve artificial harmony stifles productive ideological conflict within the team.

Teams that are lacking on trust are incapable of engaging in unfiltered, passionate debate about key issues, causing situations where team conflict can easily turn into veiled discussions and back channel comments. In a work setting where team members do not openly air their opinions, inferior decisions are the result.

3) Lack of commitment #

The lack of clarity and/or buy-in prevents team members from making decisions they stick to.

Without conflict, it is difficult for team members to commit to decisions, creating an environment where ambiguity prevails. Lack of direction and commitment can make employees, particularly star employees, disgruntled.

4) Avoidance of accountability #

The need to avoid interpersonal discomfort prevents team members from holding each other accountable for their behaviors and performance.

When teams don’t commit to a clear plan of action, even the most focused and driven individuals hesitate to call their peers on actions and behaviors that may seem counterproductive to the overall good of the team.

5) Inattention to results #

The pursuit of individual goals and personal status erodes the team’s focus on collective success.

Team members naturally tend to put their own needs (ego, career development, recognition, etc.) ahead of the collective goals of the team when individuals aren’t held accountable. If a team has lost sight of the need for achievement, the business ultimately suffers.

Video Summary #

Start with Why

2021-11-28T00:00:00+00:00

Start with Why asks (and answers) the questions: why are some people and organizations more innovative, more influential, and more profitable than others? Why do some command greater loyalty from customers and employees alike? Even among the successful, why are so few able to repeat their success over and over?

The ability to inspire those around you and to achieve remarkable things starts with WHY. Those who start with WHY never manipulate, they inspire.

People like Martin Luther King Jr., Steve Jobs, and the Wright Brothers had little in common, but they all started with WHY. They realized that people won’t truly buy into a product, service, movement, or idea until they understand the WHY behind it.

The ability to inspire those around you and to achieve remarkable things starts with WHY.
Any organization can explain what it does; some can explain how they do it; but very few can clearly articulate why.
Your WHY is your purpose, cause or belief.
Every inspiring leader and organization, regardless of size or industry, starts with WHY.
When your WHY goes fuzzy, it becomes much more difficult to maintain the growth, loyalty, and inspiration that helped drive your original success.

People don’t buy WHAT you do, they buy WHY you do it.

Great leaders are able to inspire people to act. And those who are able to inspire give people a sense of purpose or belonging that has little to do with any external incentive or benefit to be gained.

Video Summary #

Leadership is Language

2021-10-22T00:00:00+00:00

A radical playbook to empower your people and put your team on a path to continuous improvement.

In this book, the former submarine commander Captain L. David Marquet dives deep into one of the most investigated marine disasters, the sinking of the El Faro, and surfaces with new ideas on leadership and language.

You might imagine that an effective leader is someone who makes quick, intelligent decisions, gives inspiring speeches, and issues clear orders to their team, so they can execute a plan to achieve your organization’s goals. Unfortunately, that’s an outdated model of leadership that just doesn’t work anymore.

Your words matter more than you think.

David gives six plays that all leaders should use to improve how their teams operate. He says a big problem with leaders today is that they are trapped in an industrial-age playbook. In the industrial age leaders gave commands and employees followed, and that was it. But that way of leading is no longer effective, it is outdated.

The six plays #

Control the clock, don’t obey the clock: pre-plan decision points and give your people the tools they need to hit pause on a plan of action if they notice something wrong.
Collaborate, don’t coerce: as the leader, you should be the last one to offer your opinion.
Commit, don’t comply: rather than expect your team to comply with specific directions, explain your overall goals, and get their commitment to achieving it one piece at a time.
Complete, not continue: if every day feels like a repetition of the last, you’re doing something wrong.
Improve, don’t prove: ask your people to improve on plans and processes, rather than prove that they can meet fixed goals or deadlines.
Connect, don’t conform: flatten hierarchies in your organization and connect with your people to encourage them to contribute to decision-making

Video Summary #

Red Work vs Blue Work

2021-10-21T00:00:00+00:00

“Blue Work” and “Red Work” are concepts that David Marquet describes in his book Leadership is Language. Both require different mindsets and have different languages.

“Doing” in our traditional leadership style will not take us to where we need to be in the future.

What is “Red Work”? #

Red Work is about doing and reducing variability. Red Work focuses on a proving mindset and a performance mindset.

In Red Work, you seek to complete a task without a lot of need for deciding what or how. Red Work is being in control and taking control. Such as:

Process work and avoid errors.
Having predictability and controllability.

We need a mechanism to stop Red Work and ask: are we doing the right thing?

What is “Blue Work”? #

Blue Work is about deciding, thinking, planning. Blue Work focuses on improving with an embarrassing mindset.

The correct place to do Blue Work is at the beginning and at the end of a decision point.

Blue Work is crucial for a good starting point, allowing us to decide the best way to do something with the information that we have right now.

It’s also important to establish short iterations between the different actions or activities that we want to complete, so we can have some “Blue Work time” and reflect again. Blue Work is perfect to do retrospectives and see what could be improved.

It’s the time to stop and “control the clock”, collaborate and make a commitment for the next iteration. Blue Work is also about:

Thinking work.
Decision-making.
Looking to achieve excellence.
Getting more people to do independent thinking answers.
Embracing variability and looking for different inputs.

Blue Work in isolation is useless. The job of Blue Work is to make Red Work better. Endless Blue Work, planning without outcome doesn’t bring any real benefits.

Nowadays, especially in our modern software industry, there is no room for the old school of “Red-Workers” and “Blue-Workers”, but “Red Work” and “Blue Work”, and everyone should be involved in both.

It is, therefore, everyone’s responsibility to be aware of these different types of work and find a good balance between them. Leaders involve everyone in both Red Work and Blue Work.

References #

Turn the Ship Around!

2021-09-12T00:00:00+00:00

The book is about his leadership theories to how he implemented a fresh leadership model. Including the limitations of a hierarchical top-down model, why/how he failed to empower his team earlier in his career, and how the circumstances for Santa Fe were ideal for him to experiment with the new leader-leader approach.

Most people unconsciously divide the world into leaders vs followers, and make assumptions about what each group can/can’t do. Such assumptions influence our thoughts and actions that impact the performance of individual employees and the organization.

It is common for enthusiastic employees to suggest new ideas, and then they are told “it’s not your job” or “that won’t work”. People feel frustrated and eventually stop trying or leave the organization. Bosses also feel frustrated when their staff would rather do the minimum rather than to innovate or take responsibility.

The leader-leader model recognizes that everyone has the ability and potential to lead. It taps on individual potential at all levels, reduces dependency on a single leader and delivers sustained performance.

The 3 key components: Control, Competence and Clarity #

Control #

Control refers to the freedom and authority to make decisions about why, what and how you’re going to work. The goal is to delegate decision-making control as far as possible in the organization.

Find the genetic code for control and rewrite it.
Act your way to new thinking.
Short, early conversations make efficient work.
Use “I intend to…” to turn passive followers into active leaders.
Resist the urge to provide solutions.
Eliminate top-down monitoring systems.
Think out loud (both superiors and subordinates).

Competence #

People at every level must be technically competent to make the right decisions. If you give people additional responsibility without equipping them with the required knowledge and resources, things will fall apart.

Take deliberate action.
We learn (everywhere, all the time).
Don’t brief, certify.
Continually and consistently repeat the message.
Specify goals, not methods.

Clarity #

For people at all levels to make effective decisions, they must be fully aligned with the organization’s purpose, and thoroughly understand the organization’s goals and decision-making criteria.

Achieve excellence, don’t just avoid errors.
Build trust and take care of your people.
Use your legacy for inspiration.
Use guiding principles for decision criteria.
Use immediate recognition to reinforce desired behaviours.
Begin with the end in mind.
Encourage a questioning attitude over blind obedience.

Favourite quotes #

Leadership is communicating to people their worth and potential so clearly that they are inspired to see it in themselves.

Summary #

David Marquet talks about leadership that turns the ship around in his keynote at the Worldwebforum.

Lord of the Flies

2021-07-10T00:00:00+00:00

Labeled a parable, an allegory, a myth, a morality tale, a parody, a political treatise, even a vision of the apocalypse. It has established itself as a true classic.

The book focuses on a group of British boys stranded on an uninhabited island, and their disastrous attempt to govern themselves.

Themes include the tension between groupthink and individuality, between rational and emotional reactions, and between morality and immorality.

The first chapters start slowly, but they are necessary to build up the context of the story, which scales pretty quickly later on.

Responsibilities of a Tech Lead

2021-07-01T00:00:00+00:00

The Trident Career Model by Patrick Kua has three tracks. Each track represents where people spend most of their time or energy.

Archetypal Story #

Individual Contributor #

70-80% time spent on “Executing, doing”.
Designing. Testing. Coding.

Management #

70-80% time spent on “Managing the system”.
Planning. Organizing. Supporting. Budgeting.

Technical Leader #

70-80% time spent on “Leading Technical Topics & Teams”.
Aligning Team. Technical Vision. Growing Tech Knowledge. Tech Risk & Tech Debt Management.

What is a Tech Lead?

“A Tech Lead is a software engineer, responsible for leading a development team, and responsible for the quality of its technical deliverables.” (source)

A Tech Lead is a Developer who is a Leader #

A good leader is making sure that the team is moving in the same direction. The team moves further altogether, rather than simply people who are working “together”.

Leadership skills to invest in #

Empathy
Self-Awareness
Motivation
Conflict Resolution
Communication
Coaching
Feedback
Influencing
Delegation

The Tech Lead role is a leadership position, not necessarily a management position.

Surprises & Struggle #

Feeling Alone: “Outsider”. Different role. Shield/Filter.
Uncertainty: No right answer. Binary habit. Imperfect information.
People are puzzling: Unique. Different Strengths. Archetypes.

A Great Tech Lead #

A great Tech Leader is really focusing on developing others, so the team will get better capabilities.

Tell or Delegate? #

The goal is to reach a complete delegation, step by step. It’s about starting to shift responsibilities to other people, so they grow as well. It can also depend on the skills, motivations, and urgency of the task.

“Nobody is perfect, but a team can be.” - Meredith Belbin

Key points #

Tech Lead is a role change.
It requires leadership skills.
Others have been on this journey.
There are many resources available.
Move from maker mode to multiplier.

Recommended books on this field #

References #

Become an Effective Software Engineering Manager

2021-06-27T00:00:00+00:00

A great compilation of all topics that are important for management: 1:1s, performance reviews, hiring and laying off, workplace politics, remote work, and others.

The book is divided into 3 parts: the first part covers things a new manager should know, the second and third parts go into topics that all managers should master.

Although I kept nodding along with the bits of advice, I sometimes felt it was too “wordy” or going into too many details that I wasn’t interested in. That said, I kept moving forward, and I am glad that I finished it, gathering a lot of useful tips.

My takeaways from this book:

Part 1 - Getting Oriented #

Chapter 01: A New Adventure #

Practical advice on things to do the first week and finding misalignment signals on your first week.

Chapter 02: Manage Yourself First #

A good reminder of how getting your things an order comes first - this is a pre-requisite to you being efficient, as a manager.

“Your calendar it is both for you and other people to use. Keep it tidy and meaningful. It represents you. Making meetings public by default can help others reason better about how to schedule time with you.”

Part 2 - Working with Individuals #

Chapter 03: Interfacing with Humans #

This chapter covers a lot of ground on how to communicate with others.
Think twice before broadcasting information.
Be consistent in your communications style.

“Don’t communicate when you want to, but when you need to.”

Chapter 04: One-to-Ones #

It’s their meeting, not yours.

“Try to get your direct reports to do 70% of the talking. If you feel like solving their problem for them, don’t. Ask another question and let them arrive at the conclusion themselves. This is an art that takes some practice.”

Chapter 05: The Right Job for the Person #

Motivation and the hierarchy of needs. Developing skills with some practical examples on doing so.

“However, as their manager, you can work with them to place these career achievements at the bottom of their skill tree, and then plan out the milestones along the way that they can aim for to make measurable progress. Thus pushing the frontier of their zone of proximal development further and further.”

Chapter 06: The Most Wonderful Time of the Year (Performance Reviews) #

Preparing for performance reviews ahead of time. Getting peer feedback, and doing this via email, for example.

Chapter 07: Join Us! (Hiring) #

The case for not needing the most senior candidate.
Culture fit.
Setting up an interview process.

Chapter 08: Game Over (Attrition) #

People leaving is normal.
Voluntary resignations that are:
- “good reasons”, aka you could have not done much about it.
- “bad reasons”, that is you could have caught (and addressed) things early like coworker conflict, lack of challenge, compensation.

“As a manager, you are doomed to failure if you think that you are going to keep everyone in your current team indefinitely. […] You should never fight to keep staff if you cannot actually provide the conditions under which they can become happier than they already are. You’ll just defer their departure.”

Chapter 09: How to win friends and influence people (Being well-connected) #

Building your network . Making introductions, checking in with others.
Coaching and mentoring.

Part 3 - The Bigger Picture #

Chapter 10: Humans are Hard #

Working harder or faster isn’t what you should be focusing on. Instead, you should be creating the conditions that make your staff happy and productive through nurturing their autonomy, mastery, and purpose.

“At more senior levels, During bad times, you will get the fingers pointed at you as you are fundamentally accountable, even though it may have not been your fault.”

Chapter 11: Projects are Hard #

“The eye off Sauron” - working on high-stakes projects.
Things slowing down as the team is growing. More (legacy) code, more problems to deal with.
Scope, resources and time balance.

“Lead from the front: As a leader, you need to set the example for the rest of the team. Put in the work. The hardest projects can become career-defining moments. Own them and be there.”

Chapter 12: The Information Stock Exchange #

Spies and gatekeepers.

“As a manager, you will be required to make regular decisions about how much you should share with other staff and when.”

Workplace politics.

“In workplace politics, your network of peers is important as it allows you to be more broadly informed about how the wider business feels about your own initiatives and priorities.”

Chapter 13: Letting Go of Control #

Remove distractions and recharge properly outside work.
Use 10% of your time each week to do nothing and let your thoughts emerge.

“Let go of outcomes that you cannot control. Be accepting of trying your best, and encourage the same behavior in your staff. Unpredictable results are normal. Failure is acceptable. As long as you are trying your best, and you are enabling your team to try your best, then you have nothing to worry about.”

Chapter 14: Good Housekeeping #

Turn problems into learning opportunities.
Work on improving the team communication.

Chapter 15: Dual Ladders #

Designing an Individual Contributor and Manager track is vital to a healthy engineering organization culture.

Chapter 16: The Modern Workplace #

Diversity and inclusion.
Remote working.
Lead by example: work-life-balance.

Chapter 17: Startups #

Management doesn’t mean bureaucracy.
Good management is a light touch and continued collaboration.

“Remember that start-up experience is highly sought after because being impactful in that environment involves being enterprising, self-motivated, collaborative, and quick to learn. Even if the start-up itself doesn’t work out, your next gig will be all the better for it.”

Chapter 18: The Crystal Ball #

Your career vision. Looking back, looking ahead.

“An important part of a long and fulfilling life is purpose. Purpose is not about economic status or feeling well-being. It’s about a life worth living.”

Conformity Experiments

2021-06-01T00:00:00+00:00

To what extent do social forces alter people’s opinions? Which aspect of the group influence is most important: the size of the majority, or the unanimity of opinion?

The psychologist Solomon Asch #

During the early years of World War II, when Hitler was at the height of power, Solomon Asch began studying the impact of propaganda and indoctrination while he was a professor at Brooklyn College’s psychology department. He also was a professor for 19 years at Swarthmore College.

During the 1950s, Asch became famous for his series of experiments that demonstrated the effects of social pressure on conformity. How far would people go to conform to others in a group? Asch’s research demonstrated that participants were surprisingly likely to conform to a group, even when they personally believed that the group was incorrect.

Asch asked #

To what extent do social forces alter people’s opinions? Which aspect of the group influence is most important: the size of the majority, or the unanimity of opinion?

Asch believed that people behave according to how they perceive the world, not to how it actually is.

The Asch experiment #

Asch used an experiment to study conformity based on a “simple vision test”.

Using a line judgment task, Asch put a naive participant in a room with other confederates/stooges. The confederates had agreed in advance what their responses were going to be when presented with the line task. Giving intentionally the same wrong answer most of the time.

The real participant didn’t know this and was led to believe that the other people were also real participants like himself.

Each person in the room had to state aloud which comparison line (A, B, or C) was most like the target line. The answer was always obvious. The real participant sat at the end of the row and gave his answer last.

Asch was interested to see if the real participant would conform to the majority view. The confederates gave the wrong answer most of the time (known as critical trials).

Findings #

Nearly 75% of the participants in the conformity experiments went along with the rest of the group at least one time.

Asch also found that having one of the confederates give the correct answer while the rest of the confederates gave the incorrect answer dramatically lowered conformity, which means that having social support is an important tool in combating conformity.

After combining the trials, the results indicated that participants conformed to the incorrect group answer approximately one-third of the time.

Why people conform to a group they disagree with #

Why did the participants conform so easily? When they were interviewed after the experiment, most of them said that they did not really believe their conforming answers, but had gone along with the group for fear of being ridiculed.

A few of them said that they really did believe the group’s answers were correct.

Apparently, people conform for two main reasons: because they want to fit in with the group (normative influence) and because they believe the group is better informed than they are (informational influence).

Conformity can be influenced both by a need to fit in and a belief that other people are smarter or better informed.

Factors that influence conformity #

Asch went on to conduct further experiments in order to determine which factors influenced, and how and when people conform. He found that:

Conformity tends to increase when more people are present.
Conformity also increases when the task becomes more difficult.
Conformity increases when other members of the group are of a higher social status.
Conformity tends to decrease, however, when people are able to respond privately (i.e., when the group can’t know the naive participants’ answers).

Resources #

Solomon Asch | Wikipedia

The Art of Leadership

2021-04-19T00:00:00+00:00

Some nice keynotes #

Leadership practices are small things done repetitively over time.
Empathy is a powerful skillset.
The practice of one on ones is important in connecting to a team.
Asking for feedback can build trust and relationships.
Respond to feedback with a thank you and follow up comprehension questions.
Feedback is a gift.
It’s not personal, it’s professional.
Leadership is an outfit that you choose to wear for others to see.
Managers tell you where you are, leaders tell you where you’re going.
Your peers become your allies.

97 Things Every Engineering Manager should know

2021-04-05T00:00:00+00:00

The main takeaway #

As a manager your work is to create clarity, clarity, and more clarity.

Key Insights #

As a manager, you need to fix your personal quirks.
Consider doing experiments instead of making decisions.
“Bad news test” - Given two tasks, which one would you rather be sharing bad news about? Delegate that task.
On a struggling team, start by answering two questions:
- How do I create clarity?
- How do I create capacity?
Ask for clarification.
To give constructive feedback, pay attention to how the person gets stuck, sidetracked or sloppy.
Management is not a promotion. It is a career change.
Most of the dysfunctions come from some lack of clarity goal.
For a fixed deadline, scope and quality are always negotiable.
Emotional contagion is real.
As a new manager, listen and understand before you try to change something.
Good interview questions:
- What have you learned in the past six months?
- Tell me about the time when you failed and what you learned from that?
- Do you have the skills, expertise and experience to perform the job?
Complains are good: they show that you are trusted.

Another blog post with way more detailed key insights: Danlebrero Blog ;)

Embrace the Change

2021-03-01T00:00:00+00:00

The book Who moved my cheese? presents a tale inside the main story that consists of 4 characters: two mice, Sniff and Scurry, and two little persons, Hem and Haw.

Published in 1998, and I just read it at the beginning of 2021. Better late than never. Actually, thanks to my brother Jesús, who recommended it to me.

They live in a Maze (that represents one’s environment) and in order to survive they need to go out of their comfort zone and look for cheese (which represents happiness and success).

The tale starts when both groups end up at “Cheese Station C”, full of cheese. The humans established routines while the mice kept their instincts active.

One day the mice arrive at the “Cheese Station C” and find no cheese left. So they go out to find more cheese somewhere else. On the contrary, when Hem and Haw see that there is no cheese left, they start complaining. Hem, angry and annoyed, demands “Who moved my cheese?!”. Both humans counted on the cheese supply being endless and constant, so they weren’t prepared for the unexpected. The main difference here is how Haw and Hem react to this situation.

Hem denies moving away from the “Cheese Station C”, so he keeps going there every day expecting to find cheese without success, being weaker, and with continuous fear of doing something different. Haw, on the other hand, decides to laugh at the situation, turns down his fear, and goes out looking for more cheese.

… I will leave the rest of the tale to you.

The tale is a beautiful metaphor of the different attitudes that people adopt as part of their identity in life when they have to confront any change.

Noticing small changes early helps you adapt to the bigger changes that are to come.

This book is full of lessons that apply to everyone no matter who they are or when they read it. I fully recommend it.

My favorite lessons of the book #

Change happens. They keep moving the cheese.
Anticipate change. Get ready for the cheese to move.
Monitor change. Smell the cheese often so you know when it’s getting old.
Adapt to change quickly. The quicker you let go of old cheese, the sooner you can enjoy new cheese.
Change. Move with the cheese.
Enjoy change. Enjoy the taste of new cheese
Be ready to change quickly and enjoy it again. They keep moving the cheese.

“Everyone knows that not all change is good or even necessary. But in a world that is constantly changing, it is to our advantage to learn how to adapt and enjoy something better. It is not what is in the story of “Who moved my cheese?” but how you interpret it and apply it to your own situation that gives it the value.“ - Ken Blanchard.

“Life moves on and so should we” - Spencer Johnson

Never split the difference

2020-06-12T00:00:00+00:00

From policing the rough streets of Kansas City, Missouri, to becoming the FBI’s lead international kidnapping negotiator to teaching negotiation at leading universities, Chris Voss has tested the techniques in Never Split the Difference across the full spectrum of human endeavor and proved their effectiveness.

Takeaways #

Negotiation begins with listening, making it about the other people, validating their emotions, and creating enough trust and safety for a real conversation to begin.
Use mirrors to encourage the other side to empathize and bond with you, keep people talking, buy your side time to regroup, and encourage your counterparts to reveal their strategy.
Tactical empathy brings our attention to both the emotional obstacles and the potential pathways to getting an agreement done.
Giving someone’s emotion a name, otherwise known as labeling, gets you close to someone without asking about external factors you know nothing about.
“No” provides a great opportunity for you, and the other party to clarify what you really want by eliminating what you don’t want.

Summary video #

High Output Management

2020-04-03T00:00:00+00:00

In this legendary business book and Silicon Valley staple, the former chairman and CEO of Intel shares his perspective on how to build and run a company. A practical handbook for navigating real-life business scenarios and a powerful management manifesto with the ability to revolutionize the way we work.

Sections #

Managerial Leverage
Training
Motivation
Meetings and Decisions
One-on-One Meetings
Delegation and Task-Relevant Maturity
KPIs
Performance Reviews
Interviews
Promotions and Recycling

A pretty nice overview from the takeaways by Marc Koenig:

The Manager Path

2020-03-26T00:00:00+00:00

Key lessons #

One-on-one meetings with your manager are an essential feature of a good working relationship.
A manager’s job involves making it easy for her employees to get things done by creating fertile environments in which work can happen.
Mentoring new hires is critical.
Feedback works best when you, as a manager, pair that feedback with coaching.
It’s unrealistic to think you can or should shield your team from everything.

How to Improve Your Tech-Talk (or Any Other Presentation)

2019-11-18T00:00:00+00:00

We have found ourselves attending a meeting that felt like we were wasting our time with a “monologue” that is either hard to follow or doesn’t seem so interesting as it could. Let’s fix this.

Therefore, I was thinking about it, and I tried to get some keys to improving their general quality. It applies to all presentations but also tech-talks and other tech presentations in which engineers are usually involved.

Structure of the talk #

To explain how I think a good presentation should look like I will address three main topics that are relevant to structure and design your presentation.

Content of the presentation: what message do you want to convey to whom and how?
Design and Layout: how you can design an easy-to-follow presentation that supports your talk instead of taking away the attention from what you are actually trying to say.
Lastly, I think also the audience is responsible for making a tech talk successful, so I will also add a reminder about the role and responsibilities of the listeners.

Consider your audience #

When you prepare your presentation, ask yourself:

Who is attending the talk?
Which backgrounds do they have?
Which position do they have?
Which information is relevant to them?
Do they have to know all the keywords that you would like to use?

Introduce the topic #

Create some atmosphere. Try to answer these questions:

Why should they listen to you?
Why should they spend their time in another meeting?
What will they have learned by the end of the talk?
What is your main message?

Every meeting should have an output and an outcome. Keep it in mind.

Create a Storyline #

When preparing the main content of your talk, think about a storyline that connects your arguments. This makes it easier for the audience to follow.
Stick to the messages that are necessary to explain your idea or concept.
Leave out any unnecessary information that is not relevant to the core of your message.

Build a conclusion #

Summarize the main conclusion(s) in a concise way:

What is the conclusion of this meeting?
What are the learnings from this meeting?
What are the open questions or next steps?

Design and Layout #

Write less, talk more #

A tech-talk is about learning new ideas and concepts.
A presentation should support your talk, not replace or replicate what you have said.
The more words on the slide, the fewer they will be remembered.
Use visuals/graphics that support your talk instead of additional text.

Large fonts #

If you have some code to present, consider:

If it is a picture: use large fonts inside. I recommend using https://carbon.now.sh/ for simple snippets. Or just screenshots from your favorite IDE.
If you code in live: prepare your editor in advance. Use the Presentation Mode of your IDE.

Role of the Audience #

Responsibilities of the attendee #

No unnecessary phone usage, like Twitter, Instagram, Facebook, WhatsApp, Telegram, etc.
Keep your questions for the questions time, unless the presenter mentions at the very beginning that you can ask at any moment. Usually, it’s better not to interrupt the topic, so we can ask the questions at the end.
Show interest in the topic. The presenter should have spent some time preparing the slides for you.
Pair with the presenter the interest of the topic. This is also the responsibility of the presenter. You both should be eager to learn more about the topic.

Inner questions #

Was it worth the time that we all spent in this room?
Do we regret the attendance of this meeting?

At the end of the meeting, we should ask these questions in order to improve. Ask other people for their feedback, so we can grow further and together.

The Art of War

2018-08-10T00:00:00+00:00

The text is composed of 13 chapters, each of which is devoted to one aspect of warfare. It is commonly thought of as a definitive work on military strategy and tactics.

It has been the most famous and influential of China’s Seven Military Classics, and “for the last two thousand years it remained the most important military treatise in Asia, where even the common people knew it by name.”

It has had an influence on Eastern and Western military thinking, business tactics, legal strategy and beyond.

Quotes #

Appear weak when you are strong, and strong when you are weak.
If he is superior in strength, evade him.
Attack him where he is unprepared. Appear where you are not expected.
The general who loses a battle makes but few calculations beforehand.
There is no instance of a country having benefitted from prolonged warfare.
Supreme excellence consists in breaking the enemy’s resistance without fighting.
If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself, but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle.
One may know how to conquer without being able to do it.
In war, the victorious strategist only seeks battle after the victory has been won.
In battle, there are not more than two methods of attack: the direct and indirect.
An army may march great distances without distress if it marches through country where the enemy is not.
You can be sure in succeeding in your attacks if you only attack places which are undefended.
Military tactics are like water. For water, in its natural course, runs away from high places and hastens downwards. So, in war, the way is to avoid what is strong and strike at what is weak.
Let your plans be dark and impenetrable as night, and when you move fall like a thunderbolt.
Ponder and deliberate before you make a move.
A clever general, therefore, avoids an army when its spirit is keen, but attacks it when it is sluggish and inclined to return.
It is a military axiom not to advance uphill against the enemy nor to oppose him when he comes downhill.
The art of war teaches us to rely not on the likelihood of the enemy not coming, but on our readiness to receive him.
Make your way by unexpected routes and attack unguarded spots.
If they will face death, there is nothing they will not achieve.
The principle on which to manage an army is to set up one standard of courage which all must reach.
If it is to your advantage, make a forward move. If not, stay where you are.