In early September 2026 I posted a series of X threads that outline my practical playbook for engineering leadership. The posts cover company politics, self‑directed learning, execution habits, psychological safety, AI‑value framing, elite‑team signals and the player‑coach role.
I treat dealing with company politics as an implicit part of the engineering leader’s job because “dealing with company politics” and being able to deal with it well is actually part of your job as an engineering leader, there’s just not any official requirement for you to do that.
I own my learning: “You’re responsible for your own learning. Don't wait for others to "let you know" what you should learn. Take ownership, define goals for yourself and keep learning!"
Side projects are the best way to grow: “Side projects are a really great way to grow. There is no better way to learn new technologies/concepts/frameworks than building an actual project.”
Software estimates are educated guesses, not promises: “Software estimates are educated guesses, not promises. Ensure stakeholders understand uncertainties and stay informed as a project progresses.”
Writing clarifies thinking: “Writing forces you to clarify your thoughts and uncover gaps in your understanding. Whether it’s documentation, design docs, or blog posts, writing sharpens your thinking and communication skills.”
Prioritise finishing over starting: “Don’t just start things. Finish them. Prioritise execution and delivery. The most successful people in tech are the ones who consistently get things done.”
Psychological safety drives initiative: “When people get blamed for their mistakes, they stop taking initiative.”
Imposter syndrome is universal: “Don’t let imposter syndrome hold you back. The secret is that everyone has it, just some people decide to "ignore it" and do the thing anyway.”
A brag list makes achievements visible: “1) Keeping a brag list of all the wins that you achieve”.
Elite teams optimise the outer loop while average teams optimise the inner loop: “Elite teams optimize the outer loop, learning faster and driving real impact.” and “Average teams mainly optimize the inner loop, focusing on writing/generating code faster.”
Business understanding is critical: “Understanding the business isn’t optional, it’s critical for making good technical decisions.”
Add complexity only when necessary: “Start simple. Only add complexity when absolutely necessary.”
Prioritisation question: “Ask "What happens if we do nothing?" to gain perspective on priorities.”
Effective 1:1 meetings follow a template: “Effective 1:1 meeting notes: - Agenda Items - What’s going well - What’s bad - Feedback - Action Items”.
AI value framing: the right question is “How much more value can we create with AI?” and the wrong one is “How much more can we build with AI?”.
Player‑coach role spans coaching and hands‑on work: “They are also a player: This means they are writing/generating code, reviewing/creating technical specifications, resolving production issues, building MVPs/prototypes, etc.”
Visibility limitation: “No matter how great technically you are, weak relationships and low visibility will limit your influence and opportunities.”