Unexpected Project Failures
Until recently, I was working at a large software vendor in Japan for five years, in which we offered web/tech solutions to many non-tech clients.
There, I observed several big projects that endlessly continued without seeing a single product release and the candidate release date kept postponed for a few times even though the team consists of experienced project managers, product owners, and average developers. Weird!
I was lucky to witness another type of project which managed to release new products and features even though
the team only had an inexperienced manager who was also a former developer but had one 10x developers as well as other middle-level developers. Their project management had some mess and the overall quality of the product experience had room for sophistication, but they kept making progress.
Observing these two different types of project's outcomes left me with an important lesson to learn, whose value and practices are still worthy of attentions in most projects nowadays.
I compared these two types of projects attentively and gave thoughts on what characteristics had a significant impact on better progress. In the end, I found two keywords which are surprisingly related.
The opposite of prioritization
To begin with, can you answer the following question with confidence?
Quiz: What is the opposite of prioritization in the context of a software development project?
I guess most people would never thought about it.
Short Answer: Outputs
Outputs here mean the amount of technical design, implementation, and testing you have attained in a certain period of time: namely, one day, one month, or one quarter.
It would be surprising for you to know these two keywords are correlated in the context of software development and actually mean the opposite. But I guarantee that achieving high outputs will lead projects to finish.
Prioritization, Prioritization, Prioritization, BUT...
I bet you have encountered the situation where a project manager repeatedly emphasised the importance of prioritizing tasks - sorting out the tasks in the urgent order.
And for the sake of better prioritizations, more communications were encouraged among project managers, engineers, and stakeholder. Hence, teams increased the number of meetings to once or twice every day.
Prioritization has pros but also cons! It is not a silver bullet.
Pros:
Prioritization makes a team focus on finding critical problems for users, identifying why these problems occurred, and quickly fixing them with a few lines of code in an urgent manner. This type of management style is suitable for already released and maintenance products.
Cons:
The problem with this prioritization-centered approach appears vividly when a lot of new features are to be developed, and more foundational work is needed with a lot of effort. But both prioritized task executions and solid foundational work are hard to achieve simultaneously for the following reasons.
1. Prioritized tasks vs development order
Tasks sorted by prioritization are often less efficient for development productivity because prioritized tasks pay more attentions to something that are visible to users/stake holders, while it would be actually easier for developers to start with the foundational part.
I prepared an intuitive illustration of pyramid construction below, a visible analogy to software construction.
As you can imagine, constructing from visible parts requires more efforts for each block and is not robust. It may even sounds ridiculous but this is often a reality.
On the other hand, constructing pyramid from the foundation can make more progress with the same effort, but would be less satisfactory to users.
As a result, for the same amount of effort, construction from the foundation can be 12 blocks ahead of construction from what are important to users.
2. Context Switching Cost
Frequent prioritizations must come with the context switching of tasks for developers, but it comes with a high cost, as many experts have already suggested (e.g. this article). Developers outputs will decline sharply if their priority tasks are changing even a few times a month.
3. Development Mindset
Priority-focused teams tend to forget the value of foundational work and only do minor fixes on the surface to solve urgent problems. But the system internals becomes messier with the accumulated temporary fixes, which deteriorate the long-run productivity and extensibility.
Project Manager A: Documentation is of course important but we don't have time to fix this document now. It is not prioritized.
Engineer Lead B: Such a feature is desired for the safe delivery of this service but we are short of hands and cannot spare time for it now.
When conversations like the above are heard in your project, that is an indicator that the importance of the foundational work is ignored and the product's development productivity is impaired in the long run.
Why outputs of work is important in a project?
So how can we handle the other type of development?; there is no strict deadline for each task, but the entire roadmap is heavy and long because a lot of new features are to be integrated into the product.
As you may know, the more components are involved in one product, the more fine integrating works are needed. Interface adjustments get severer, integrated testings get to be more important, more integrated documentations are desired as well.
That is why MAX OUTPUTS Strategy comes into play. Contrary to the frequent prioritizations, the project focuses on the amount of outputs team members produce each day. e.g., pull requests, issue tickets, and design documents.
Since there is no strict deadline, members can focus on laying the groundwork for the product - building the components from the bottom layer one by one, which makes the product robust and stable in the long run.
While the main motivation for prioritized work is urgency, the essential motivation for this type of development is development tempo, which sets the basic amount of outputs produced everyday. Because tasks have somewhat similar traits in terms of volumes, qualities, and flows, developers aim to attain the same quantity of outputs everyday.
For the sake of MAX OUTPUTS of team members, more quiet working time is introduced. Each member focuses on their assigned development tasks and they are encouraged to produce more outputs. Hence, teams tend to show their work by commit logs, pull requests, or testing outputs.
Why 10x developers are valuable in software development project
The above comparison between prioritization and output makes it easier to understand why an inclusion of 10x developer matters to the overall progress of a project.
A lot of software development are actually expected to develop new features rather than just maintenance the service. And thus output of the project is relatively more important than fine prioritizations.
As I said in the beginning, I saw some large projects fail, which put emphasis on prioritizing tasks and fixing some hot issues appearing on the surface but ignored the importance of building the vast volume of (foundational) works for the project. I believe that this happened because these project managers did not have large software development experience in the past.
At the same time, I also witnessed the participation of 10x developers in a project often solved the project stagnation. They are skilled and mostly quiet in team meetings. They solely focus on adding features and fixing bugs to reduce the issue tickets. They are also good at scaffolding the foundation on which other developers can build components safely, smoothly, and neatly. Yet, their values are often underrated because they prefer hiding behind others and keeping their contribution as secret as possible.
The below picture is another pyramid analogy with 10x developer to project.
What can we do as a project?
It is impossible to suddenly hire 10x developers tomorrow, but it is possible to kick off the following strategies to achieve similar results 10x developers bring.
- Recognise among team members that output is as important as prioritization in a software development.
- Set no meeting day once or twice a week.
- Avoid bringing urgent tasks to developers.
- Encourage working early or late for developers so that they can secure more quiet time to focus on development.
- Encourage developers to keep their development tempo. Split tasks into small pieces and set the goal for weekly achievement. E.g., the number of solved issue tickets and pull requests.
- Have morning stand-ups among developers to share their outputs yesterday.
- Visualise the outputs of members. Simple bar graphs or line graphs are good enough to show members' progress.
These team-wide MAX OUTPUT practices will enhance the team's overall progress and software stability in the long run.
Importance-Urgency Matrix for Engineers
Planning the allocation of outputs based on the importance and urgency of tasks matters in real projects. The diagram below illustrates how much percentage of outputs should be allocated to each task type.
As you can imagine, enhancing the outputs of Not Urgent && Important tasks plays a vital role in the future landscape of the project; The more systemic automation brought from these important works, the less urgent tasks team members will face and thus can spend more time on more development and testing of important features. And the positive spiral will continue.
Thank you for reading my article.
Happy Coding!
Top comments (0)