This is about a simple method for managing your software projects. The method focuses on three main responsibilities: people management, leadership, and ownership. It helps to prioritise them against each other, and gives a structure to identify and manage tasks within each responsibility.
Let’s look into each of the three responsibilities.
People management includes hiring, promoting and mentoring engineers, performance reviews, providing feedback, maintaining a healthy and productive team environment and so on.
Leadership involves planning, setting goals, assigning tasks, liaising with other departments and/or clients, expectations management and other activities to keep projects on track and complete them successfully.
ownership is about maintaining the technical systems behind the software products that the team is looking after: bug fixing, security, monitoring, alerting, adoption of new and removal of deprecated technologies, technology strategy and road maps, cost management, risk management etc.
To be successful, you need to pay attention to all three responsibilities. However, the amount of attention that each of them requires is not necessarily the same. It depends on the team, organisation, product, the current stage of its life cycle, and other factors. Different responsibilities are important at different times.
For example, a newly formed team has to learn to work together before efficiently delivering and maintaining the product. People management would be most important at this stage.
When the team has gone through forming, storming, and norming stages of its life-cycle it needs to start performing. For a team in an early-stage startup, leadership clearly becomes more important. If the functionality is not delivered on time and the product doesn’t grow, it may be shut down and there would be no technical systems to own and no people to manage. If, the product is mature and requires mainly maintenance, then Ownership would become the most important responsibility.
Within the scope of each responsibilities we can group all the things we have to deal with into three categories which are Issues, Things that are okay, and Ideas:
Issues have to be addressed or accepted depending on their impact on the team. If something is too slow and fails too frequently it has to be fixed. If there is a conflict in a team it has to be looked into immediately and resolved. If a team is unsure how the new functionality that the other team has developed, both the teams need to be engaged to unblock them. Teams with fewer issues are more efficient. Having lots of issues dragging on for a long time affects team morale and performance. Resolving issues promptly improves your team's performance many fold.
Things that are okay:
These things need only to be acknowledged and accepted. No need to fix things that are not broken. If every engineer who is working on an initiative knows what needs to be built and they are on track, there is no need to run daily meetings for status updates. If stand-ups are quick and on-point, there is no need to change their format.
Acknowledging and communicating that certain things are going as planned or are in good shape is important. Otherwise, team members and management would be taking them for granted and would be focusing on issues, including insignificant ones, too much.
Ideas need to be evaluated and, if they are good enough to be implemented, added to the road map.
Collecting and evaluating ideas from the team members and acting on them shows the team and senior management that the manager cares about the future of the team, its members, and the entire organisation. Ambitious and meaningful goals as well as opportunities to experiment with new stuff motivate engineers to stay in the team longer and work with more passion. Not doing that is a signal to engineers that the manager doesn’t value their suggestions and doesn’t care about the future of the team. Best engineers will realise that their growth and careers may be at risk soon and start leaving the team.