It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
I don't think you have to know how to code to manage people who code. In fact it's arguably an asset -- it removes the temptation to jump in and fix things yourself. You do need to understand the process and establish mutual trust with your team so they can help you get your head around the technical issues they encounter and in turn organize things to help them avoid those problems in the future. But you don't need to have written code to know what a merge conflict is or how technical debt impacts team velocity.
The single best product manager/scrum master/whatever you want to call it I've ever worked with didn't write a lick of code. He understood his job was to facilitate the development process and relied on us to help him understand what worked, what didn't, and how to keep things moving forward.
It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
I don't think you have to know how to code to manage people who code. In fact it's arguably an asset -- it removes the temptation to jump in and fix things yourself. You do need to understand the process and establish mutual trust with your team so they can help you get your head around the technical issues they encounter and in turn organize things to help them avoid those problems in the future. But you don't need to have written code to know what a merge conflict is or how technical debt impacts team velocity.
The single best product manager/scrum master/whatever you want to call it I've ever worked with didn't write a lick of code. He understood his job was to facilitate the development process and relied on us to help him understand what worked, what didn't, and how to keep things moving forward.
I don't think you have to know how to code to manage people who code.
Interesting. I'm not sure the role of the scrum master as originally envisaged involved managing the people.
Maybe this is something else that has changed over the years.
Maybe using "direct" instead of "manage" would have been clearer. I'm not talking about where people are on the corporate totem pole.