Leadership in Software Development

If in doubt, engineers should do as product managers say. This is because product managers have a wider context. For example, they’re aware of the market. They also know priorities on all levels of an organization.

A person having a wider context is a leader by default. A leader can step back sometimes and let others lead. For example, he can ask subordinates to teach him. Subordinates should be careful because teaching the leader without invite may be considered rude and may lead to unpredictable results.

To make results predictable and good, we must cultivate trust. Trust resides on integrity, intent, capabilities, and results.

That means a party in a relationship builds trust when:

• Actions match their values and beliefs.
• Its motives are clear.
• It is capable of completing a task.
• It has a good track record.

There’re many levels of leadership. For example, level 0 is when a leader does not fight for the ability to lead. Level 3 is when a leader does not give orders directly anymore. Level 7 is when a leader becomes a legend and doesn’t need to contact subordinates anymore. Subordinates must help the leader to raise his level. The leader should patiently explain the rules if they’re not aware of them yet. The usefulness of the leader depends on his subordinates. If they know how to be proactive, the leader can do more meaningful work.

It’s very tough to keep wide context up to date for a leader, that’s why both leader and subordinates need to watch out for discrepancies in world views and notify each other about them.

Trust and deadlines improve outcomes for large projects. I explained the part about trust above. Some people don’t like deadlines, but I do. They help because it’s easy to plan activities around definite dates. It’s very hard to plan a multistep activity when you cannot bind it to anything.

Skin in the game is also very important for outcomes. Exactly one person should feel personally responsible for a project or a feature. Otherwise, nobody is responsible for it, and it will fail. Responsibility for all features or projects should not be on one person. It’s best when different people on a team are personally responsible for different features and communicate about them with other teams.