Technical leadership
Technical leadership
How Maher Jaafar practises technical leadership: written decisions, standards that scale, code review as teaching, mentoring and community organizing.
For me, technical leadership is not a title. It's the work that makes a team faster and calmer: clear decisions, shared standards, honest communication and people who keep growing. I practise it in engineering teams, in the Flutter community as an organizer of Flutter Västerås and co-founder of Flutter Tunisia, as a mentor in the Google for Startups Accelerator and earlier with Google Developers and MentorNations, and on stage at FlutterCon Europe and DevFest Stockholm.
Making technical decisions
- Write decisions down. A short decision record (context, options, choice, consequences) prevents the same discussion from happening every three months and helps the next person understand why, not just what.
- Match the process to the risk. Reversible choices can be made quickly by the person closest to the work. Irreversible ones (data models, public APIs, platform choices) deserve a written proposal and a review.
- Prefer boring technology for the core. New tools are great where they solve a real problem. The foundation of a product should be something the whole team understands.
- Make the trade-off explicit. Every architecture choice costs something. Naming the cost openly builds more trust than pretending a solution is perfect.
Standards that scale
Good standards remove decisions instead of adding rules.
- Automate quality. Formatting, linting, tests and builds run in CI, so code review can focus on design and behaviour.
- One way to do common things. State management, error handling, navigation and API access follow shared patterns, which is especially important in a Flutter codebase that targets several platforms.
- Small pull requests. They get better reviews, merge faster and are easier to roll back.
- Observable systems. Logs, crash reports and metrics are part of the feature, so problems are found by the team before users report them.
Growing people
- Code review as teaching. I explain the reasoning behind a comment, separate must-fix issues from preferences and point out what's good, not only what's wrong.
- Pairing on the hard parts. Working through a difficult bug or design together spreads knowledge faster than any document.
- Room to own things. People grow when they own a feature or a decision end to end, with support rather than control.
Communication
A lot of technical leadership is translation: explaining a technical risk to a product manager in terms of user impact, turning a vague request into a clear plan, or giving a talk that makes a complex topic like Dart memory management easy to follow. Speaking at conferences and organising meetups trains exactly that skill.