Thoughts on Leadership in Software Development
On picture of the world
In the world of software development, it’s common sense to follow the lead of product managers and similar leaders when things get confusing. Why? Because these managers have a broader picture of the world – they understand the market and know what’s important across the whole organization. Essentially, someone with this broader understanding is, by default, a leader.
It’s very tough to keep a broad context up to date for a leader, that’s why both leader and subordinates need to watch out for discrepancies in their pictures of the world and notify each other about them.
On situations when subordinates lead
A good leader knows when to step back and let others take charge. A leader might even ask a team member to teach him something. But here’s a tip for team members: be careful about giving advice to your boss without them asking, as it might come off as rude and lead to unexpected results.
If we want things to go smoothly and predictably, we need to build trust. Trust is like a building with four pillars – integrity, clear intentions, skills, and a track record of success.
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.
On leadership levels
Leadership comes in different levels. I won’t go into details, but 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. Sometimes subordinates drag the leader to a lower level and it’s very sad for everybody.
Obviously, the usefulness of the leader depends on his subordinates. If they know how to be proactive, the leader can do more meaningful work.
Some people don’t like deadlines, but they’re helpful because they let us plan activities around specific dates. It’s way harder to plan things when there’s no fixed time.
Skin in the game is 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.