Like at other publishers like Yahoo, Sport1 etc. I worked before, the situation at Condé Nast Germany was quite similar. There was a lack of sharing information and communication between the tech-team and other departments like the editorial-team, marketing, sales etc.
Different ways of trying, different ways of failing!
Well, to deal with this issue, there were several approaches I experienced in the companies, I worked for before. Some tried to establish a weekly update meeting with a representative of the tech-team and one the editorial-team. Others used to establish fixed „consultation hours“, where the tech-team is available for any stakeholder questions during a fixed time-frame. Furthermore, there was the approach to set up a „claim form“ that stakeholders had to fill out, if they want the tech-team to do anything. At the end, none of these methods really worked to improve the cooperation between the tech-team and the stakeholders.
There was another thing that popped up, when I started at Condé Nast. The team had a scrum process in place that worked quite well, but was lacking of one significant criteria: the review and improvement of the developed feature. As we are a quite small team with only a few developers and have to deal with a bunch of requirements that are coming from a lot of stakeholders, the situation established that the stakeholders write a story in Jira, these stories are discussed and prioritized in a planning meeting and then implemented in the upcoming sprint. After two weeks, the same process starts again, with the only difference that the stories from the stakeholders are completely new ones.
Well, so far so not good, as this means that in fact, we are not living an agile process, but are used to implement a two-week waterfall model.
Why changing only processes is not the solution
But what has this to do with the cooperation and communication between developers and stakeholders? A lot! Because the origin of the problems is the same. It’s the missing involvement of the developers concerning the KPIs and the goals of a developed feature. Much too often, developers are considered as “printing presses” to explain it in a print context. Much too often, the editorial-team develops an idea that should increase reach or the sales-team develops an idea that should increase revenue. Anyway, they usually just pass their ideas to the developers, who implement this without knowing the context and the targets behind this requirement. They deliver the feature, get an official approval by the stakeholder and that’s it for them. They start developing the next feature that is in the backlog.
To change this, a stronger involvement of the developer is crucial. He has to understand the business value behind the feature, has to take responsibility for the success together with the stakeholder and thus develops a stronger accountability for the whole product. The implementation and deployment of a new feature or website may not be the end of the process for the developer. This is the point the team should start to gather data and incrementally start to optimize the feature from a editorial, sales AND technical perspective. So, just updating the developer with the current roadmap and the current issues on a website or CMS is not enough. There must be a way to deeply involve the developers in the success of a product and not only inform them about the plans. A goal for a developer is not achieved, when the feature goas live without any bugs - it’s achieved, when a feature performs as it was supposed to do and meets the business needs. This part is usually only considered by the stakeholders and not the developers. But this must be changed!
A change of mindset is needed
So, in the first step to get there, it’s not a change of processes, it’s a change of the mindset of the stakeholders and of the developers. This is the hard part! The process part is quite easy, when all parties agree. Actually, sometimes there is not even a change of processes needed as stakeholders start to involve developers in a natural way. The start to directly ask the developer for his or her thoughts about an idea and the developer starts to provide proactive ideas, tech-trends that could help improving the product and give valuable feedback for new and existing features. This feedback wouldn’t be possible, if the developer doesn’t know about the context and the goal of a feature and thus feels no accountability for the success of a product.
OK, that’s it for now… The next time, I will explain to you how we actually tried to achieve this change of mindset and and how we adapted our processes.
Did you experience a similar situation in your company and if yes, how did you deal with it? We are happy, if you share this with us and drop a comment below!
