Episode 1 – Polly Pospelova – open <dialog>

On 4th October 2019 • 38 min read

Welcome to the very first episode of open <dialog>, the podcast for collaborative SEOs and digital marketers. In each and every episode, we’ll be speaking with the best and brightest minds in SEO, digital marketing and beyond to find out how we can work more effectively, efficiently and productively with other teams, departments and clients.

In our first episode, DeepCrawl’s Sam Marsden spoke with Polly Pospelova, who is the Head of Search at Delete Agency.

Episode 1 - Polly Pospelova - open by open dialog

Welcome to the very first episode of open dialog, the podcast for collaborative SEOs and digital marketers. In each and every episode, we'll be speaking with the best and brightest minds in SEO, digital marketing and beyond to find out how we can work more effectively, efficiently and productively with other teams, departments and clients.

Over the course of the episode, Polly shared her experiences about:

A visual summary of this episode has been sketched out by the supremely talented Katja Budnikov for your viewing pleasure. The full sized image can be found here.

Polly Pospelova open dialog Sketch Notes

If you enjoy this podcast, you can make sure you’re the first to hear about new episodes by signing up to our mailing list, and don’t forget to share using the hashtag #open_dialog.

 

Join our mailing list

 

For those of you who prefer to read along, here’s a written recap of the episode.
 

How did you get into SEO and digital marketing?

My story, like so many other SEOs’ stories, was a happy coincidence. Back in 2003, I was doing my master's degree, and as part of that degree, I chose the dissertation title of ‘multi-threaded intelligent search engine spider software written in Java’. So it was a piece of software that I built without realising there was any purpose for it. It was just fun. You feed it a URL and it goes off downloading HTML files, parsing HTML, storing information discovered about certain types of content, held within certain tags in the database and returned based on simple search queries.

All I got out of it, was that I thought I could program a little bit better now. There was no industry as such. The SEO industry didn't really exist, not as clearly defined as it does today. But that was my first experience. So I got quite deep into what content means, how to weigh certain content that is enclosed in certain tags, how to figure out what the page is about, certain parsing difficulties of scripts or tags with styles and attributes inside them. So I guess I've gone deep into analyzing the page code and doing something with it.

Then I graduated and worked as a software developer for a little bit. Then SEO started to emerge. I noticed it really emerge in 2005, and at the time I was a technical project manager, and one of our clients came to us and brought a very long SEO recommendations report done by some SEO agency, saying “can you implement this on my website?” I looked at it and I thought half of these things probably don't matter and would be wasting your budget, but these and these and these things are quite interesting.

That was my first very successful SEO trial project, and everything else has led me to go deeper and deeper into the sector. I've almost created a department without there being a department in the agency. I was lucky enough that our co-founders just pretty much let me do what I wanted to do as long as it was commercially viable. And here we are today, a very technical SEO-focused digital transformation agency.
 

So you started off by building your own web crawler?

Yeah, that's correct. It was a university project, it was non-commercial, but it could do all of the basic things on a low intelligence level.
 

How do you think coming from a development perspective has shaped your experience of SEO?

I think having a technical background really helped me do things well throughout my career. The deep understanding of markup, speed, performance, the way requests are handled between the browser and the server: all of these things help you grasp things a little bit quicker. But then that's just one piece of the much bigger puzzle, as SEO is so broad. In fact, I think everything we do has got some kind of SEO connotation. Having a technical understanding definitely helps with technical SEO.
 

Who are you working with on a daily basis as the Head of Search at Delete

Delete is a full-service digital transformation agency. We do large, meaty builds for big multilingual, multinational brands. So I end up working with just about everybody. On a daily basis, I work with the solutions team. So this is the team who defines what we're building, how and what is in scope and what is not in scope.

I also work with our delivery teams who manage budget estimations and make sure that everything is covered in our budget.

I work very closely with our UX and Design team too. In fact, we've gone through almost a process of evolving our UX and Design team to a point where they now consider search probably just as much as I do. They've evolved from thinking that UX is the most important thing, to now realizing that everything they do has an SEO consequence.

And naturally, our development team is absolutely my baby. I love them. I'm no longer a developer myself, so I feed on other developers’ talents. We’ve almost formed a group of people who specialize in SEO or performance-specific approaches from the front-end to the back-end. So we have UI with HTML, CSS and JavaScript developers who can do things that I would never be able to do. Of course, you also need the platform specialist programmers who can deliver the rest of the logic to the full-scale enterprise level.
 

How have you gotten other developers to care about SEO related issues?

This is something I feel quite passionately about. Of course, we don't check if developers are interested in SEO in particular. I mean, there are 50 or 60 of them. But what I know for sure now, having gone through years of doing innovative technical type stuff and pushing the boundaries, is that with developers, generally 9 out of 10 would not consider SEO if they have joined the team to build websites. They're focused on the front-end and the latest techniques that front-end developers care about. The back-end developers normally care about their programming and the best working practices.

Usually, it's my job to get them interested and that is a challenge. The way I do it is that if I give developers a brief and say, “Well, can you do X, Y and Z?” with a long list of technical SEO requirements, they might do it right, but it will be half-hearted, or maybe require a little bit more Q&A. However, it’s more impactful if I take a step back and I actually explain to them, share a screen with them, with what it is that I'm trying to achieve. I'm trying to sell the dream to them as if they are my client. If I explain to them what I'm trying to achieve, like the latest microformats, by showing them whatever I'm trying to trigger and showing them what it means to get there, then they are a lot more interested and they work a lot faster.
 

Tell us about the hackathon you held to improve site speed and get a perfect score in Lighthouse

So the latest experiment which I covered at BrightonSEO was exactly that. I sat down with a group of developers and I said, “Well, how difficult do you think it would be to achieve [a perfect score in Lighthouse]?”. We'd done some optimizations and the website was nowhere really. Well, wasn't nowhere, it was still a reasonably fast website, but it was scoring only about 56 out of 100 in Lighthouse. I said, “shall we try to brainstorm and see how far we can push it?”

I showed the developers the different talks and blogs that talk about site speed, and got them interested basically. Then we decided to arrange a couple of hackathons where you actually have more minds join in, and we refined it into a longer program of works and ran it as a series of RND updates on our own websites. It would be difficult to do this on a client website, I think, but taking it [performance optimisation briefs] to the client and saying, “Well, can you give me X budget, and I’ll just try to optimize it?” doesn't work like that. It's not commercial. You need to show them what site speed means to them in pound signs or conversions or extra leads that you could achieve for them. So I needed a methodology to form a case study or a business case, so I had no option, but do it to our own website.

Did you get all of Delete’s developers involved in the Hackathon? What did that look like?

It looked like people coming into work on Saturday! Well, you arrange it as a social gathering. It usually involves pizzas or some other food. Beers help! Obviously trying to find a weekend where it wouldn't affect people’s families and their lives usually helps. So quite a few people turned up. It was a good group.

I'm very, very lucky. Our development team has been with us for a while. There is very low staff turnover in the development team and they were very advanced. Then we've got some brilliant SEOs in-house, they got involved. Yeah, we just took it from there.

We didn't do everything in that one day. We were analyzing recommendations. Trying to figure out what changes would make the most difference, what to start with, what to leave for later. Obviously starting from something that would make the most difference is logical. So we blasted through our images, and then we realized that actually, now we have to cut up into small pieces just about every single piece of code. What I've discovered, is that it is a completely different approach to build something for speed and for performance than just building something. We literally ended up rewiring the whole thing from scratch.

Were any optimisations made to improve the Lighthouse score more than the actual performance of the site? e.g. Next-gen image formats

You know what? The last few percent are the hardest. I think we got stuck at 98%, and then 99%. I would say, just updating image formats doesn’t really make a huge difference. It's a combination of things together that deliver a real impact. For example, not loading images which are not within the viewport at all and lazy-loading images as you scroll down the page. Also, if a browser recognizes and understands WebP we obviously serve it, but then we have a downgrade option, served if browsers don't support WebP. So it's a huge series of image manipulations that we ended up rolling out.

But I tell you, the best thing from that was that we actually ended up building near reusable components or practices that we now deploy on quite a lot of our projects, which is where I've managed to sell the project to the agency as if I'm cost-neutral. This also helped the way the wider development team now build projects, of course, this has changed.

Not every single project coming out of our doors would be scoring 100%. It's very, very hard to do and it's very time-consuming. You can't just add a month's work on top of a client’s budget.
 

What are the key things that you'd recommend that SEOs or marketers can communicate to development teams to improve performance?

Images are extremely important. I guess a ‘load only what you need’ approach is also very important. As in, when you develop your styles or scripts, develop them in small files grouped by logical components on your website. So, for instance, have a set of styles or resources, I guess, for forms, buttons, for general colours, for pagination, and then lazy-load them only when you need them. Don't load the styles and scripts that that page actually is not even using.

I’d call it a hack and this is where you take all of the resources needed for that first paint and inline them into your head tag. That's really brilliant, as it delivers you a near-instant page load on first load. That is important for any websites, whether it's a landing page for your PPC campaign or even the landing page for an email marketing campaign. If you can have something load instantly without it even being AMP, why not? So that is a really cool hack.

The clients that we end up dealing with, they just come with the requirements saying “Well, I want my website to be super fast. I want it to load in less than two seconds on our core pages.” So that's my brief and then we sit down with the team and say, “Well, we've got 300 hours for this. What do we do within those 300 hours to come as close as they want, ideally and more?”.

The thing is, the criteria is changing so fast, that often we would begin building a site, but if it takes six months to build and if it's a large implementation, things change and by the time it actually goes live and it’s gone through all of the approvals, quite often it could be below what we initially set out to achieve.

So I guess what is important for an SEO is to form an understanding between them and their clients and that this is a living and breathing tool if you are using Lighthouse. But also, every other website out there changes. Therefore, the sector average constantly moves. So if it's a project that's running way too long, it probably will be out of date by the time it's launched.

Google has released Lighthouse in order to help website owners see what's wrong with their pages and see how to fix them. They are enforcing it is a standard, which is great for the users because SEOs have to satisfy their users not only by returning the relevant results, but also to ensure that whatever is returned as a result loads fast and provides an excellent experience. To begin with, it probably starts slowly, but I'm noticing now performance on sites that are released by competitors, agencies or other SEOs are much, much more advanced than even six months ago.
 

How do you get other people in the agency to take an interest in SEO-related issues?

The way we do it is by knowledge sharing. Quite often, maybe twice a week, maybe sometimes once a week, we run knowledge sharing sessions or show and tell sessions within the agency. Different teams take over those sessions at different times, but what we try to do is make sure there’s an agency-wide understanding of what we do, how we do it and why. I find it very, very important. We're all in it to deliver a final product and every single piece of the puzzle needs to be excellent to make sure it all plugs in together and comes out at the highest quality.

I'm even now introducing developers into accounts practically from the pitch stage. So getting them to see what the client is asking for and how they're asking for it now. Briefs are now coming through the door specifically talking about performance. I've never seen that before. I’ve worked in this agency since 2005 and maybe in the last 12 months I have noticed large briefs, say a few hundred thousand type projects, which specifically talk about performance, so it clearly is gaining momentum.

I'm showing this to developers when working on our responses of what we're telling our clients, how we're going to do it so that they get what they're asking for. So they are involved from the very start. I am absolutely doing that now, and we're very lucky. We have quite a few leaders in the development team, there’s a lot of trainers, and people who invest their time into making the rest of their teams better and more up to speed. So I'm not on my own here. It’s a good culture. But it's a culture that one needs to nurture and proactively encourage.
 

What do your agency-wide knowledge sharing sessions look like?

We operate from our offices. So if we're running a session here, everybody from this office would gather around. We have a large nice island. The kitchen area over there is very large, so we would gather together. We've got a massive up screen kind of this size next to it, so we would project and everyone who is physically present would contribute and listen. But then all of the rest of the offices would be able to dial in. There are plenty of tools and conferencing facilities out there we use. We try to get everybody involved even if they are over WiFi.
 

Do you have any disaster stories when projects have gone horribly wrong?

I guess we wouldn't be here had we not made some mistakes and miscalculations. It's normal we’re human, we do get things wrong. It's how you go about admitting and fixing things that are wrong, that's what's important.

Maybe not a disaster story, but a very recent one. It's a current project launching in September. We have been working on a digital transformation for a national property client and we’ve worked on topic modelled content for the core pages. So they have property developments around the country. So there'll be some core data, but there is some additional data and content that we are plugging in for the new website to make sure gets the best ranking opportunities. We were estimating the content part of the project, this is where I've made a mistake and not involved enough people.

There were two parts to it. Some content needed to be completely new, so it had to be written from scratch. But some core content had to be migrated. I made a few assumptions with the team of how we can migrate it from asking for a backup of the database from the old solution. We thought that we’ll get that database, write a script and migrate all of the right content into the right cells in the new database and then we're done so we don't need to be porting across for months.

This is where we really miscalculated how difficult it would actually be. So the data was in a format that could not be ported across, it was not in the format we needed. We ended up doing an awful lot of extra parsing and our scripts ended up being much, much more complicated. What I've learned is that I probably should have investigated the state of the assets and content a little bit further and not been so quick with some assumptions.

It all ended well. We ended up re-estimating and replanning and adding a few more people into the team. But it was interesting how I thought I pretty much knew what I was doing, and it ended up being a much bigger piece of work.

The good thing is we were doing the best thing for our client. We were looking for a way to not kill our client with monkey see, monkey do work. Nobody wants to be importing thousands and thousands of pieces of content across manually. It's soul-destroying. So I tried to maintain the excitement in the project within their in-house team and solve problems. We did end up solving them, it was just how much bigger solutions that were needed.
 

How do you explain what happened when things go wrong?

I find honesty works the best. Nobody can reproach you or disrespect you for being honest and doing your absolute best. So we always tell everything to our clients and not when it's too late, we almost tell them about the problem when it starts so that they are on board with it and they almost feel like they are part of the solution. So if you get them involved, they feel for you so much more. They are eager, assuming you have a good relationship with them so that always works better for me.

Do you tell clients only what they need to know while still being transparent?

Yeah, it depends. I guess how much you tell the client depends on how much they want to hear. People of certain roles in certain levels don't want to hear about code or databases. They just want to know what it's going to cost and the summary of the problem if there is one. Or if you're working with someone inhouse and eager to learn and it's almost like a knowledge-sharing relationship. They want to know everything, but equally, you feel excited to share. If somebody wants to work with you, co-work with you this is the culture that we try to encourage all of our clients. You almost become an extension to their team. We become them. They become us. You share whatever they want to know, but adjust it to the level of role.
 

What knowledge sharing happens between yourself and your clients?

Lots! That's another thing I'm starting to see in briefs. The last three briefs we have responded to specifically ask for added value and that added value will be that you engage the inhouse team, sharing things outside of their sector.

Quite a few companies are actually really keen on that. So a university doesn't want to know what you've done for another university they want to know what you've done for a football client or a sports club. So they want to know something from outside of their sector as well as something that is directly relevant to them, so as to help them form a better understanding of what's going on in the industry and where it's all going.

We have weekly or biweekly calls with smaller teams, maybe group marketing teams or regional marketing teams where we really go into a lot of detail on a weekly basis. So something comes out. I don't know. Something comes out something new. You tell them there and then. As we learn, we try to push it to our clients because the more they know about what's coming out, I guess the more exciting things we can build fast and share with our community. Like this performance piece of work. We did it quite early and now we've practically ended up deploying it on just about every project we’re working on.
 

What key advice and tips would you give to SEOs and digital marketers looking to communicate more effectively with other stakeholders, like developers

Well, first I think that SEOs should actually talk to developers and vice versa. Working in an agency, it is very easy to get lost in messaging, documents, sharing chats and not actually voice. I always find I get so much more out of people if I actually talk to them. They’re human, they will detect the vibe from your voice, tone of voice and they will feel more engaged somehow.

So first of all, SEOs please talk to your developers whether it's on a microphone like I'm talking to you right now or telephone. In-person of course is ideal but, in the modern world, everybody's so mobile now it is sometimes difficult. So talk to them.

Then, of course, keep pushing. Don't leave it until next week. Just keep talking even if it's a five-minute chat about some feature that you're not quite happy about. Just do it now so it feels like a regular thing. You almost set a pace, an example of how that relationship is going to develop. Do show them why you're trying to do it and what you ultimately are trying to achieve and what it means for the clients even commercially. Share how it's being tracked. Share what goals you're trying to increase, what traffic you're trying to maximize. They are interested. They really want to know.

Involving them is the most important thing you can do. For example, I have a new business opportunity where normally I would go with a member of our sales team or solutions team. But actually, this time I'm saying, you know what? I'm actually going to take our SEO Engineer with me because it's a heavily technical potential project. They will get excited. There will be much more accurate output there and then from them. The client will see the commitment and the talent within the team. I think it's a win-win, so I'm adapting.
 

Would you say the project to get a perfect Lighthouse score has helped in convincing clients?

I think absolutely. It's a live example and I've also kept the old website on a subdomain, old.deleteagency.com, as a point of comparison. Quite a lot of people asked actually what was it before? So I've left it all there for anyone to see and experiment, to see the difference in code, see the difference in styles, how things load so they could actually get inspired. If somebody knows a little bit more or has a deeper technical understanding it will be so much more valuable for them, but also to clients. I run on a lighthouse test on the old site and straight away on the new, and I'm saying, “See, it looks exactly the same, but it in terms of performance, it's worlds apart!”.
 

Is there a product or service you’d like to promote that makes your working life easier

I really like an agile software development tool. It's a suite called Atlassian and the particular product that I'm talking about is called JIRA. JIRA is a way to develop projects, but I use it for all of our SEO accounts. It's a brilliant task tracker you can collaborate with. I don’t have any shares in JIRA, I just I find it works really well if you are an agency and you work with a client with an inhouse team or multiple teams inhouse. You can onboard them all with their roles and their own usernames in that software, you can all collaborate in one kind of Wiki-style ticketing system. That really helps and makes my life a lot easier.

The reason I like JIRA is that I used to be a developer. Minimum interface, maximum functionality. It's not fancy looking at all, but it does the job in the way I'm used to. But absolutely, there are so many tools out there. In fact, Google Suite is amazing. Collaborating on documents and sheets is fantastic. It’s really powerful what you can do with scripts in Google Sheets is phenomenal as an SEO. There are loads of tools you can imitate and functions you can recreate.
 

Be the first to hear about new episodes

A massive thank you to Polly for being our very first guest on open <dialog> and teaching us so much from her SEO experiences working agency side. You can find more episodes of open <dialog> here on the DeepCrawl Blog and make sure to be the first to find out about new episodes by joining our mailing list.

Join our mailing list

 

Tags

Get the knowledge and inspiration you need to build a profitable business - straight to your inbox.

Subscribe today