The Manager, The Engineer's Best Sidekick
How can a Manager be an true added-value on an Engineer's perspective?
Hey, fellow Leader 🚀,
I am Artur and welcome to my weekly newsletter. I am focusing on topics like Project Management, Innovation, Leadership, and a bit of Entrepreneurship. I am always open to suggestions for new topics. Feel free to reach me on Substack and share my newsletter if it helps you in any way.
If you ask any Software Engineer about the added value of a team’s manager, the feedback might be far from ideal. A Project Leader, Manager, or any project-related leader needs to accommodate a lot of expectations from different parties, which need appropriate communication at the right level. Some of these expectations require more than a simple “Current status” on a subject, especially for initiatives that start to derail. This is where might occur a friction between the Engineers and the Leader. So my goal is to give you some tips on how to be the engineer’s sidekick allowing you the lean way you need to push the team for more performance or information.
Firefighter mode: Gain more time and help disperse the pressure
On a software development team, the engineers are best at developing the code for building a product and ultimately fixing a technical problem. Not going to status meetings which might take forever. Some of these meetings might be right in the middle of the morning or afternoon, breaking any concentration or line of thought in the process. This is where a Manager can step in.
The Manager typically is more proficient with political maneuvers and communication than any developer. It is typically part of the manager’s role. If an emergency breaks out, the manager can help by understanding the critical effects and finding alternatives or mitigation strategies, realigning priorities with relevant stakeholders, while the main issue is being fixed. This strategy allows some extra time for the engineers to investigate and test a proper solution. Instead of patching and fixing the problem at the moment, and then having the issue again later.
If the manager can understand how things are progressing, and be able to answer and communicate basic technical aspects, the engineers might not need to join the status meetings. Freeing their time to address the most important part: Fixing the problem in the first place.
Firefighter mode: Leverage on the network. Find a specialist who can help
On complicated technical issues, the manager can be part of the solution, even if is not coding or has a technical background. How? By leveraging on the network.
Complicated problems might require multiple skills that the development team might not have, or are not sufficiently mature. If a team is under pressure to fix something, having a manager constantly asking how things are, is not the best way to help engineers with a problem.
Being part of the managerial side of the organization provides better visibility and allows one to know contacts who can later provide an extra pair of eyes or hands. By leveraging on someone outside the team who can help identify root causes or fix problems. This might prove especially useful on problems that require multiple technical expertise, where a problem might not have a clear path to a solution.
Out-of-the-box training
Typically software engineers are curious individuals and receive new training with open arms. Providing some training outside the typical offerings can be a source of motivation, and improve the product’s quality in the long run.
Examples of out-of-the-box training are Domain Driven Design, Clean Architecture, Use of IA in Development Process, etc. Extra points if you manage to go to the market and ask for tailored training content, with specific points the engineers would like to see covered.
This kind of initiative requires a bit of effort on the manager’s side, but the result could be very positive and well-received by the team. Especially if the team has low expectations regarding the organization they are working on.
Calendar Gatekeeper
There are fewer frustrations for a developer, than checking the calendar filled with meetings. Especially when producing code requires hours of concentration of uninterrupted work. A manager who realizes this can help by not being part of the problem, in the first place, and making sure nobody outside the team exaggerates on the reporting needs.
For the first case, is normal that you would organize meetings with people from your development team. My suggestion is to keep in mind their preferences and avoid scheduling meetings in the middle of the morning or afternoon. I try to schedule meetings at the very beginning of the morning or before lunchtime. I try to avoid afternoon meetings with my team members and try to provide the maximum of hours in a row for them to code peacefully.
For the second case, please note depending on the organization, scheduling meetings with a developer is regarded as an added-value task and a sign of progress monitoring. Especially for non-technical areas like Business or Product. Once I got a project where one individual alone, was scheduling a status update meeting every single day, for one hour long with the developer. Of course, these weren’t only status updates, but an opportunity to add scope creep. I immediately tried to stop the approach and got escalated from the Business side with the argument I was acting as a roadblock for communication. Firstly, hijacking another’s team resource is out of limits without the consent of the manager. Secondly, requirement changes on a project cannot be done without proper tracking and there is no need to schedule 5 hours of follow-ups per week. Unfortunately, the code is not done on its own and there isn’t any technology that converts speech into code (at least at that time).
Communication coach
Coaching can be an important task for a leader and a way to upskill a team member. One of the most unappreciated and undervalued skills of technical staff is their ability to communicate properly, even between technical parties. There is a degree of mindset among engineers the technicalities are self-explanatory and if someone else doesn’t understand is because they lack the skills for it. In reality, what happens more often than not, the way the message is delivered is below optimal.
Is incredibly important for an engineer to be able to communicate efficiently. Especially while handling difficult scenarios, where problems arise and a multi-step strategy might be needed. The image of having a software developer doing the coding alone on the laptop, wearing headphones with classical music, and only providing status on a JIRA ticket, cannot be far from what is expected.
Here the manager should create awareness and examples, of how the communication could be improved. The engineer should be allowed to acknowledge that having poor communication and lack of feedback will hurt the career in the long run. Even for someone hard-working and with good technical skills, communication, or the lack of it, can be the reason leadership roles wouldn’t be given to that person. Of course, there are examples at big organizations of Technical Architects who struggle to share an insight clearly, let alone in a foreign language. But these will be the exceptions in a globalized and remote working setting. The engineers who will improve in this area will be the ones thanking you the most in the long run.
That’s it. If you find this post useful please share it with your friends or colleagues who might be interested in this topic. If you would like to see a different angle, suggest in the comments or send me a message on Substack.
Cheers,
Artur