Divide and Conquer! An approach to software engineering project management.
Tags: career, publicspeaking, development, projectmanagement
Published: 2021-09-07 04:51:05

---
title: Divide and Conquer! An approach to software engineering project management.
published: true
description: what do Software Engineering, Project Management, Political Strategy and Public Speaking have to do in the same article?
tags: #career, #publicspeaking, #development, #projectmanagement
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xe1q4saa4koq6x21ba6l.png
series: Public Speaking and Leadership Skills - Toastmasters Pathway
---


## Divide et Impera!

_Divide and conquer!_ : in politics and sociology, it is _a strategy of gaining and maintaining power by breaking up larger concentrations of power into pieces that individually have less power than the one implementing the strategy._ [wikipedia](https://en.wikipedia.org/wiki/Divide_and_rule)

Basically, split the forces of your enemy into smaller groups or individuals, which are easier to control and defeat.

Wait,  what has that to do with project management in software engineering?

Do I mean to **isolate and weaken the individual team members** so that they can be easily _ruled_, sorry, **managed**, and that the goals can be achieved without any form of dissent?

Of course, not!

But how could I achieve the goal that was assigned to the team I was working with - 20 developers, more than 1 million lines of code, more than 15 thousand errors, hundreds of features to be rewritten - if not with  Divide and Conquer!?

> _Software development is the act of breaking a complex problem down into smaller problems and composing simple solutions to form a complete solution to the complex problem_.

This is actually true for any big task, it helps if you break the task down into smaller, more manageable parts. **Little piece by little piece, the big task is less intimidating.**


> “How do you eat an elephant?"

>“Easy — One bite at a time”

### So what did we do in practice?

- we individuated 4 **macro-areas of intervention** within the project/codebase.

- we split the team of 20 + people into 4 **squads** who could focus on one of these 4 macro areas independently - almost.
 
- we run an **analysis** on features and errors, aggregated them, and then split them into categories that were assigned to the different squads and individual members who were in charge of that category.

- we made iterations more frequent.  instead of monthly deadlines, we were reassessing our status weekly ( at the beginning we did not even have anything “showable” if not that the number of bugs (defects) and errors was decreasing…) and eventually, **re-adjust course**.  


Not everything though could be broken down in smaller bits, nor was it advisable.

### Where did we not divide instead?

- Decision making: **devs can be solitary animals**:  but we didn’t want to have a developer working on his task alone, just to realise after days or weeks the solution was wrong or did not fit the big picture.   So,  we had iterative coding design sessions to discuss solutions collectively ( within the small groups though).

- Knowledge sharing:  weekly present some interesting solutions or learnings to other team members.
We dismantled **Silos** and **Towers of Knowledge**: especially with this high churn rate - we could not afford to have someone be the only one responsible for doing things or knowing how to do certain things.

- Helping each other:   **devs are stubborn and like challenges** - but we could not afford people being stuck for hours, or days on a problem - so we enforced “asking for help, or seeking people in need”  30 minutes of struggle → shout it out to the team:  **maybe someone already went through a similar problem and already has a solution**.

In the end, **by combining an atomic and aggressive approach to the problem with a mutualistic approach to the people**, we were able to reduce the scope and increase productivity.

[By working on a smaller scope](https://dev.to/dvddpl/the-biggest-advice-i-could-give-to-another-developer-3jme), we could ignore the rest.
[By avoiding distractions](https://dev.to/dvddpl/you-have-only-limited-time-and-attention-eliminate-the-noise-4f0b) we could improve focus 
By having a shorter feedback loop -  _"Do something, Make sure it is ok, Rework or Move onto the next task"_ -  we improved our speed
By sharing the struggles, celebrating the progress, sharing knowledge, and showing help to each other, we **fought frustration, insecurity** and a sense of impotence in front of a massive task.
And in the end, despite all my predictions, we made it.

As Francis of Assisi said: 

>Start by doing what’s necessary; then do what’s possible, and suddenly you are doing the impossible.


-----

This is the transcript of a speech I gave at my local [Toastmasters Club](https://www.toastmasters.org/) (an international organization to practice public speaking and leadership skills) for Level 4 of my [Innovative Planning Pathways](https://www.toastmasters.org/pathways-overview/pathways-innovative-planning-path) where I had to write and present a speech about my experience in a project. 

You can consider it a **fictional story**, although a lot of what is described there comes from my **direct experience**.  

I hope you find it interesting and of some help.