$ cd ./topics/career-leadership
Leading UI teams, running communities of practice, communicating with stakeholders, and the habits that make a team better at its craft over time.
24 notes🌱 2 seed🌿 20 growing🌳 2 evergreen
The jump from developer to lead is mostly a jump in communication. The code still matters, but more of the outcome depends on whether the right people understand what you’re doing, whether decisions get written down, and whether knowledge lives in the team rather than in one head.
These notes cover the human side of engineering. I’ve been a TV app developer, a UI lead and chair of a cross-department UI community, and I’m now a lead developer on real-time trading interfaces. The case studies are abstracted: patterns and lessons, not internals.
hover to explore · click to open
Case study — raising coverage with network-level mocks instead of brittle ones, shipping features test-first, speeding up quality checks, and getting Playwright adopted across several teams.
Case study — designing and shipping a React network-graph library for several teams, and why rendering tech, API shape and Storybook mattered most.
Case study — leading the UI of a low-code network automation platform where workflows are drawn as BPMN diagrams. Model-driven editing, server-side permissions and a catalogue of reusable building blocks.
Case study — UI engineers were scattered across backend-shaped scrum teams, under-used and unaware of each other. Making the case for a UI community, then chairing it across departments.
Case study — taking a large React codebase from a long backlog of TypeScript errors to zero with months of small, non-functional merge requests, so the build could finally enforce types.
Case study — handing over a platform I'd led the UI of, through structured sessions backed by written docs, a reuse strategy and a clean backlog, so the team could own it without me.
Case study — building a broadcaster's streaming app for many TV platforms at Accedo. Memory and performance work for slow devices, a back-navigation model that finally made sense, a full rebrand, and a knowledge-sharing culture.
A one-page, version-controlled record of a significant decision. Context, decision, consequences. Never edited after acceptance, only superseded, so the history of "why" survives.
Information is everywhere and almost none of it sticks. Learn less, one thing at a time, then write, build and share — and design your environment so focus is the default.
Keep meetings on agenda, translate engineering work into delivery language, and present roadmaps as value, not cost. Most of a lead's influence happens in these conversations.
Muscles adapt in days, tendons in weeks. Planned deloads and short, spaced bouts of loading keep the slow tissue in step — and the same is true of teams and their tech debt.
Tendons adapt slower than muscles, and organisations adapt slower than code. Schedule the recovery week before an injury schedules it for you.
A design is ready for review when a UI developer, an API developer and a tech lead new to the project could each start building, or challenge it, without asking you anything.
Digital transformation isn't buying tools; it's changing what people do every day. Culture is the sum of small habits, and platforms are how you make the good ones easy.
Four measures of software delivery, two for throughput and two for stability. In high-performing teams they improve together, so speed and safety aren't a trade-off.
Sort work by urgent and important. Do, schedule, delegate, delete. Most real progress lives in "important but not urgent", which is exactly the quadrant that gets squeezed out.
You can't push volume and skill at the same time without something giving. Platform roadmaps work better when they alternate building capability with hardening it.
Pairing trades a little throughput for quality, shared ownership and faster onboarding. Pick the style for the goal. Ping-pong for TDD, driver/navigator for design, strong-style for teaching.
Scan for leaks, rotate first, rewrite history with regex patterns rather than literal lists, and add a pre-commit scanner so it never happens again.
Find defects where they're cheapest to fix, in refinement, the editor and the pull request. But shift-left means early feedback, not running every expensive test at the earliest stage.
When time comes in smaller blocks and sleep is broken, the minimum effective dose, short explosive sessions and a flexible schedule keep progress going — or at least keep the skills.
Buy what's generic, build platforms for supporting capabilities, and leave the core to product teams — Domain-Driven Design as a map for platform investment.
People are more willing to see hacking as legitimate when they feel a system or authority won't listen to them, and they're angry about it. A psychology finding with uncomfortable lessons for organisations.
Specialise for a block. Two or three goals at a time beat ten — in training, where goals compete for recovery, and in teams, where they compete for attention.