Are Developers part of Discovery?
TLDR: Yes… wait, no. I mean, sure! ahh!!!!!
Tough question. My opinion has been evolving over the many years I have worked as a software developer and later as an engineering manager. I will walk you through some of the versions of my opinion throughout the years.
First Draft version (2000–2005)
One of my first versions of my opinion is that a dev is a dev. Devs should focus on coding and building things. They are passionated about this (at least a reasonable amount of them :P), they have been trained on this, this is their main responsibility. People who are not passionated about coding for whatever reason, should focus on understanding WHAT needs to be built and communicate that to developers to the extent that is needed for them to be able to build something. Even between developers, the goal was to divide and conquer in a way where each developer would have their “module”, “component” or whatever we called and only that developer and God knew what was happening in the code for that particular part of the system. It felt like the right thing to do!
Second Version (2005–2015)
I have met many software developers in my career, and the ones who were most valuable to the product/project were always the ones that understood WHAT is being built, and challenged (in a positive way) and contributed to the WHAT. The positive impact on the product was simply amazing and you could start to see the two worlds blurring the lines to the extent where people felt comfortable contributing to things that were not necessarily their main responsibility. The most exciting experience I had in dev team happened during this time (and shaped how I look at software development). This was driven by the rise of Agile. Multi-disciplinary teams, XP practices, shared ownership, pair programming. All of a sudden, everyone was potentially knowlegeable and involved in things beyond their primary area of responsibility. Of course we still had people that only wanted to code, and that needed to be respected, but people got pushed anyway to do things they didn’t necessarily wanted to be part of. But if you did a good job of setting up a balanced team, you would harvest the benefits. It felt good. It felt like the right thing to do!
Third Version (2015–2020)
No matter which project or company, I always tried to push the teams I worked on to function like the second version I just described. This resulted in many success cases, but also other cases where it didn’t go so well. The more we start talking about things speed, burn-down charts, optimizing the team, say-do ratio, productivity, etc…. the more developers start to be asked the question “how to deliver more?”. The answer is normally very simple. Let’s help our developers to be 100% focused. Maybe you will relate to some of the sentences I will list here: “Do the devs really need to attend this meeting?”, “The scrum master will look into this obstacle, just pick another card”, “Should we do like this or like that? I don’t know, we need to ask the Product Owner”, “How many story points have you completed this sprint?”, “Velocity needs to continue to increase”, etc.
There is nothing wrong with the desire and the goal of increasing productivity overall, but sometimes it has led me to my third opinion version that devs should focus on dev. Felt like the return to version 1, but driven by productivity boosts. It felt like the right thing to do.
Fourth Version (2020–2022)
My fourth version of my own opinion on this matter starts really on the individual level. From the people perspective, nothing really changed in the last 22 years. There are still developers that only want to code, and others interested in the WHAT a little more. I believe it is part of the engineering manager’s job to create the kind of environment where this all of those needs can be accommodated in a good manner. If someone, as a software developer, is interested in contributing beyond coding and spend sometime doing discovery and learning about the PROBLEM, this should be possible. If someone, as a software developer, is interested in only focusing on the SOLUTION, this should be also possible. And even the same person should have the ability to navigate between those two examples the whole time (That is actually quite healthy and helpful).
CONCLUSION
When I took a deeper look at the evolution of my own perspective, I realized there is no right or wrong answer to the question I posed on the title. Humans tend to set rules (Version 1, 2, 3) but at the same time, there is no rule that will work for ALL different types of people. Human-optimized environments, should offer possibilities and flexibility. Go, try, test, change, adapt, react, and start again from scratch.
