In this post I’ll present the Effort-Complexity Matrix and how it can be used to understand technical units of work.
The Effort-Complexity Matrix is a tool we can use to chart a given task somewhere on the matrix and get a gut-sense of what it takes to accomplish the given task. It combines two key factors: complexity and effort.
Defining complexity and effort
Complexity - how difficult the task is to understand and explain
Effort - the time required to complete the task
For example, the task of landing astronauts on the moon is complicated because it requires expertise in a deep subject (rocket science). It is hard because it requires a lot of time to build the rockets and spaceship that the astronauts will use.
Meanwhile, the task of doing laundry is simple because it has limited technical details and is low effort because it can be done in about 10 - 15 minutes (wash cycles aside).
Relativity and Specialization
In reality a software engineering org has a team of specialized software engineers with a variety of experience (e.g. junior, mid-level, senior). As an engineer rises in seniority, they gain the ability to grapple with more complex tasks more easily.
For example, a tech lead should be able to design a data model for an application while a task such as this might be more complicated for a junior engineer.
Or, a hardware engineer with 15+ years of experience would probably might view some embedded system programming as more simple than a backend web engineer.
Hence, complexity and effort are relative. This is fine as the framework serves as a gauge to break down larger projects for a team and isn’t about applying absolute labels to engineering tasks.
Applying the framework
Given a large software project, we likely have a team of specialized engineers with a range of experience. For a simple example, let’s say we have a team of 4 engineers with the following skill levels:
- one tech lead (Engineer 1)
- one staff (Engineer 2)
- one senior (Engineer 3)
- one mid-level (Engineer 4)
The tech lead looks at the given project and applies the Effort-Complexity Matrix. They come up with the following breakdown of high-level tasks or features:
- Task A: complex / hard
- Task B: simple / hard
- Task C: moderate / easy
- Task D: complex / medium
- Task E: simple / easy
It would make the most sense to put the most senior engineer on the most complicated task AND the most difficult in terms of effort (Task A). They should be able to use their skills and experience to “simplify” the task and perhaps break it down into smaller pieces that can be distributed to the team or managed more predictively. It’ll ensure that we get the best bang for our buck in terms of engineering effort.
A second obvious example is Task E which is simple and requires easy effort. This is a good task for a more junior engineer to get their feat wet. Additionally, something that’s simple and large effort makes sense for a more junior engineer to tackle. They might need mentorship and guidance to stay the course but it’s better saving expert engineering cycles on more complicated problems. Hopefully, the junior team member is exposed to increasingly more complicated challenges through their own work, the code review process, and pair programming.
Now that we’ve applied the Complexity-Effort Matrix to our project, here’s how we might break-down some of the work:
- Task A: complex / hard => Engineer 2
- Task B: simple / hard => Engineer 4
- Task C: moderate / easy => Engineer 3
- Task D: complex / medium => Engineer 1
- Task E: simple / easy => Engineer 4
Note that while a tech lead might have more experience, it’s often better to assign the most complex / highest effort task to an IC who has full-time capacity to focus on the problem (often leads do not).
Additionally, the most complicated and hard problems are likely the riskiest and should either be started earliest or and least spiked to better understand them. They likely have the most unknowns, can drag on and take longer than expected, and otherwise add stress to the project as they linger in the back-log.
Conclusion
That’s it! Thanks for reading. How do you think about technical problems? Do you and your team use a framework at work? Do you consider complexity and effort required? Zap me a note or tweet at me and let me know. Goodbye for now 😀