This article is about The Dev group in relation to other business units in the company. In this article, “the Dev group” is shorthand for whatever business unit the software development team is in (Technology, IT, …).
Many times in a company, the Dev group is seen not as a consumer of requirements and a provider of solutions, but as somehow subservient to other groups, like Marketing. The Dev group has to be very careful not to challenge their statements in meetings, and just accept that they know what they’re doing, no matter how little it’s based on actual customer feedback, or how SWAG the finance estimates are, or how much of their input is colored by personal bias. I’ve been taken off of meeting invites because I dared to challenge the statements about the Dev group and defending them from other business units. We even say things like “Let’s find out what The Business thinks of these features” as a short hand for “the other business units”. But phrasing it that way implies that the Dev group isn’t a separate but equal business unit.
This is a very unhealthy way to see it. For starters, it’s unhealthy for ANY group to not be able to challenge any other group in the company, when done in a constructive way. You can’t have improvements if you can’t talk about problems.
It also turns the Dev group’s mission from “We provide solutions that make the company’s goals possible” to “We translate everyone else’s brilliant ideas into code”. If you’ve ever heard a bad cover band, you know that execution is just as important as the original ideas, Neither does any good without the other. Even that view of it excludes the Dev group as the creator of ideas, which is rarely the case.
It’s essential that the Dev group be on the same footing and seen as a partner to the other business units in order to create the best possible business solutions. And the words we choose broadcast how we see that relationship just as much as our actions.