People management is always demanding and exhaustive. While challenging, the solutions depend on the type, expertise and seniority of the people you manage.
As a manager of a team of solution architects within a large program of over 100 people, I understand the importance of a tailored approach. With approximately 9 architects, each leading a squad, most teams manage their backlog effectively. However, one squad consistently struggles with this issue. That squad had an architect. Let’s call him Mr.LateNighter.
The backlog contained many change requests and improvements, which has affected their ability to develop new modules.
Discussing with Architects, managers, and scrum masters in a one-on-one setting did not yield concrete results. There was always a mix of signals, and the architect complained that he had a lot on his plate and could not take on new modules.
How I Handled it
Another member of my team had capacity. Let’s call him Mr.Smarthat. Smarthat has completed the design for most of his backlog. After discussing this with Smarthat, I told the project manager for Mr NateNighter that I would give Mr.Smarthat. Smarthat will be the solution architect for the new module.
While communicating with the PMO team, I told them that while we could solve the solution architect problem, what the developer would work on was still a problem and also needs to be solved quickly.
What difference It made
The above step immediately solved two problems
- By highlighting the development problem, the Project managers were reminded of the bigger challenge: that design alone is not going to solve the problem.
- Once they realized it, they discussed more assertively with the product team on a more realistic backlog, de-prioritizing the less impactful change requests.
- Mr Latenighter realized that another person could take his place if he exaggerated smaller problems and delayed the issues at his disposal.
The Result
The day after communicating the decision, the PMs discussed it discussed it with customers, Latenighter and other critical stakeholders in the squad, and it was decided and agreed that the design of the ongoing change would be closed in a week, and the design of the new module would start next week. This was mentioned in the Slack channels and agreed upon by Mr.Latenighter as well.
What I learnt
While threatening is an agreed-upon strategy for getting people to do it, doing it subtly requires a lot of planning, attention to detail, and playing different cards with different stakeholders.
Another aspect: I should admit that this strategy worked, as my honest intention was to help Mr Latenghter’s team take up new things and enable him to have a better work-life balance. Once you make honest efforts to solve your team’s problem, people respond positively, go out of their way, and the problem gets solved.
Life & Thoughts of Hariharan Anantharaman 