You might wonder, why the hell do you need an engineering brand? Why should you, as an engineering leader, care about your company’s employer brand?
Before you close this tab, let me explain. The answer is pretty simple.
If you have trouble recruiting or retaining engineers, one way to fix this is building a strong engineering brand.
You need an identity.
You need to know what you stand for, and you need to show it to the world.
You need a compelling value proposition that makes talented developers want to work for you and the existing ones want to stick around for a long time.
You need an engineering brand, but how do you start building one? How will you stand out from the other companies competing for talent?
In this episode of the Level-up Engineering podcast, our host Karolina Toth had a chat with Sarah Wells, Technical Director at the Financial Times. Sarah spent years building the engineering team’s brand at Financial Times, and she shares many nuggets of wisdom so you can replicate her success at your organization as well.
We're covering:
The obvious reason to build up your engineering employer brand is that you want great people to join your company and to stay there. People often start thinking about an engineering brand when they’re thinking about recruiting engineers or setting up an internship program. Developers have opportunities to join many different companies.
You want people to look at your job specification and think, “I’ve heard the Financial Times talking at a conference. They seemed to understand technology, and their engineering culture looked interesting and inclusive.”
This is what you want to get out of building your engineering employer brand. When engineers see an opportunity to join you, they’ll already have a good impression of your organization.
I’ll be using the Financial Times as an example. The company brand is about what we do, which is reporting the news without fear and without favor. Some aspects of the company brand are relevant to every department.
When you’re talking about the engineering department, there are specific aspects to being an engineer. We share culture and brand values with our company, but we have our own view on it.
The core values of the Financial Times are trust, ambition, curiosity, integrity, inclusion and subscriber focus. This applies for engineering as much as it does for any department in the company, but there is more to being a developer. So, you need to build a separate engineering brand that stays in line with your company brand and complements it.
The Financial Times came up with a list of cultural values about a year ago that we wanted to demonstrate. I attended a workshop with people from all over the company to figure out how to demonstrate these values. Some key values were creativity, trust and integrity; I focused on creativity.
I found it interesting that many suggestions coming from other departments were ones engineering had been doing naturally. The 10% days came up as an idea, but in product and technology, we've been doing 10% days for a long time.
This shows there’s a fit in our overall values, but each department ends up being specifically focused on their own area. We write software and operate systems, so that leads to inherent differences.
The first challenge is that you may not know what your brand is. You may have never had conversations about what it means to be in your engineering department. It doesn’t tend to come up until you start thinking about how to represent it.
You might find that not everyone has the same view about what your brand stands for. Figuring it out isn’t easy.
The second challenge is that it takes time and effort. Building your brand isn’t an engineering task, so you need people who will take it seriously and maintain the effort to keep going.
You don’t want to publish a couple of blog posts, and just stop. You need to be out there, continuously communicating in different ways, to have an impact that gets people thinking about you positively.
To have a real impact, you want people to know that they can come back later and read more interesting stuff. Maintaining a pipeline of content, and making sure that people always feel supported to go out and do talks takes a lot of work.
Representing the FT takes time and support.
Your culture is part of your employer brand. If you can’t represent your culture and your brand, it’s going to be hard to come across as authentic. You want to show your culture publicly, and if your organization can’t do that, you’re going to struggle coming up with a brand pitch.
But your brand is more than your culture.
When it comes to your engineering employer brand, you should also consider things like:
Culture makes people want to work for a company or stay working for a company. Your engineering brand is a combination of your culture and the opportunities you give to your engineers.
You want to give people an idea of what it’s like to work for your company. What’s important for you and for your team, and what type of things do they get to do when they join?
You need to communicate what languages and technologies you’re using. If there’s a Node.js developer, they’ll want to know that the Financial Times is using Node.js.
Developers also think, “What are my opportunities to take on new challenges? Will I be able to make decisions about technology, or will I be working my way through a prepared backlog?”
An important goal of your engineering brand is to attract and keep your staff, so you want it to give people a strong feeling of, “I’d love to work there.” This reason will be different for different people and different companies.
You want to attract people you value to your organization.
It’s the same for us.
A key realization we had when we started speaking at conferences and writing blog posts, is that a key audience for us is our own staff. Your blog is an effective way to communicate with your engineers.
The first people reading our blog posts are our own engineers. You don’t want to give them the impression, “It’s not real; this isn’t the company I know.”
Your engineering brand needs to be authentic. Otherwise you’ll have a problem retaining developers. Your brand should represent what you’re like.
The obvious answer is content like blog posts, podcasts, books, or speaking at conferences. These are the key tools, because these are about communication.
We feel like it has a bigger impact to send a speaker to a conference than to be a sponsor. We could choose to spend money on a sponsorship, but getting someone on stage talking about our culture seems to have a bigger impact.
Our behavior at conferences is another tool. We set expectations for people from the Financial Times, like they should be friendly and chat to people with recruitment in mind. They should look out for people who may be a good fit for us.
You could do it strategically, but it was organic at the Financial Times. We used to go to conferences, get inspiration from others, and keep learning, but we constantly felt behind.
After attending many microservices and DevOps conferences, we got to a point where we thought, “We know as much about this topic as the speakers.” This made us consider doing talks, so we ran an internal technical conference. This got our people more comfortable with stage talking, and gave them confidence to apply to speak at conferences.
We wanted to attract great people, so we set up a blog. First, we went to our teammates who were already blogging and asked if we could republish their posts on our blog. These posts started to build our audience.
It wasn’t an overnight success, but our engineers saw it and thought, “This is great; I want to be involved.” The basic idea is to let people know that they can do this, they are going to get support, and it helps build their career.
We often get input from our comms department. When we’re writing a post that touches on business or cultural themes, we make sure they take a look. When we want to talk about production incidents, we talk to the Legal and HR departments to make sure they’re comfortable with us discussing it.
But we haven’t received much input from our marketing department on how to market ourselves. We’ve learned more from other speakers, and once we had a few people regularly speaking at conferences, we formed our own speaker’s guild internally.
We don’t have a list with all the talks our engineers have given, but it’s a good idea to build a resource collection.
Instead, we have a speaker’s guild Slack channel for everyone interested. We’ve collected resources there, like Google Docs with links on how to write a good pitch, and we share conferences that are looking for speakers. When anyone in the Financial Times engineering department expresses interest in speaking, someone will definitely help them out.
If anyone applies to speak at a conference, they can write an abstract or a talk, and we give them feedback. They get to benefit from the combined internal experience, giving them confidence. They get the feedback early, so they know how good it is and where to improve, instead of sending an abstract off to a conference with no idea if it’s okay.
It’s the same with writing blog posts. It takes effort to learn how to make your writing interesting, and the topic has to be engaging with people outside the FT. Blog posts often describe what you did, but not the problem and how your actions solved it. We help our colleagues with how to structure thoughts more effectively.
We consider it a value; and it was positive for my career when I started giving talks. We’re not just doing this because we want to put the Financial Times engineering brand out there, but we think it’s valuable to the people as well. On top of that it helps build our brand, so we support it.
We do internal tech talks, and lightning talks which are opportunities for everyone in the Financial Times engineering to try their hand, and get feedback. Our people are incredibly supportive of anyone giving talks. They get positive and constructive feedback, which builds confidence.
We expect people to participate to a level. Giving talks isn’t everyone’s idea of fun, but as you get higher up in engineering, you’re expected to communicate one way or another. You can give talks or write about your topics.
Communication is an important aspect for us when assessing people for promotions. Several years ago, if you wanted to become a senior engineer at the FT, people asked you, “Have you spoken at our lightning talks yet?” It wasn’t the only way to prove yourself, but it was a good one.
It’s a great way to make yourself visible, and being visible is always good.
We don’t have rules; it’s all up to the individuals. I’m reluctant to push it, because for some people, the idea of standing up in public is terrifying. This shouldn’t stop them from being promoted, or affect them negatively.
All we do is encourage people to take part in conferences, especially our internal tech conferences.
At internal conferences, we try to get people from every tech group to step up and give a talk. We want all disciplines to represent themselves, like product and delivery. We speak in product conferences as well, and engineering has a shared blog with the product team.
So, it’s not an expectation, but we encourage it, and we tell people, “You should give it a try.” People often approach those of us that give talks regularly, asking for feedback, or to recommend them for conferences. Passing them speaker invitations and helping them to get ready is a good way to support new speakers, so the FT gets a wider representation.
We don’t have anything in writing, but we have solid values.
If you ask people in the Financial Times, you get a consistent view. I know this, because our talent acquisition team ran forums a year ago, where they asked our engineers, “What do you think the Financial Times engineering culture stands for?” The answers were consistent across our engineering department.
We stand for openness, lack of hierarchy, empowerment, and the ability to make decisions without having to go through a redundant approval and sign-off process. We value learning, and we support people to go for training or conferences.
The values are clear, but we don’t have an engineering culture deck. It's a great idea to write it down explicitly, but I feel like we have a consistent view, and we express it in our interactions.
A good example of this is when we started working from home because of COVID-19. We made sure people felt supported, so we’ve had a lot of social meetings. This is a manifestation of our engineering culture valuing every one of our teammates.
There’s an interesting aspect of blog posts and speaking: you want people to be themselves. You don’t want to discourage them, but you also need to maintain a consistent quality. This is why I review a lot of blog posts we publish.
We’re happy for people to publish a post about a story when they accidentally committed bad code. They can tell what impact it had, what they’ve learned from it, and how quickly they dealt with it. Or when the Financial Times homepage went down because sharks ate the internet cables.
This makes for a good story. People love that, and we like to talk about them. The moral of our stories are generally how we responded and what we’ve learned from it.
We let our teammates’ personalities come through, while we make sure there is a reason for people to read it. We ask the question, “Why would someone inside the Financial Times or outside be interested to read this?”
Occasionally someone writes a great blog post, but it doesn’t send the right message about us. Then we might restructure it, or change it.
We share recommendations of conferences among us that are good for our brand. We have speakers in a range of areas, like JavaScript, Node.js, and web performance. Everyone has a view of what conference is good for their area; my specialty is DevOps and microservices. I recommend conferences to my team members that were great for me.
We aim to speak at conferences that are held in countries where we recruit engineers. We prefer to speak at places where we have an engineering team, like London, Sofia, and Bulgaria.
We made a special effort to speak at conferences while we were scaling up our developer teams. It helped, because no one knew about the FT engineering department in Sofia at the time. We used talks to raise awareness, and you could see the impact it had on attracting developers.
And it’s not the only aspect. Our team members are sometimes invited to speak at high-profile conferences, which is also worth doing, because it has a massive reach. Speaking at conferences in the US is useful, because it’s shared widely.
Finding the right conferences is up to the people. We generally value conferences that get us in front of people we could potentially recruit.
The main reason it’s consistent is that we work closely together. We’ve got technology departments in three locations: Manilla, Sofia and London. Most of the engineering is in Sofia and London, while Manilla has operations, infrastructure management, and security.
This year was the first full year where we had a team both in Sofia and London, so we hosted our internal tech conference jointly. We had a panel that was split across the two locations. Every tech internal conference we’ve done had a theme; this time it was multiple locations, one team. It helped build the cross-location culture as well.
There are slight differences between the different locations, even between developer teams about what you do, and what’s expected. Most of it is the same for everyone, but there is some variety.
Doing them has helped us a lot. Victoria Morgan-Smith, a colleague of mine, has co-written a book called "Internal Tech Conferences". She helped a lot with setting it up.
Our first conference was five years ago. It started out as a random suggestion, and the CTO said, “It sounds great; we’re doing it!”
It takes some organization, but it goes smoother every year, because we’re getting used to it. People who don’t normally work together, get to know each other and get to show off their work, which is valuable to the organization. It reminds everyone that we’re all doing our best.
Everyone is doing interesting stuff, it’s just in different domains within the FT, but they’re sharing information. It also helps with sharing good ideas across different parts of the organization.
Early on most of the sessions were panels. We choose a topic by asking people what the hot topics are that year. A couple of years ago, it was how much we’re doing DevOps, and what it’s all about.
Panels were a good starting point, because it was easier to persuade people to speak as part of a group, than to speak by themselves. We’ve found that you need people who feel comfortable disagreeing. Also, you shouldn’t put people who are too senior on the panel, because everyone else lets them dominate the conversation; so you have to mix it up.
We’ve gradually done a mix of panels and different length talks, like lightning talks, longer talks, and in-depth stuff. This year, we tried a new method: we asked people to submit their suggestions, while in previous years we only tried to encourage them to participate. It changes every year, and I love it.
We’re guided by technical leadership in terms of what should be the focus, and what they want to demonstrate. We don't spend a huge amount of money on it, but it's a great opportunity.
We encourage everyone in the engineering department to spend time there. It’s a one-day event, and ideally everyone could be there for the whole day. We always do something fun at the end, this year it was a quiz.
There’s a surprising number of companies that don’t have visible employer brands. When you look at job adverts, there are lots of companies you don’t know anything about. Doing anything about it will make you stand out in this environment.
There are big software companies with a big recognition factor. If you get into that position, it becomes easy to stand out. People always want to know more about companies like Netflix, Google or Uber.
The key isn’t standing out, but making sure that the people you want to appeal to get your message. If your brand represents what it’s like to be in engineering at your company, only people who find it attractive will come to you. The value is in helping them make a decision whether your company is the place where they want to work, before they come through the door.
This saves time for everyone, and that’s what you can expect from your employer brand.
You want people to associate your job adverts with the feel you gave them in your communication. If you consistently see great content from a company, you’ll likely put them on your short list. If you get a sense that they have a supportive engineering culture, you’ll consider them when you’re looking for a job.
The idea of your employer brand is for people to be able to understand whether your company is the right place for them.
People attending tech conferences in London have probably seen our team members speaking, so they have the sense that the Financial Times engineering is out there and what it’s like. But many potential employees aren’t part of this group.
They see a job advert from the FT, and they look up our engineering department. They’ll find the blog, they’ll find that we speak at conferences, start reading, and think, “This looks good.”
There are companies that you try to look up, and there’s nothing to tell you what it’d be like to work there. Or what you find may be unappealing, like a lack of diversity. You can look at the FT’s online presence, and see a mix of people, see the openness, and find the technologies we use.
Standing out is great, but the key is to represent yourself, so people can discover and understand your engineering department.
I feel like the quality of our applications has improved. We’ve always had a team where people stayed for a long time. I’ve been here for nine years, and it’s always been a company where I wanted to stay, because I’ve had interesting opportunities.
Many applicants tell us stories that they’d heard about us at conferences or meet-ups, learned about our engineering culture, and that made us attractive.
We see more people applying to work at the Financial Times engineering, and we often hear that our content led them to us. We receive many employee referrals in the FT, which is always a good sign.
We also host meet-ups at our office. Our people don’t always speak at the events, but others get to see where we work, and get an idea if they’d like it. We moved to a new office last year, and our meet-ups instantly improved, because now we have a great workplace.
The first thing is that you always have a brand. If you don’t work on it, you give up control over what people think of you. It’s worth considering what you want them to think, and invest at least some time to start working on it.
The second thing is realizing how much the work on your engineering brand is targeting your existing employees. The first people to read your blog posts are the ones working for you.
Writing a blog post is often the most effective way to persuade your employees about a new approach. You’re arguing for something, present evidence, and it influences people internally as well.
You want people to be proud of working for you, and employee referrals are a great way of recruiting engineers. So, if your engineering brand works internally, you’re on the right track.
We let our people know when we publish blog posts. We post it on Slack, and list them in the roundups that technical leadership sends out regularly. Our people show support for any team member who’s publishing at least with a like or a share, because it’s part of our culture.
We actually use our blog posts internally as well. For example, we have a post describing what happens when traffic hits our website, and it’s a great resource for new engineers on that team. It’s written in a way that people outside the FT engineering can understand it, so we use it for on-boarding.
Sarah Wells has been a Technical Director at the Financial Times for two years. She’s run teams doing first-line operations, reliability engineering, building tooling, and Origami, the Financial Times’ design system team. Her mission is to build great software for the FT.
She used to work as a Java and Go developer. Five years ago, she started building a new microservice based system at the Financial Times. That got her into operation and support.
At Apex Lab, we're experts in end-to-end digital product development. Our remote-first company operates with a flexible schedule, allowing us to help clients tackle difficult challenges worldwide.
Want us to build your next idea or upgrade your existing product? Our experts cannot wait to work with you. Get in touch with us and let's make this happen. 💡🚀