Over the past few years, I have grown into a hands-on Tech Lead Manager (TLM) role. I still deliver technical work while managing engineers, making product decisions, and building the team. After reading several books, I tried some of their ideas in practice. I wanted to record what worked, what fell short, and what I am still figuring out. These notes cover the role itself, management planning, team building, and day-to-day execution.
I currently work at a small, geographically distributed vertical AI company. These are personal observations shaped by that specific environment, with no claim to being a universal management playbook. I have omitted identifying details, and the people in the examples below are fictional.
A lot of people move into technical leadership this way: the previous lead leaves, and someone else has to step up. That was my path. When the Tech Lead at my previous company left, I became the de facto Tech Lead. I took over delivery, technical decisions, mentoring, code reviews, and cross-team coordination, including finishing a half-built external SDK across three client platforms.
Many of my friends love code for its own sake and care deeply about elegant architecture. About a year after moving to Singapore, I realized I was becoming more of a problem solver. Two and a half years on infrastructure teams let me explore difficult technical problems. I also supported other engineers and the long-term evolution of our products. That experience gave me enough material to write Extending Android Builds.
Later, moving countries and companies widened my path again. Writing the book and becoming a Google Developer Expert shifted my focus as well. I began working more on communication, design, and projects where a broader perspective could help others.
My technical scope is now wider. It includes Android and iOS architecture, UI/UX systems, evaluation for AI workflows, and data analysis that can reveal product needs. In a first-line startup role, I still stay close to implementation. "Vision" is not a reason to lose touch with the details.
Today I work as a hands-on Tech Lead Manager and cover part of the Product Owner role. The work moves between collecting data, writing a PRD, and making architecture decisions. As the company evolved, I became part instrumentalist and part conductor: a supportive, highly engaged player-coach.
Two opposite management failure modes help explain the distinction:
Support requires context and concrete action. Involvement should help other people take ownership.
Early in my current role, I wrote down a few reminders for myself:
I also follow a few quieter rules as an engineering manager:
Teamwork is the clearest thread running through how I define the role:
I organize management planning around four questions: mandate, goals, team, and execution path. Maintaining the Android and iOS products is the baseline mandate of a Mobile App team. I also ask what additional value that team can create:
Goals deserve the same scrutiny. Doing the work correctly is often easier than finding the right work. In many startups, taking the right goal to 80 percent matters more. It often beats improving an established area from 90 to 92 percent. Keeping the mandate flexible and adjusting direction have been some of the most rewarding parts of the job.
The technical path depends on the team and how the business makes money. Some consumer companies acquire users through paid ads and run a portfolio of products, hoping a few become hits. A vertical subscription business grows through long-term retention. The two need different technical paths.
A portfolio business may prioritize reuse, low launch costs, and fast experiments. A subscription business may care more about reliability, product quality, and long-term maintainability.
A popular technology is not always the right choice. The real question is whether it helps the business retain users and stay ahead of competitors.
When several technologies fit both the business and the team, my checklist looks roughly like this:
Coding Agents do not remove the human side of these decisions. Asking an agent to understand a codebase as large as AOSP and find the right solution remains difficult. High-impact choices still depend on context and access to expertise.
The remaining question is the team itself: who we need, and how their strengths fit together.
A team feels more like an orchestra to me. There are different players, principal players, and a conductor, but everyone contributes to the same performance.
Large companies often standardize hiring for consistency and scale. Standardized interviews often favor candidates who know how to prepare for them. Strong candidates with less conventional backgrounds may be overlooked. A startup can collect a wider set of signals:
No one can understand another person in a one-hour call. Three to five focused conversations can provide independent signals, as long as the process respects the candidate's time. I would build a Mobile App team around complementary people, rather than a checklist of Android, iOS, and Flutter job titles. It might include:
Working in multinational companies broadened my view of what a team could look like. Demographic representation matters, and so do differences in professional background, product exposure, language, and problem-solving habits. Together, they affect team resilience and the range of options available during planning. Hiring can never be perfectly objective, but team composition can still be deliberate.
Experience is also harder to read now. One candidate may have eight years of professional experience but resist AI-assisted development. A recent graduate may have eight years of programming experience. Similar trade-offs appear between technical depth and breadth, or between business knowledge and familiarity with the current stack. AI can produce a lot of code. An experienced specialist can still spot a weak signal and act on years of context. I value people who can see what they need to learn and close the gap to a useful 60 percent quickly. They also need to work with the untidy constraints of real products.
A friend uses an interview question I like: "Tell me about a product you think is well made, and explain why." I browse Mobbin for design references for the same reason. Real products expose judgment in a way an abstract question cannot. For some roles, another standard interview round may not tell us much. A paid, time-boxed trial or a short pair-working exercise can reveal more. So can asking a candidate to build a small tool with a Coding Agent.
Most experienced technical professionals already have the basic discipline to manage tasks, and clear SOPs can improve it over time. I think task management and Agile receive more attention than they deserve in small, experienced teams. Coordination roles lose leverage when they are detached from product and technical context. In a large, regulated, or dependency-heavy organization, a strong TPM or Scrum Master may still be essential. The test is whether the role resolves real constraints or maintains reporting machinery.
Even if a particular practice makes one step in an SOP five or ten percent more efficient, the returns eventually flatten. In practice, the process still has to fit the project. A mobile app rarely ships a new version every day, while a web product may ship several times a day.
Teams still need clear priorities, dependencies, and timelines, but heavier tracking does not create ownership. Avoid changing direction in a morning meeting and expecting results that evening. A written plan, agreed timing, and enough context remove a great deal of friction.
Day-to-day delivery is shaped by both team routines and what we expect from individual engineers. The 10x engineer is often misunderstood as someone who writes code ten times faster. I think the real multiplier is learning speed. An engineer who can enter an unfamiliar area and quickly become a domain expert may deliver far more than ten times faster. Coding Agents already generate code quickly, so raw coding speed is no longer a useful comparison. What matters is how fast someone can find the right problem, build the necessary context, and turn that understanding into a working result.
Many people spend years searching for the perfect to-do app and end up using the one built into their phone. At work, try a blank document: list what the team needs to do next, grouped by release, week, or sprint. Let the project determine the process, then return your attention to the work in front of you.