001. Communication

The first pillar of effective leadership has a straightforward formula.

Welcome to the very first edition of The Tech Leader Docs. Thank you for being a subscriber!

The first few newsletters will cover the most fundamental pillars of good leadership. Being well-practiced at these will set you up for success in any field.

Every edition will give you practical leadership skills you can take to work right away. Let’s go.

---

Poor communication will tank the best teams.

The good news is that good communication is achievable by anyone. It has little to do with your personality or temperament or even your mood on any particular day.

Good communication is a skill you can practice, and like all skills, mastering it is straightforward: follow the recipe until it becomes second nature.

There's a recipe for good communication. Like other recipes, one of the best ways to learn it yourself is to teach it to someone else.

One of the most important things leaders can do for their teams is to set standards. You can write them down, or lead by example, and hopefully you do both. To ensure people on your team practice good communication, you set a standard for it. In this way, you teach it to them. You follow it yourself.

The main gap between poor communication and good communication is knowing how much to say. Here's the recipe.

1. Don't be lazy

Especially in technical fields like software development, it's good practice to communicate your thoughts to others as if it were the first time they'd ever heard of something remotely like this. Yes, it takes more time and effort (initially). Don't be lazy.

When you explain things with full background and context, you're not assuming the person you're speaking with is dumb. Instead, you avoid making the assumption that they're familiar with what's in your head at the same level that you are. Hopefully, in a strong and diverse team of many different talents and backgrounds, everyone is bringing a slightly different strength to the team. (We'll cover more about hiring a strong technical team in a later edition.)

Since everyone's strengths are slightly offset in terms of focus areas, it's (hopefully) likely that you have more detail about the project, product, or parameters you need to explain than someone else does. If you want to respect your team member's time and not leave them to fumble around for answers later on, don't leave anything out.

This is also useful when explaining things to yourself, which is why I came up with a system for writing good documentation. (That one is public — feel free to share it!)

2. Explain, don't dictate

A benefit of diversity of experiences is the likelihood that your team members will come up with different ideas and solutions than you would. When explaining an issue and the solution you'd like to see, focus on the ultimate results instead of the pathway to get there.

This is a "mission command" style of leadership. In it, you trust that your team is made up of smart, resourceful, creative people. You offer the desired end state, any relevant parameters or constraints, and any other influences on the process that you're aware of. After that, it's up to your team to make it happen. You avoid micro-managing, which is better for both your mental health and that of your team members.

Dictating precise solutions, even when you know the domain well, does not create speed. As a domain expert, you might happily offer resources or common pitfalls that you're familiar with. Dictating the solution path, however, can slow your team down by causing tunnel vision. Team members end up putting all their resources towards a solution that might not work out — at no fault to them — because you haven’t sufficiently emphasized the desired end goal.

Instead of saving time, this only postpones the natural breadth of initial exploration of the solution space to the less-than-ideal, mid-sprint, we-sort-of-started-building-already moment.

3. Define success

Success can be defined in many different ways. Here are a few, to give you an idea:

• The product works really well and the other teams love it

• The product mostly works and everyone is buying it

• The product is finished quickly and management is really happy

• The product took twice as long as expected and the customer thinks it's perfect

• We met the arbitrary success metric

Many different forms of success can be valid, but aren't necessarily intuitive. If your team doesn't know what the metrics are, what the desired outcome is, or who is ultimately going to judge your success, it can be very hard to achieve it.

You team wants to succeed. You have the knowledge of what success means, so share it at every opportunity.

If you don't know what your team's success looks like, you'd better find out. Talk to your boss, your board, or your customers, and agree on something to aim for. Your team needs the direction, and so do you!

Take it to work today:

1. Don’t be lazy

2. Explain, don’t dictate

3. Define what success looks like