The military has many concepts that can be used in software development and I particularly like the commander's intent. The commander's intent captures the commander's and operation's goals, giving the platoon a clear objective to pursue. The platoon focuses on this goal and is empowered to achieve it by the means available even if it doesn't follow the commander's instruction. I started applying these principles a few years back, learning the following.
Movies depict the wrong leadership lessons
Military movies showcase soldiers who fear their superiors more than any enemy they face. Dissent among the ranks is ruthlessly quelled, and any act of insubordination is promptly and severely punished. This compels them to blindly follow orders, regardless of any detrimental effects such orders may have on the person.
Managers in software engineering apply this approach, having learned it from the military or from growing up in an authoritarian household. This management style demotivates many software development teams. It is impractical to micromanage every developer due to time constraints.
The modern military cultivates a culture of mutual trust from the top down and bottom up. Commanders empower their subordinates to execute decision-making with a similar goal. Team leaders in software engineering should consider taking a leaf out of the modern military's handbook.
Military command principles have an impact on software developers. Several management principles employed by the military can be applied in the software development process. I summarized them under ‘Intent as a vital part of mission command.’
Intent as a vital part of mission command
A commander's intent is a clear depiction and explanation of the mission goal. It guides the platoon and ensures the main objective is achieved as expected. The soldiers in the platoon inherit this intent and adapt the mission strategy when needed to achieve their goal. The commander's intent links the mission and concept of operations. Commanders may also use the commander's intent to explain a broader purpose beyond the mission statement. The mission and the commander's intent must be understood two echelons down.
These core principles follow select events and traits from different times and eras. They are all applicable today.
Napoleon’s French forces tolerated junior officers taking the initiative. If soldiers deemed executing an order impossible, they were allowed to act within its intention. The US military established the commander’s intent. This introduced mutual trust, as leaders placed greater trust in their subordinates to act within operational intent when faced with changing circumstances. Communicating intent to subordinates to encourage sharing of leadership responsibilities.
Leaders need to offer more than giving orders. The buck starts and stops with them. Their biggest responsibility is to lead the team instead of controlling every aspect of the project.
The team achieves more when everyone is empowered to handle their responsibilities. A leader who nurtures and promotes this gets the best out of their team members. There's no metric to quantify this aspect, yet it remains one of the most vital aspects of leadership.
The leaders who implement this strategy go unnoticed. They will keep the team on track, facilitating communication, and resolving disputes. Every software developer relies on their team lead to define the project's priorities. I'm responsible for finding the quickest way to get the project back on track should something go awry.
A development team can do excellent software with exceptional teamwork, even with a few bad apples among them. This is less likely to happen if the team has poor leadership. With good leadership, the team can make beautiful and excellent software. I have written an insightful article depicting how you can design beautiful software.
Read: Software Developers Can Build Beautiful Software
How do you incorporate this as a team lead?
The commander's intent is a guiding principle I live by. It follows the hallmark rules of adapting, improvising, and overcoming any situation as it comes. I empower my developers and team with the confidence to take charge of their tasks and responsibilities as the situation dictates. This guarantees maximum productivity and output regardless of the shifting scenario or environment. This is how we implement it in our team.
Ensure you write a "Why" for each task
Developers are far more likely to take pride in their work if they understand the value their work brings to the organization. This also enhances their esprit de corps and overall job satisfaction.
Communicate the "What" behind each task
You'll have developers on your team that work best with minimal supervision, while others may need more guidance. The latter may require a more specific rundown of what you expect them to do to achieve their goals. It is vital to package it as a suggestion instead of an order. Independent developers require much fewer suggestions on how to do their work.
Distinguish between different types of developers
I identify those under my wing that require more guidance than their independent counterparts. It might be counterintuitive to micromanage such developers. Instead, I offer suggestions and let them choose the best action with the end goal in mind.
Regard your developers as your sports franchise
I treat my team like a sports franchise in a competitive league. I am interested in their personalities, goals, ambitions, and development. They are my team and I want to see them succeed and vice versa. We support and cheer each other. A win for one is a win for all of us, and this helps us build our team to greater heights. We expect excellence and great things from each other. We continually learn and improve in our various roles for the greater good of our team.
I motivate my developers. The added motivation may have them write better code faster, push fewer errors, and voluntarily work more hours. Do not mistake motivation for remuneration. Money attracts and retains employees but is seldom a great motivator. A big contract with a poor culture doesn't motivate franchise players and this sentiment applies. Employees want to feel happy about their jobs.
How do you incorporate this as a developer?
You may have little power as a developer to change the workplace culture. Depending on your work environment, you could pass up some suggestions for improving your working conditions.
Open up to your team lead
You can shoot your team lead a few ideas on improving your workplace culture so long as they are receptive. You could ping them this article and let them know what's working for others in the space.
Dealing with an aloof team lead
You can't teach an old dog new tricks but we're dealing with people which should be better. People don't change their attitudes and their behaviors simply by asking them. This also applies to an aloof team lead. Approach them in a non-condescending manner. Engage them with respect, allowing them to offer guidance on the direction to follow. Show a genuine interest in the overall success of the team and organization. Ask why something is vital for the business and why doing it produces the best results for the business and client. They are more likely to give you a concrete 'what' and 'why' that will help you achieve the project goals and satisfy customer expectations.
Make sure to ask their thoughts on whether it would work. I'd suggest something they could consider implementing. It may improve the productivity of various software development phases. Be careful with your delivery, lest it comes across as critical of their management style. I’ve tried and tested this approach in the software development process, bringing about increased productivity.
Read our most recent piece to know why the IT sector is the greatest and why there are many great employment possibilities.
Conclusion
Authoritarian leadership styles are old and practically ineffective in this day and age. Collaboration, trust, and effective communication bear more fruits. It’s easier to catch more bees with honey than with vinegar. This adage is applicable in software development.
I collaborated with my developers to create Goleko. It is a state-of-the-art project management tool that manages projects fast, easily, and simply. This is one of the seven productivity tools I've availed to my team.
For these and more thoughts, guides and insights visit my blog at martinbaun.com
You can find Martin on X
Top comments (0)