The rise of planners
When brick-and-mortar companies first discovered the power of computing they saw the opportunity to leverage software for the only thing that matters to companies: making more money. By leveraging this sleepless machination capable of pushing data to all corners of the world, locality was no longer a problem. Automating repetitive tasks, running the business at all hours, and even scaling operations across the globe became within reach. It is in this gold rush of information that the software development lifecycle practices and tools we use today originated.
One of the constants is, to the surprise of none, the search for ways to make software in a cost-effective way. Nowadays, the common wisdom to achieve this goal is to rely on a variety of roles and disciplines that collaborate to make software. One such role, whose sole responsibility is keeping the flow of work unimpeded, is the “planner”. You may know them as Product/Programme/Project managers, SCRUM masters, or “that person with the Gantt chart”. Regardless of the name, they are the ones that usually guide the efforts of others.
Types of software projects
When you analyze software based on the goals of the organizations that birthed them, you find two broad categories: Software as a tool, and software as a product.
Going back to our old-school businesses, the creation of software has, historically, been a means to an end. In these organizations, the software is usually created to enable or enhance business capabilities to help it make its product more profitable. These companies are the majority.
On the other end of the spectrum, you have organizations that make their entire product offerings with software. Funnily enough, those often sell process-enhancing tools to the other group. Think of all the Software-as-a-Service contracts that float around the industry.
The dictatorship of planners
In the pursuit of effectiveness, some planners decided to shrink the informed forum as much as possible, concentrating expertise and expediting decision-making. Those select few would then be responsible for leading the rest across the minefield that is building useful software.
Centralizing information, thinning communication lines, blocking outside influences, holding unchallenged assumptions, and monitoring others with obscure measures; Planners eventually become dictators.
Maybe this wasn’t the intent initially. It could have been born out of a desire to protect their team’s precious time. Or maybe it was born from a lack of trust in the decision-making skills of the others. Regardless of the intent, the oppressed resent it.
A problem for the majority
Before going too far, I would like to remind you that, while I do not believe this is done consciously out of malicious intent, I do believe in the negative impact that such a practice has. Additionally, just like other rant-induced (and perhaps cathartic) essays you see published across the industry, these problems are present in the majority of engagements. Not all, just most.
Finally, while I am making these claims without the analytical receipts to back them up, I do believe I speak for a majority of people involved in the software industry. This being the case, I will pull no punches when denouncing these bad practices, so that hopefully we grow out of them as an industry.
How it feels
Being kept disinformed and goalless, teams churn away at the work. Without an understanding of what they are trying to achieve, sloppy work is done. That work is then measured, arming those who mistreat the team with tools to push even harder. All this push tries to meet demands no one understands.
By robbing the team of agency and knowledge, they:
- Don’t understand what they are building;
- Don’t believe in the plan;
- Don’t care about building the correct thing;
- Don’t correct incorrect assumptions;
- Don’t care about their effectiveness;
How it perpetuates
All these negative feelings, in turn, drive team members away. Any little knowledge they gained through sheer stubbornness, as well as all their expertise regarding the inner workings of the software itself, vanishes. And so, another fresh, ignorant, member joins the team.
Unfortunately, remedying that ignorance is too costly, so the knowledge centralization strengthens, and more alienation ensues. This is the perfect excuse to go further in the dictatorial direction.
And thus it repeats.
Is it time for a change?
If you’ve identified your planner, processes, or even yourself in the previous text, it is time for a change.
To be able to serve your businesses, you must deliver useful software effectively.
To achieve this, some of the previously held wisdom stands: You must understand what you are making. However, it doesn’t stop there. In the case of software, you must also understand how you build your software.
Incidentally, if you work for a company where the software is the product, there is no excuse. You must understand your software, for it is your business and your process.
From planner to enabler
The change needed is simple but deep. The role of the planner should not be an exercise of control, but an exercise of trust and understanding. Stop being a planner, and become an enabler instead.
Enablers have a couple of characteristics that make them invaluable to their teams: They share information, establish strong channels of communication, embrace external influences, validate their assumptions with others, and empower their peers to do more.
To do this, make no mistake, they still need a vast amount of knowledge about the business and product. But beyond business acumen, they must also understand all the pieces involved in building software to a degree where they, at least, can communicate effectively with others. Their expertise is a glue that holds the team strongly together.
Start the change
This change won’t come easy, and it won’t happen overnight. But it must come if we want our industry to be sustainable and successful for years to come.
Our industry is known for having a “continuous learning” aspect to it, and this is true for enablers too. With every new project and every new requirement, something new must be learned. And it is in this spirit that I would like to provide you with some tips to start this change today:
Share your domain understanding with your team
Spread the knowledge, share your assumptions, and validate them as a team.
This will help all of those involved not only to understand what they are building, but also give them the necessary knowledge to make good decisions.
Pair with your team
Get together with your team members and work with them.
Be it code, design, infrastructure, testing, whatever. Pair with people from all disciplines.
This will serve to bootstrap your knowledge of how they work, as well as give them a direct channel to ask questions. It will also serve to repair the previously broken trust.
Just be mindful and try not to control how they work, they are the experts, and you are there to learn.
Create goals together
Share the reason behind the objectives with your team.
Collaborate with them when deciding which metrics to track, as well as how to track them.
I recommend reading this article as a starting point.
Closing notes
Finally, I would like to touch upon some things I have ignored thus far.
First, planners also have skills that benefit the team. Those skills might be taught with different contexts in mind, but they still generally apply to our field. Be mindful when making the change to enablers to not lose those benefits. The issue was not with the skills themselves, it was with the way they were applied.
Secondly, it is imperative that teams trust each other. Despite my harsh criticisms towards planners, the change is impossible to achieve unilaterally. To this end, if you are starting this change, communicate about it. Share my article if you want, but at least talk about the change you hope to achieve and ask for support.