Thanks for asking, Elena! I love to see earnest attempts at improving communication within organizations ❤️
We are writing an article "marketers vs. developers"
My first suggestion is that you avoid encouraging an "us vs. them" mentality, even in casual writing. It's true that developers respond well to certain presentation of information, but so does everyone 😄
Now, on to your larger set of questions. From the way you phrase certain things, it sounds like in your situation, the marketing team is responsible for communicating asks to the engineering team. Is that correct?
I've never been in that sort of situation: in the companies I have worked for, the requests pass through a product or project manager and are discussed and prioritized together with an engineering lead. But even still, I feel I can give decent feedback here.
In addition to a written document, I have always benefited from having a direct conversation about that document with the person(s) providing it. It gives everyone the opportunity to easily clarify any details and ask any questions that come to mind, and gives engineers the chance to adjust unrealistic expectations and correct any wrong assumptions in the document at the very beginning.
These conversations don't have to be long or formal: sometimes a 10 or 15-minute chat is all you need. The important thing is that the conversation happens at all, and that the engineers have been provided the brief at least two or three days in advance: depending on their workload, they may not be able to read through it right away.
Additionally, there should be no timeline or deadline given unless it has been agreed to by an engineering lead. This is very important; even time-sensitive/urgent requests need to be vetted by an engineer before committing to it. The only people qualified to provide a valid estimate for the work you want done are the people who will do it, so if an engineer says something will take 4 weeks, and you say, "Okay but the client needs this by X date," then you need to work with the client to either reduce the scope of the request or find a way to give the team the time they need to satisfy it. Remember, we're on the same team: we're not deliberately inflating our estimates to make your life harder! Attempting to force a timeline on an engineer only hurts your relationship with them and the quality of the work they can do for you.
What are the main and the most important things in the brief for the developer?
Reasons. Why do you care about this work? Why should we?
Urgency. Is this a "drop everything and do this now" request, or do we have the luxury of prioritizing it in context with our other work?
Goals. What are we improving? What are we striving towards? Will meeting these goals provide short-term value, or are they steps towards some longer-term success, or are they both?
Impact. How will achieving these goals impact the business? And, perhaps more importantly, for each goal, what is the impact of missing it?
Stakeholders. Besides you, who else cares about this?
Once we have this information, I think most engineering teams can give you a quick and accurate estimate of how much work this actually is and our best guess at how long it will take to do everything. We can then work with you on fitting it into our product roadmap, reducing the scope of your ask and providing some alternatives if our estimates don't align with your needs.
What is often forgotten to be included in the brief (something needed for further work)?
In my experience, all of the things I listed above except "Goals." I often have to follow up to get that information.
What is not as important but appears in brief?
Mockups of the imagined result. A project brief is not a product design. Diagrams are great if they help illustrate your goals, but most of the time drawing mockups before discussing the request with your engineering team is likely to be wasted effort: projects are rarely so straightforward as to be able to accurately imagine the final result from the outset, and mockups in the brief can mislead engineers about what you actually care about.
Mockups are best deferred until later, once the work has been committed to and as one of the first steps in the project design.
How can marketers help developers with his/her work? What information to provide, how to set a task?
Be available for frequent discussion and demos.
Be overly explicit in your communication: try to leave as little as possible open for interpretation.
Be willing to repeat your answers to our questions.
Be timely with communicating any changes to your request, and be ready to re-evaluate the timeline with every change, no matter how small it might seem: sometimes things are easier said than done, and sometimes they're easier done than said! (Those are the best times 😄)
A great technique I've found is to create an online chat room / Slack channel dedicated to your request once it has been committed to, and prefer to have all discussions there. If any face-to-face conversations are had, summarize them in the channel immediately afterwards to preserve important outcomes and make sure you're all on the same page. This space becomes the "living source of truth" about the project, and is a fantastic resource during retrospectives.
How do marketers interfere developers while thinking that they are being useful?
Flooding our calendars with project-related meetings. Regular check-ins and demos can be useful, but they're not always necessary and often don't need to happen face to face or even in real time.
Remember that everyone uses a lot more jargon and terminology than they are aware of. When you're communicating with us, try to be conscious of your word choice and of the fact that terms may be shared between us but might mean very different things to each of us.
Oh, and please try to avoid using our jargon and terminology unless you're quite certain you're using it correctly (ask us if you're not sure! 😄): if we hear you use a technical term we might think you understand more than you actually do about something, which can lead to big communication issues!
Thanks for asking, Elena! I love to see earnest attempts at improving communication within organizations ❤️
My first suggestion is that you avoid encouraging an "us vs. them" mentality, even in casual writing. It's true that developers respond well to certain presentation of information, but so does everyone 😄
Now, on to your larger set of questions. From the way you phrase certain things, it sounds like in your situation, the marketing team is responsible for communicating asks to the engineering team. Is that correct?
I've never been in that sort of situation: in the companies I have worked for, the requests pass through a product or project manager and are discussed and prioritized together with an engineering lead. But even still, I feel I can give decent feedback here.
In addition to a written document, I have always benefited from having a direct conversation about that document with the person(s) providing it. It gives everyone the opportunity to easily clarify any details and ask any questions that come to mind, and gives engineers the chance to adjust unrealistic expectations and correct any wrong assumptions in the document at the very beginning.
These conversations don't have to be long or formal: sometimes a 10 or 15-minute chat is all you need. The important thing is that the conversation happens at all, and that the engineers have been provided the brief at least two or three days in advance: depending on their workload, they may not be able to read through it right away.
Additionally, there should be no timeline or deadline given unless it has been agreed to by an engineering lead. This is very important; even time-sensitive/urgent requests need to be vetted by an engineer before committing to it. The only people qualified to provide a valid estimate for the work you want done are the people who will do it, so if an engineer says something will take 4 weeks, and you say, "Okay but the client needs this by X date," then you need to work with the client to either reduce the scope of the request or find a way to give the team the time they need to satisfy it. Remember, we're on the same team: we're not deliberately inflating our estimates to make your life harder! Attempting to force a timeline on an engineer only hurts your relationship with them and the quality of the work they can do for you.
What are the main and the most important things in the brief for the developer?
Once we have this information, I think most engineering teams can give you a quick and accurate estimate of how much work this actually is and our best guess at how long it will take to do everything. We can then work with you on fitting it into our product roadmap, reducing the scope of your ask and providing some alternatives if our estimates don't align with your needs.
What is often forgotten to be included in the brief (something needed for further work)?
In my experience, all of the things I listed above except "Goals." I often have to follow up to get that information.
What is not as important but appears in brief?
Mockups of the imagined result. A project brief is not a product design. Diagrams are great if they help illustrate your goals, but most of the time drawing mockups before discussing the request with your engineering team is likely to be wasted effort: projects are rarely so straightforward as to be able to accurately imagine the final result from the outset, and mockups in the brief can mislead engineers about what you actually care about.
Mockups are best deferred until later, once the work has been committed to and as one of the first steps in the project design.
How can marketers help developers with his/her work? What information to provide, how to set a task?
A great technique I've found is to create an online chat room / Slack channel dedicated to your request once it has been committed to, and prefer to have all discussions there. If any face-to-face conversations are had, summarize them in the channel immediately afterwards to preserve important outcomes and make sure you're all on the same page. This space becomes the "living source of truth" about the project, and is a fantastic resource during retrospectives.
How do marketers interfere developers while thinking that they are being useful?
Flooding our calendars with project-related meetings. Regular check-ins and demos can be useful, but they're not always necessary and often don't need to happen face to face or even in real time.
Remember that everyone uses a lot more jargon and terminology than they are aware of. When you're communicating with us, try to be conscious of your word choice and of the fact that terms may be shared between us but might mean very different things to each of us.
Oh, and please try to avoid using our jargon and terminology unless you're quite certain you're using it correctly (ask us if you're not sure! 😄): if we hear you use a technical term we might think you understand more than you actually do about something, which can lead to big communication issues!
Thank you, Daniel ;) You've helped much!