Finding the opportunities to increase your impact as a developer — the conclusion
The first part of this story ended with some questions: Is there a difference between the potential impact in different phases of product progression? Does the potential impact of a single developer increase or decrease during product evolution? How does the seniority level factor in?
As with many interesting cases, the solution that came to me one day was to add a new dimension to the graph! After contemplating about the details for long time, here is the resulting graph, including separation between seniority levels:
The graph portrays the potential impact for developers in three seniority levels: junior (in green), senior (in light blue) and architect (in red) in the three phases of product evolution — explore, expand and extract.
Before providing reasoning for the graph details, it should be noted that the Success-Payoff graph contains a hidden trait, where usually both the complexity of the product (the underlying system and code) and the size of the team grow as the project progresses.
As a result, in the “explore” part of the graph the team working on the product is small, therefore the project progress is directly linked to the impact a single developer has on it. Since writing new code base from scratch requires experience, the ability of junior developers to make impact at the very beginning is negligent, while for seniors the starting point is high. In both cases, the impact grows in correlation with the project progress, where at the end of the phase the change in impact levels, as the exploration options are exhausted. From my experience, in such early stages the complexity usually does not require an architect role.
In the “expand” phase the challenges require larger team with wider areas of expertise, causing reduction in the impact of each single developer. The depiction of this observation on the graph is gradual descent in the impact of junior and senior developers, starting after a small “steady state” in impact at the beginning of the phase. The beginning of this phase marks the stage where the complexity requires someone with broader view and knowledge. Enter the architect. In accordance to the rise in complexity, the impact of architect is expected to rise as the project progresses.
When a project progresses into and within the “extract” phase, the tasks become more focused and the changes in architecture scarce. As a result every developer involved is expected to have smaller and smaller impact — juniors, seniors and architects.
So what does this mean for you as a developer?
Although the impact is expected to decrease in the “expand” and “extract” phases, achieving deeper understanding of the system and integrating new technologies can make a developer’s impact remain steady as the project progresses. It can even offer a chance to increase the impact, and an option to improve the developer’s seniority levels. The following graph depicts in black arrows the areas in the graph where such advances (from junior to senior and from senior to architect) are most likely to happen.
The two arrows that from my experience offer the best path to advance in seniority levels are the two most left ones, in the transition from “explore” to “expand” phase. In this phase prior knowledge of the system is crucial, and the opportunity to make large and impactful changes is the greatest. But, before you drop all you’re doing to find this type of project, it should be noted that as described above, this stage in the product progression has the biggest risk for failure, therefore the risk and reward chances should both be taken into consideration.
That’s all folks, hope you found this interesting. I will be happy to get comments and suggestions for improvement. Next time — similar breakdown of potential impact for management roles!
