Who makes the decisions in your company? Probably lots of people. In most companies, the HR department makes decisions on benefits and salary structures, because they are experts in that area. Typically the CEO and executive board make decisions on where the company should invest in order to maximize their return on investment, because they are the experts in this area.
Who, however, makes decisions regarding how to solve technical problems from the standpoint of chosen solutions and tools and methods used? It should obviously be the software engineering manager or perhaps the senior architect, right? From the title of this blog, you can guess my answer.
I believe—and you may agree—that decisions should be made by the people who are the closest to the problem. But is that really what happens? Have you ever been in an organization where a manager is assigned to the really important and complicated problems nobody can seem to solve? I have. That manager is often the “ultimately accountable” person. Why is this? Often it is to foster effective communication. The manager sits in between the hands-on technical practitioners and senior management as a communication buffer, but why is the manager also the trusted person to solve the problem as a result? The manager also has the power to access tools in some “gatekeeper” fashion. The manager is going to rely on the technical expertise of people closest to the problem to truly solve this issue, so why are the these people not directly trusted to solve the problem? If they are given this accountability, are they given the power to truly be accountable? Are they directly given the ability to access what they need? Can they make decisions or only suggest decisions to the manager, leaving the manager to decide? (Or leaving the manager to go to senior leadership so they can decide?)
I have been asking lots of questions here, so it’s time I get to my point: To maximize efficiency in problem solving, the people closest to technical issues should be empowered to solve those problems in their own way. They should be given the problem, all of the parameters around it, the acceptance criteria for the solution and the authority necessary to access whatever they need to determine root cause and ultimately come up with a solution. They should also be accountable for whatever they decide AND have the opportunity to further adjust a solution should it end up not appearing to have been the best choice once it is put into action. Sure, managers and senior technical leadership can and should be involved, but they should be more in the role of “servant leader” and not “boss”. Therefore they do 2 things: remove obstacles (which can involve helping if asked) and report status. This will allow the people closest to the code to focus and solve the problem.
Note that the 5th principle behind the agile manifesto says: “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” Also note that the 7th principle says: “The best architectures, requirements, and designs emerge from self-organizing teams.” “Self-organizing” means organized by the team members, not the team manager. Additionally, from a scaling agile standpoint, the 9th principle of the Scaled Agile Framework (SAFe) is to decentralize decision making. So you can see there are multiple published points of support for this suggestion.
Technical leaders do have the expertise to understand the problem and eventually the potential solution at some level, but they never know as much as the technical person working directly on the code. They are not coding everyday. They are not hands-on integrating with 3rd party packages and learning about known defects in those 3rd party packages. They are there, but they are not doing the work.
Keep in mind when this happens, these hands-on practitioners will often get promoted as a result of doing so well at solving problems. Then they will be the manager or the technical leader. It is important they remember that they were given the tools and level of trust to solve problems that lead to their success so that they realize, once they choose to move away from the code, that the same rule will apply. They need to let their hands-on folks solve the problems! At first this will be very difficult for them (as well as for the less experienced hands-on folks) because, for a period of time, they may still be “the best”. However, the fact remains—they are no longer in the code as much as others. So let these (newer) people in the code solve the problem.
This post may seem like a no-brainer to many, but what do you see happening? If you are a manager, what do you do? There are many discussions and debates that can, and probably do happen, around this topic, as there are probably many reasons and special circumstances that lead to decisions about how difficult problems are solved. But I'd encourage you to create a culture that lets people closest to the work make decisions and solve problems.
