Becoming a tech leader: my principles

Happiness at work cannot be pursued, rather it must ensue as a side-effect of good working principles.

Extracted from many books in my bookshelf, firsthand experience with a growing organization, and the mentorship of many smart colleagues and friends, these were the principles that I wrote down in my growth plan last year.

On yourself:

• Always strive for the best outcomes - even if it requires difficult conversations.
• Escalate when you cannot adequately handle your responsibilities.
• No matter the circumstance, you always have the freedom to choose your attitude (V. Frankl).

On having goals:

• Being a tech leader means starting with a (problem-solving) goal, and creating a team whose outcomes help you achieve that goal.
• To improve your team, improve its structure (Team Topologies) and grow its people.
• Have clear goals, explicitly communicate them to your manager, and hold yourself accountable to them.
• Lower level goals must be aligned with higher level goals. This is an important relationship in many contexts: project roadmap design, organizational change, cross-team collaboration, and increasing the scope of your responsibilities.
• Your management journey starts at reliably delivering lower level goals and will move up over time, as trust builds.
• Understand that your goals will necessarily have many roadblocks. Learn to navigate pain and produce progress, instead of giving up on “unattainable goals”.
• If you limit your goals to what you know you can achieve, you are setting the bar too low.
• Make sure you're keeping a pulse on progress towards goals.
• Have status meetings with those accountable for goals. Make it about the status and progress towards goals. Identify roadblocks before your team reaches them.

On team management:

• Being a tech lead means you are both a maker and a manager. Make sure to have a working model that supports that.
• Adjust your role to adapt to circumstances, but make sure to communicate them clearly in order to avoid confusion.
• Build trust by: listening, admitting mistakes, offering trust to employees, provide affirmation, and keep a consistent demeanour.
• Great managers have both the creativity and technical skills for management. Engineer your organization by comparing its input and outputs.
• Probe your people without shame but with humility and empathy. Don't be a hawk, but coach people when they make mistakes.
• This is a good order for figuring out solutions: owner, system, then implementation. Instead of putting out opinions about WHAT should be done, help the organization by recognizing WHO should do it. Trust that the right person will figure out the WHAT.

On technical design:

• Ideal design ensues from experience with the system rather than upfront design. Thus, the best approach to ideal design is to make small investments on a continual basis rather than big upfront investments. Put only 10-20% of time towards “ideal design”
• Recognize when those you are talking to are not the best people to challenge you. Seek people who will disagree and challenge you.
• Keep complexity (and peak complexity) in mind. Design deep modules, bring code and infrastructure together under interfaces. Keep pulling complexity downwards (in the stack).

On project management:

• Foster good work habits (regular updates, planning, etc) in yourself and others. Have to-do lists for yourself and make sure your team has them too.
• Push through to completion. Good planners who don't execute their plans go nowhere.
• Communicate plans clearly and have clear metrics conveying whether you are progressing towards the plan you set out.
• Recap your view of what has happened in the project and where the project is going next.
• Give freedom to people but make them accountable for convergence.
• Open mindedly seek the best answers and bring others along as part of the discovery process. Leadership is not whipping people into shape – rather helping them get in shape with their own will.
• Design project roadmaps that produce incremental value.
• Don't bring on people into projects too quickly. Start small, grow, and then shrink again.
• Project to product: in a few years, you won't be managing projects, but rather products. Learn about product thinking.

If you enjoyed this post, you can give me a follow on Twitter: @hkheradm