Seven Habits of a Highly Successful Team - Sander Hoogendoorn (Talk Outline)

Sander Hoogendoorn (Amsterdam; ~40 years in IT, coding since 1978, still codes daily; leads the tech team at a daily-deals e-commerce company) on how his “mostly successful” team works — “mostly,” because during the big quarterly sale (run over 3 days instead of 2) they had a serious outage they were still repairing that morning (“even successful teams fail, always at the wrong time — Murphy”). Golden nugget: you cannot stop learning in this industry. The title (riff on The 7 Habits of Highly Effective People) and description were generated by ChatGPT, then he wrote the talk to fit — because software is a team sport, he made it about a team, specifically his own.

1. The Problem — Technical Death & the Innovator’s Dilemma

• The company is 20 years old this year: started with a single daily deal on an ugly, nerdy web page, everything managed in an Excel spreadsheet; the daily-new-deals model is unusual and makes tech hard.
• Growth led to: a renewal project (called “Next”, “as all projects are”), forked open-source systems they can no longer upgrade (the ERP is 8 versions behind, one release/year — a risk), microservices “with weird names” that didn’t work out, deployed on every cloud, and — without thinking through architecture — copying data around (user accounts landed in the CMS, which shouldn’t hold them) and syncing it via every mechanism imaginable.
• Result: technical death — all the team’s time goes to maintaining/keeping things running, no time to innovate (a widespread industry problem).
• The real cause is never the tech. Monoliths are “okayish”; legacy can be great (the Pantheon of Rome has stood 2,000 years); dependencies are ugly but cuttable. It’s always the organization — managers, product managers, and marketing pushing the next feature; refactoring gets “no time.” (You shouldn’t ask for refactoring time — just do it, it’s part of the job.) A cultural problem — and toxic norms like “let less-experienced devs get feedback later rather than pull senior resources off critical work” (a word/attitude he hates).
• The innovator’s dilemma: you build a working (weird) business model, add features, then someone new (Temu, etc.) arrives with newer/easier tech and a better model — you must reinvent, but you’re stuck in your stack. The only certainty is constant change.

2. Habit 1 — Prioritize Pragmatically (70/20/10)

• Work always exceeds capacity, so priority-setting is key. It starts with a purpose — a clear “dot on the horizon.” When he joined, the goal was “make more money with higher margins,” which you can’t build software toward; they distilled a mission statement (“Europe’s leading deals, connecting a community of consumers, surprising them daily”) and want A-brands (which required renewing the hideous website + app + backend).
• Budget split: 70% getting away from the old problems (innovating toward the dot), 20% renovating existing systems people use daily, 10% keeping the lights on.
• The tech board (a group and a Jira board — most managers, COO/CTO/CMO, logistics/finance/marketing, plus him) meets every Thursday at noon over lunch. Anyone can pitch; each idea is filtered:
  1. Will it help reach our goals? If not, kill it immediately.
  2. Can we actually do it? (13 people — can’t do everything; sometimes prefer boring tech and just crank it out.)
  3. Is it small enough? If too big, send it back to be broken down into a first part.
  4. Do we need it now? — the key question: is it more urgent than the other important things? Re-prioritize almost weekly to handle constant change.
• Rejects go to a “someday/maybe” column (from Getting Things Done) — officially revisited every 3 months, “in reality never” (i.e., the bin — “don’t tell my company”). Finished work → “selected for development” → anyone on the team picks it up (autonomy).
• The 20% (small features on production systems, ~2–5 days max, no hard estimates) is decided by a separate board (mostly department number-twos); bigger items go to the tech board. The 10% keeps the lights on (hard during the multi-day sale — everything broke).

3. Habit 2 — Kill Complexity (with tiny steps)

• Can’t “close the shop for half a year and rebuild” — it’s continuous renovation (“keep the shop open”), like his Amsterdam bicycle repair man. Gall’s Law (John Gall): a complex system designed from scratch never works → always start simple again → smaller work in shorter cycles.
• Developers jump in head-over-heels and underestimate — because of the Cynefin framework (Dave Snowden, who spoke earlier): Clear (best practice — dishes → dishwasher), Complicated (good practices, analysis, manageable), but most of us are in Complex/Chaotic — unknown unknowns, no best/good practices, so estimation is near-impossible and big problems never finish.
• The only way out of complex/chaotic is experimentation — a test to learn/discover if something works; it may fail, and failure is an option (you learned something). Many orgs want innovation but won’t experiment (in Kent Beck’s terms, in the desert experimentation is wrong; Hoogendoorn lives in the forest). Smaller experiments fail faster → faster learning → feedback cycles. Not deciding still lets time pass → the innovator’s dilemma.
• Be a “coddiwomple” — “to travel purposefully toward an as-yet-unknown destination.” Take very small steps (“if you think they’re small, make them smaller”; two-week sprints are not small). Best explanation: a cartoon contrasting small steps vs. two big steps (one of his three memorable takeaways).

4. Habit 3 — Own the Work (Autonomy)

• Anyone on the team can pick up anything from the boards — their decision. Software is too complex to figure out alone: Dijkstra (1984) — “the programmer has to think in conceptual hierarchies deeper than a single mind ever faced before” (ours is the most complex industry); the 90/90 rule (first 90% of code = 90% of time; last 10% = the other 90%).
• A ridiculous-but-real tech stack slide from a previous client — who went bankrupt on technical debt so fast they didn’t notice. Hoogendoorn admits how much of the modern stack he no longer knows (he started with a black screen and green characters, no Windows, no internet, learned from books).
• Charity Majors: “the smallest unit of software ownership is not the individual, it’s the team.” Autonomy is hard — a developer (Joyce) asked “what should I work on?” and he insisted she choose (“you know what’s important and urgent”). Self-organization can’t be taught (like the “draw the owl” meme) — learn by doing.

5. Habit 4 — Simplify to Amplify

• Dee Hock’s principle: ”Simple, clear purpose and principles give rise to complex, intelligent behavior. Complex rules and regulations give rise to simple, stupid behavior.”
• So they removed most imposed rules — when/how to work, what tools/laptops, where you are (home/bar/office; only ask people in one day a week). Metaphor: a crossroads near his home where they removed the traffic lights → people communicate, read each other’s intentions, let each other go first (except BMW drivers — “dangerous”).
• Saint-Exupéry: “perfection is achieved not when there’s nothing more to add, but when there’s nothing left to take away.” What his team no longer does: Scrum (“I hate Scrum” — but not Kanban either; hundreds of tastes between), sprints, retros, most standups, product owner, stories, estimates, pull requests, blaming — “we just collaborate.” Very limited architecture. Since everyone becomes their own product owner, they’re product engineers (per Büsra) — they go into the business, learn what customers want, and build it with the business.

6. Habit 5 — Communicate & Collaborate

• Work is mostly sharing knowledge, not hoarding it (if your company promotes hoarding, “quit”). Practices: event storming (Alberto Brandolini’s — works even with single-color sticky notes), lots of pair programming and mob programming (not mandatory — people like it), weekly lean-coffee sessions (pitch topics, 5-minute timer, vote, extend or move on), and yes, “vibe coding” (“you have to these days”). On AI: it looks faster but doesn’t necessarily make you faster — we still solve the problems, not the AI.

7. Habit 6 — Deliver Continuously

• Cycles have shrunk over decades: RUP (4–5-month cycles) → DSDM (6-week) → XP/Scrum (2-week) → now continuous delivery/deployment — every small change auto-deployed, ~40–50 deploys/day with a small team → tiny changes, tiny topics, rich feedback.
• Sprints have problems — finishing too early (nobody does), building things then the accepter’s on holiday, and above all progress isn’t linear (fast, then stuck). No single process works (rhinos stay in small families; developers cluster badly). Allen Holub: ”Agile is not a process or framework, but the ability to create your own and change it whenever you need to.”
• Shorter feedback loops → you get better. If you can re-release in 5 minutes, correctness at release matters less (Jez Humble: “if it hurts, do it more frequently, and bring the pain forward” — about releasing). The bus/train metaphor: missing the bus is no big deal if the next is along in 5 minutes (Jason — his third key takeaway). Big monoliths deployed every 3 months accumulate too much change to test → releases drift further apart. Automate everything.
• (His laptop and PowerPoint dramatically crashed mid-talk; he improvised without slides — fittingly, since the talk is about handling the unexpected. “If everything else fails, remove your node_modules and do an npm install.“)

8. Habit 7 — Have Fun

• Team outings (lunches, blokarting) are nice, but “we’ll go have fun” doesn’t fix motivation — everyone enjoys different things.
• Model (Dan Pink, Drive): motivation from purpose (the dot on the horizon), mastery (sharing knowledge / learning together), and autonomy (letting people choose).
• Not everyone likes change — his late mother (who died a month before the talk) and father went to the same French campsite for 25 years, and that’s fine; plenty of people happily “write Java in a bank basement.” But “old keys won’t open new doors” — if you want to ignite change, you are the only one who can; don’t wait for others, keep asking newcomer questions, never stop learning.
• Closing 10-second retro: there’s always change; we live in the forest while our organizations tend to be deserts; never stop learning; it’s still the most fun industry even without blokarting; AI is here to help. And: “take your mom out to dinner more — before you know it, you can’t.”

People, Books & References Cited

• Sander Hoogendoorn — speaker; leads the tech team at a daily-deals e-commerce company.
• Stephen Covey (7 Habits), John Gall (Gall’s Law), Dave Snowden (Cynefin), Kent Beck (forest/desert), Dijkstra (1984), Charity Majors (“smallest unit of ownership is the team”), Dee Hock (simplify-to-amplify), Saint-Exupéry, Alberto Brandolini (event storming), Allen Holub (agile definition), Jez Humble (“if it hurts, do it more often”), Dan Pink (Drive — purpose/mastery/autonomy), Büsra (“product engineers”).
• Concepts: technical death, innovator’s dilemma, 70/20/10, tech board, someday/maybe (GTD), coddiwomple, 90/90 rule, continuous delivery/deployment, lean coffee, mob programming.

Video: https://www.youtube.com/watch?v=ESsbHEY2kwE — Transcript via yt-transcript.sh; outline generated from the transcript.