The Four Pillars of Engineering Management

The Best Project Managers Aren’t the Loudest in the Room

Những quản lý dự án giỏi không phải người nói nhiều hay ồn ào nhất, mà là người tạo ra sự rõ ràng, giảm thiểu xung đột và hỗ trợ nhóm một cách âm thầm. Họ lắng nghe trước khi nói, đặt câu hỏi để hiểu chứ không phải thách thức, nhận biết ai đang mất tập trung và giữ bình tĩnh dưới áp lực. Công việc thực sự của họ thường vô hình như điều phối mọi người, thúc đẩy quyết định, cảnh báo rủi ro sớm và quản lý căng thẳng cùng kỳ vọng.

Lập trình viên nên đọc bài này để hiểu cách một quản lý dự án hiệu quả thực sự tác động đến hiệu suất nhóm thông qua sự lắng nghe, giải quyết vấn đề ẩn và xây dựng môi trường làm việc nhàn nhã, không phụ thuộc vào sự nổi tiếng hay tiếng nói nhiều.

I Have an App Idea: How to Bring It to Life

Bài viết hướng dẫn chi tiết cách hiện thực hóa ý tưởng ứng dụng (app) từ khâu xác thực, bảo vệ, lập kế hoạch sản phẩm, tìm đối tác phát triển, xây dựng MVP, huy động vốn, ra mắt đến marketing.

Một lập trình viên nên đọc bài này để tránh rơi vào sai lầm thường gặp khi chuyển ý tưởng thành sản phẩm—từ việc bỏ qua việc xác minh nhu cầu thực tế đến thất bại trong việc phát triển và quảng bá một cách hiệu quả.

50 Articles That Shaped My Thinking

A curated collection of 50 essays from three years of writing about engineering leadership, culture, people management, product strategy, and technology. Organized into seven themes — Leadership & Vision, Culture, Managing People, Product & Strategy, AI & Technology, Personal & Professional Growth, and Change & Adaptation — each entry includes a brief summary of the core idea, from adaptive leadership and culture debt to AI adoption cycles and systems thinking for organizational change.

7 reasons experienced EMs get stuck

Experienced engineering managers often stall in their careers by repeating predictable mistakes, even when they're aware of them. Seven key traps are identified: confusing title with impact (a Director title at a small scope is misleading), equating team size with importance, blindly applying tactics from previous companies, over-delegating to the point of abandonment, using authority instead of reasoning, under-delegating due to lack of trust, and focusing only on problems while neglecting recognition. The author draws on personal experience, including a failed startup and a humbling return to an EM role, to illustrate each pitfall with candor.

We Tried Agile and It Didn’t Work

When teams say 'we tried agile and it didn't work,' leaders should treat it as diagnostic data rather than resistance. Common failure modes include adopting agile ceremonies without changing decision-making, weak product ownership, excessive work in progress, symbolic empowerment, and leaders delegating agile to teams without changing the surrounding system. The post outlines a five-pillar diagnostic framework (mindset, practices, roles, teamwork, outside-the-team support) and a practical recovery path: acknowledge the previous experience honestly, name a concrete outcome, pick one small visible improvement, maintain an improvement backlog, and inspect results. Skeptics should be engaged as sources of information rather than dismissed. If the word 'agile' carries too much baggage, leaders can pursue agile goals under different framing.

Blog: The Context Switching Tax: Why Engineering Teams Ship Less Than They Think

A Microsoft Research study of 484 developers found engineers spend only ~11% of their week writing code, with communication and meetings consuming even more time. Context switching is identified as a major hidden tax on engineering capacity — Gloria Mark's research shows it takes 23+ minutes to regain focus after an interruption. The post argues the constraint on roadmap throughput is attention, not headcount, and recommends four fixes: protecting contiguous focus blocks, auditing and cutting meetings, limiting work in progress, and reserving senior engineers for high-judgment tasks. The piece closes with a pitch for Wawandco's embedded engineering teams.

Why Scrum Isn’t Working Even Though You’re Doing Scrum

Organizations often implement all the Scrum ceremonies and roles yet still fail to see the expected benefits. The core problems are: Scrum events becoming empty rituals rather than value-generating activities, sprint interruptions being treated as costless when they erode team trust and focus, organizational lack of prioritization pushing too many demands onto teams, leaders not creating the right environment for self-managing teams, Scrum Masters staying too close to the team instead of removing organizational impediments, and excessive rules making Scrum feel like bureaucracy. The recommended approach is to apply Scrum's own inspect-and-adapt principle to improve Scrum itself — identifying the biggest root cause and experimenting with one change at a time rather than attempting a big-bang reset.