The year is 218 BC, and the war between Carthage and Rome rages on. Two ancient superpowers are locked in a head-to-head battle for dominance over the Mediterranean. Hannibal, a 28-year-old Carthaginian general, leads his troops through the unfriendly terrain of the French Alps to launch an attack on the Roman mainland. The weather conditions, attacks from the Gallic tribes, and shortage of supplies all contributed to making this march one of the most challenging and celebrated campaigns in history. However, Hannibal prevailed. With his unmatched “managerial” and leadership skills, he was able to overcome all of the challenges he and his campaign faced.

You might be wondering why the heck I’m starting with such an introduction, but if you really think about it, leading a software engineering team isn’t so different from what Hannibal did in the Alps but on a smaller scale, if you take away all the stabbing, marching, and battle parts, of course! Leading a software engineering team under tough circumstances can be a challenging undertaking. Software engineering projects usually go off the rails at some point or another due to changes in business direction, team dynamics, lack of communication, or other factors. Things are constantly evolving and changing, as Heraclitus once said, “the only constant is change.” It’s a simple equation, really. Sometimes, there are just too many balls to juggle, and people are prone to errors.

Why do projects go off track?!

Deadlines looming, budgets at risk, and stakeholders breathing down your neck. Managing projects shouldn’t be that overwhelming. Let’s go through some of the items that might cause your project to go off rails.

- Project planning gone wrong

One of the most famous sayings of Benjamin Franklin is “By Failing to prepare, you are preparing to fail.” Project planning is the first step and the most critical step of the project or sprint lifecycle. In planning you define what you are going to work on, prioritize it, estimate the work, allocate the resources and try to control potential risks. Failing to do any of those items might come back to bite you in a later phase in the project.

Businesses and decision makers usually try to rush engineering teams to start the development process as early as possible. In some cases, business requirements may not be well defined or crystal clear. Here comes your job as a PM or a tech lead, you need to hold the business horses and make them feel accountable to make the requirements reach the definition of ready before moving on. However, it’s also very important to mention that you need to also stay nimble enough to move as quickly as possible. Finding the right balance is tricky but it’s super essential for the success of the project. You need to be thorough and firm, but you shouldn’t cause a case of analysis paralysis in your project. That would be counterproductive!

Once you have your requirements ironed out and the business requirements are broken down to technical use cases, your team should start estimating the work and setting up the initial plan and dates.

This should be a very straightforward task, but that’s not always the case. The business side might request to push the dates to achieve certain business KPIs or business milestones, the estimation might not anticipate risks or issues, etc. As an engineering manager you should make sure that the technical team is taking the right amount of time to develop the software. Rushing the development process is always counterproductive. Technical debts, major defects, performance issues, etc are just normal outcomes for this strategy. However, sometimes engineering teams might not be efficient enough, you need to make sure that you are weighing this on both sides and keep pushing in all directions to move this at the right pace.

You need to also make sure that risks are anticipated within the development timeline. Some big teams actually build their systems in a way in which failures are guaranteed to occur within the system, take Netlix’s Chaos Monkey for example, which deliberately turns off instances while the code is running in production. This might sound counterintuitive but that will guarantee that developers are taking failures into account while writing their code, making the software more resilient.

Transparent and open lines of communication are key aspects in life. Project management is no exception. Humans make assumptions, interpret things differently and their logical reasoning vastly differs. Friendships, vacations, and every single aspect of life is affected by the level of communication and transparency. As a PM, you should master this and you need to make sure that everyone is aligned around the project status, deliveries, timelines, risks and every key aspect of the project. You need to make sure that the action items are groomed, well understood and clear to all the affected stakeholders. Don’t hide issues in the hopes of resolving them behind the scenes, be clear and transparent. Escalation paths should be well defined and clear for everyone. This will empower the team to be more self-managing.

- Widening goal posts

Picture this: a team of highly effective software engineers starting on a very innovative project with a clear understanding of the requirements and goals. Hard to picture that, right? I know!! because that’s not the norm in the industry! In this Utopia, The engineering team will tailor an architecture that fits the requirements, goals and infrastructure to the dot. However, That’s not what happens in most cases. Usually, requirements change, projects evolve and the engineering team is left scrambling to support the flow. This usually contributes highly to the technical debt and defects that systems usually have.

Throughout my experience, I get to sit down with clients frequently to capture requirements and refine details. Interestingly, businesses are usually not exactly sure on what they want. It is down to you and the leads of the technical team to make sure that the client is aware of the scope, and is presented with the best options to implement the functional asks, in order to evade the fiasco we mentioned before. This is usually done within extensive solution discovery calls, Drafting up documents and studying the requirements and the technical approaches needed. I usually start with the critical business needs in the first call and I branch out from there, documenting everything and sharing it with all stakeholders frequently and in a timely manner. Making sure that each requirement is drilled down, well defined and is detailed to the dot, while also holding up all stakeholders accountable for their parts of the delivery.

It’s also important to mention that as a PM, you’re the gatekeeper of the scope of the project. If the business requirements are still not well ironed out or not mature enough, you need to bring that up to the business. Make sure that you are only committing to mature requirements.

However, when the project is launched, you need to make sure that the scope is governed, we need to define a go live plan and any further requirements - unless they’re absolutely critical to the business - should be pushed as fast-follows.

- Promising the sun

Sales folks are definitely the superheroes of acquiring new assignments and expanding businesses. However, sometimes their unwavering enthusiasm might lead them to commit to certain details without proper alignment with their technical team, promising the sun, the moon and the stars to the clients without consulting the engineering side. This is a common issue within big projects and sometimes this might cause missed features, requirement gaps and in some extreme cases might be a showstopper for projects.

Usually PMs are not included in the closing of such deals. So, you need to keep a very open and transparent comms channel with your client, the business side and the engineering side. You need to be aware of any misalignments ASAP. Making sure that it’s captured and it wont come back and bite you in the rear later on. By establishing this channel you can keep everyone aligned on the capabilities, limitations and the deliveries of the project.

- Orchestra without a conductor

The beauty of orchestra is woven in the fact that each individual within the group is a skilled musician in their own right, has a specific talent and masters a specific instrument. All together, if managed right, will produce magnificent musical pieces. Stephen Sondheim once said that “Art, in itself, is an attempt to bring order out of chaos. ”. The conductor steps to the podium, faces the orchestra and with his baton leads the group in perfect harmony. This is exactly the dictionary definition of organized management. One mistake and the whole thing will fall to the ground, shattering the whole piece all together.

It takes the whole team to achieve success. No piece can function without the other and everyone should excel in their specific rules to bring out order.If the conductor is not doing their job, the orchestra would be left scrambling to find their harmony.

Same goes for project management, ineffective management would lead to detrimental results. Bad management can take multiple shapes and forms such as lack of clear goals, unclear planning, poor stakeholder management, Insufficient risk management and contingency planning, Lack of accountability and oversight and poor people skills.

On the other end of the equation lies the engineering team. It is rumored that inefficient tech teams are one of the reasons why startups fail. Usually excellent coding, collaboration and communication skills alongside a high sense of accountability are the main traits that all engineering teams should have.

You as a PM, should always be trying to zero down on any issues that might rise. You need to make sure that whatever the status being communicated by your engineering team is the actual work status on the ground. Hold everyone accountable to their claims. Keep yourself super close to the engineering teams. Find the right balance between championing the client and empowering the people in the trenches. Establish a culture where people are comfortable to share their opinions.

I usually start my projects by letting my team members know that I’m a very transparent, honest and straight up guy. I’ll be transparent about the good things and the bad. I try my best to build a safe and open culture where people can feel safe to share, grow and learn but I let them know in advance that I like accountability and open communication and if things start to deviate from acceptable standards, I’ll be on their tails.

- Handling tech debts

Tech debts lurk in the shadows, silently threatening to hinder progress. Tech debts should be handled diligently and frequently unless you want your product to become a big ball of mud. I like to allocate some time to handle tech debts. That means that around 10% of the development capacity should be reserved to handle tech debts assessed and prioritized by their severity and impact. I also like to introduce a refactoring sprint every 4-5 sprints. Collaborate with your tech leads and make sure you are able to make the client understand the need for handling tech debt. Analyze the system and make sure that they are presented with the business impacts of having tech debts in the system in the short and long run.

TLDR; The secret recipe of a successful PM

People who are focused, open, transparent, good communicators and have good conflict resolution skills will go a long way in the PM practice. To do that, adopt a proactive and collaborative stance within your team, encourage open and honest communication, and build strong bonds with the team and stakeholders. Hold employees accountable, while also fostering an atmosphere that allows for development and learning. Document everything, check deliveries and procedures, and give stakeholders regular updates. Empower those who are in the trenches by continuing to learn and adapt. Create a recovery strategy in advance to handle unforeseen circumstances and make sure that your escalation paths are well defined. By adhering to these guidelines, you may successfully manage projects, safeguard your team, and navigate them with confidence.