Many moons ago I worked in a briefly-successful UK "dot com" integrator, and then took a break from work for personal reasons.
When I came back, I rejoined in the design department, rather than return to a role in engineering, where I had been mostly front-end. (I described myself whimsically as a "pet engineer".)
What we realised then is that the design team needed an engineer on their side of the divide to act as a go-between with implementation, but also to translate requirements in both directions, explaining what each side thinks (as well as urging some respect for the designers' craft).
Nowadays this is reasonably commonplace but at that time it was pretty radical.
Technical teams often make the mistake of thinking that their knowledge, their language, and their problems are supersets of or at least the essence of the problems of the business. They are quite wrong.
Many moons ago I worked in a briefly-successful UK "dot com" integrator, and then took a break from work for personal reasons.
When I came back, I rejoined in the design department, rather than return to a role in engineering, where I had been mostly front-end. (I described myself whimsically as a "pet engineer".)
What we realised then is that the design team needed an engineer on their side of the divide to act as a go-between with implementation, but also to translate requirements in both directions, explaining what each side thinks (as well as urging some respect for the designers' craft).
Nowadays this is reasonably commonplace but at that time it was pretty radical.
Technical teams often make the mistake of thinking that their knowledge, their language, and their problems are supersets of or at least the essence of the problems of the business. They are quite wrong.