Why 10x developers really matter in software development project

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 for many non-tech clients.

There, I saw several 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.

I was lucky to observe 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, whose value and practices are still worthy of attentions in most projects nowadays.

I compared two projects carefully and gave thoughts on what characteristic had significant impact on the 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.

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 members' 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 stakeholders, and hence teams increased the number of meetings, to once or twice every day.

Prioritization has pros but also cons!

Pros:

These teams are good at finding a problem from users' perspectives, identifying why the problem occurred, and quickly fixing it with a few lines of code in an urgent manner. Thus this type of development style is suitable for patching already released and maintenance products.

Cons:

The problem with this approach appears when a lot of new features are to be developed, more foundational work is needed with a lot of efforts. But both prioritized task executions and solid foundational work are hard to achieve simultaneously for the following reasons.

Prioritized tasks vs development order

Tasks sorted by prioritization are often less efficient for productive developments because prioritized tasks focus more on something that are visible to users/stake holders while it would be easier for developers to start with the foundational part.

I prepared an intuitive illustration of pyramid construction below.

On the other hand, constructing pyramid from the foundation can make more progress with the same effort, but would be less satisfactory to users.

Context Switching

Frequent prioritizations must come with the context switching of tasks for engineers, as many experts already suggested it like in this article. Engineers outputs will decline sharply if their priority tasks are changing even a few times a month.

Development Mindset

Priority-first people tend to ignore hard work and end up only doing minor fixes on the surface to solve the urgent problem. But the system internals become 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?

On the other hand, the other type of development has the opposite characteristics; there is no strict deadline for each task, but the entire roadmap is rather heavy and long because a lot of new features are to be integrated to 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 the development rhythm, 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 really matter 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 by themselves.

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.

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 get the development rhythm. 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 below diagram illustrates how much percentage of outputs should be allocated to the 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!