Does Software Development Productivity always mean getting more work done in less time? No.
The other day Paul Adams, who runs product at Intercom, posted the above diagram. Which made me think of a challenge that Jonathan Cutrell's podcast gave to its listeners on his episode about development productivity:
Minimize the output to get to the same place.
"Productivity and effectiveness is not about how much you do, but about what you do." - Jonathan Cutrell DeveloperTea
It is easy as an engineering manager to get focused on the "Outputs" stage e.g. how many tickets we moved to Done this sprint. However the best in class teams evaluate their work by focusing on what business value can we deliver. How do we get to our desired outcome for our customers with by being the most effective and efficient.
What is software engineering effectiveness?
Software engineering effectiveness is to do things right.
What is software engineering efficiency?
Software engineering efficiency is to do the right thing.
What can you do today?
Spend more time in the inputs stage. For instance, go over your Jira backlog for the next sprint. Now look through it from the lens of what's the least the team can do to get to the output desired. Some useful tactics:
- Go back and forth with the product owner to share with them the complexity and alternative of each solution
- Challenge architecture and technical decisions
- Spend more time discussing the design document
- Ask your team to suggest alternatives
- Share the business goals with the entire team
In conclusion, doing the right thing means spending more time on the input stage but it pays off and over time you'll see it impact your team's development velocity.
And remember, in the words of Kelsey Hightower, "no code is the best code", it doesn't break and doesn't need testing.
