Welcome to a new
On Aug 4th, we spent an hour with Sam asking her everything about bridging the gap between marketing and engineering 💪🏽
First, remember that developers are people. As a group, developers do tend to be more reason or logic-driven, that's what makes them good at dev, but ultimately, learning to separate the code from the developer is key.
When working with a jr developer, understand that they're probably getting everything from a fire hose. They'll usually want a bit more handholding on any tech solves. If you're working with a Sr developer though, I encourage you to approach them with the problem you're seeing and what end result you would like to see. And be open to collaborating. They may be able to solve something even better without causing huge impacts or dev backlog.
Lastly, really master the language and reasoning behind user stories. A user story is generally structured like As a ____, I want to ____ to ____. So for example, As a search engine crawler, I want to find and parse structured data from schema.org to better understand the content of the page, as well as populate search results with rich features. You don't always have to follow this format, but if you start approaching your dev team with those types of data points (who is it for, why do they want it, what do they want to do), then generally conversations are much more productive. And most developers HATE pointless meetings and convos (don't we all) - so this is a great way to get on their good side.
If you have a way to talk with Tech, then I would highly recommend it. If not, and understanding that I have no clue what it is you're trying to get them to build, then really listing out all the steps or loopholes/bandaids you have to go through to do this work at this time may help. Also still framing from that approach of what's the end goal you're going after. I've also found that usually leaving caveats of being open to other solutions or collaboration tends to soften the conversations. So the old "please help me understand how to do this better".
Oh goodness, the number of times I've run into this. I tend to ask a lot of questions about a solution and try to present hunger to learn and understand. Once I see that the other team has shifted to being more educational, then that's usually when they're also ready for a bit more collaboration or hearing my own experience to have input on the solution. Let them feel like experts to lure them into a comfortable space - and then prove you're the smartest in the room
This one is definitely a classic. So what I end up doing is documenting all the changes we want to make, and offer that if they want to keep the access locked, it's no problem at all, we'll just need them to implement these changes. Then when they inevitably don't get implemented by that dev team, the client usually calls an audible and demands we get access relatively quickly. OR, the dev team sees how much time those things take and then give up that fight. I also may sometimes ask why they're nervous about us going into the CMS? And straight up ask them how can we build trust.
So, I'm pretty lucky that most of our clients have internal dev teams and because of my own experience, I'm pretty integrated into them. In past relationships though, I've seen where not setting expectations of needing engineering help at times has really hampered success. Because of this, we include in our onboarding that we'll need a point of contact for those things to get those intros and conversations started earlier. Ultimately though, if the client isn't able to get buy-in from their engineering team, all we can do is make it clear that there's a ceiling to what we'll be able to reach. And at that point have to trust the client to fight that fight. We'll supply them with the data and info that we can, of course, but business priorities dictate resources.
To be honest, I'm still working on that myself. I'm starting to schedule dedicated time to take classes or work on passion projects. It helps immensely that my husband is a back-end developer so we'll actually work on projects together. Other things I've done for work/life balance: I take off every Friday afternoon to spend time with my hubs without the kiddo. And I have started treating dinnertime as sacred time. There are some times where I'll be texting my partner, but I generally do not do any real work during that time. And the Women in Tech SEO community helps me stay informed and learn about new things to try for SEO. I also subscribe to some newsletters for the front-end of things - JAMstack, Netlify, etc. That way I can stay up-to-date on trending web technologies.
Consider running a presentation on SEO to the team. Since you're on the engineering side, I'd recommend going into the super nerdy part of search, like how the algorithm works, machine learning and its impact, etc. I've done presentations like that to engineering teams a few times and while they don't all get excited, usually about a third to half do and hey, that's a win in my book!
Look for the win-win" - aka, get ppl excited about SEO by translating what it means to their performance in their role if SEO works well. Plus, make it as easy as possible for them (specifically what little things they can do to make their results better thanks to SEO traffic).
Always the engineering team lead. That's who is responsible. For me, I like to lay out as much info as I have, and be completely transparent on the pieces where I'm uncertain. That way, the lead knows where they need to step in and make a call, and also, where they don't.
Unless you were hired as a developer, you're not "passing the buck". You're taking what you're responsible for and relying on your team and their skill set to carry it through. That's the reason we have multi-person teams. Also, your secret weapon when you feel uncertain will always be this group. And just from what I've seen, 9 times out of 10, we're doubting ourselves because we've been conditioned to do that. Trust yourself. SEO is an art, not a science. So that means sometimes we'll find a way of NOT doing something, and there's value in that too.