How do gender and ethnic background affect pay in tech?

This short-form, data-led article uses cord data on the ethnicity, gender and salary expectations of engineers to identify the pay gaps that exist between different gender and ethnic groups in the tech industry.

The original can be read here. More articles in the same series can be seen here.

Contextual data

White females have the lowest average salaries of all groups of engineers, at £62,019. The average female from a minority ethnic background earns £67,925, and white male engineers earn, on average, £72,573. Minority male engineers are the highest earning group, with an average salary of £77,576 – 25.08% greater than that of the average white female.

Below, the data is explored by function, job title (among developers), seniority and years’ experience, in order to compare the difference between the salaries of engineers of comparable ability and experience from different gender and ethnic backgrounds.

Unless clarified by context, “engineer” is used to refer to any professional who has created a profile for job-seeking purposes on cord. Engineers are carefully selected to be able to create profiles on cord. They require professional experience in Tech and Product-related roles, and are therefore specifically represent people working in these roles rather than, as many other statistics sometimes cover, the “Technology industry” as a whole. It is therefore felt that the data discussed here gives a unique insight into gendered and ethnic pay differentials among people working in Tech and Product-specific roles.

Salaries by function

Graph showing average salaries of white females, minority females, white males and minority males by function

Minority males are the highest earners in each function, while white females are the lowest earners in every function. Minority females earn more than white males in Development, but white males earn more than minority females in Infrastructure, Data and Product & Design.

The disparity between highest and lowest earners is greatest in Development, where males from ethnic minority backgrounds earn 29.99% more, on average, than white females.

Developer salaries by job title

Graph showing average salaries of white female, white male, minority female and minority male developers by job title

Males from ethnic minority backgrounds earn more than other groups in every job title within Development, and again, white females earn the least.

The disparity is greatest in back end, where males from ethnic minority backgrounds earn 28.57% more, on average, than white females.

Salaries by experience

Graph showing average expected salary of white females, minority females, white males and minority males by number of years' experience

Males from minority backgrounds earn more, on average, than other groups at every level of experience.

Men from ethnic minority backgrounds with 2 years’ experience earn more, on average, than white women with 5 years’ experience.

Key Insights

  • Across all tech and product functions, seniority and experience levels, men from minority backgrounds are the highest earners, while white women are the lowest earners
  • Men from ethnic minority backgrounds earn, on average, 25% more than white women
  • The average white female needs 6 years’ experience to out-earn the average man from a minority background with 2 years’ experience

Data Disclaimer

Data refers to 54,082 engineers across all locations (primarily London, Europe/Remote, and New York) on cord.

Gender is determined by one of two methods. All engineers are given the opportunity to self-ID. Roughly one quarter of engineers do so. The remainder have been assigned a gender (male or female) by a third-party predictive API ( based on their name. The API makes mistakes, but is accurate in 90-95% of cases. The same API is used to predict the ethnic background of all engineers.

All salary data is based on engineers’ expected salaries on cord, which is used as a proxy for actual salary.


This is a short-form piece aimed at letting Back End developers know which skills are most in-demand, according to data derived from cord’s product.

There are others like it viewable here. The original post for this article is here.

Demand for specific Back End development skills is difficult to quantify without hard data.

cord have analysed the average number of messages received by Back End developers with specific skills, allowing Back End developers to make more informed decisions based on relative demand for their skills.

Graph showing average number of message requests received per engineer with different Back End development skills on cord

The data show that TypeScript is the most in-demand skill for Back End Developers. Developers who listed TypeScript as a primary skill received, on average, 16.37 message requests each.

The next most in-demand skills are Go, Node.js, Microservices, React and AWS.

Of the top ten most in-demand skills, the least in-demand was APIs – which averaged 10.19 message requests per Engineer listing API building as a skill.


“Primary skills” refer to the skills that engineers identify as part of their primary skillset when they create their profiles on cord. They can select multiple skills.

“Message requests” are messages sent by companies to engineers, regardless of whether or not the engineer accepts that request.

Leader bio – Dan Mcneil

This long-form piece is based on an hour-long interview with Dan McNeil, a Head of Engineering I’ve known since I was an agency recruiter. Dan’s thoughtfulness on topics like inclusivity and neurodiversity have always made him a distinctive engineering manager to follow and learn from, so interviewing him and distilling his philosophy was a fascinating experience.

The article can be read below, or in its original location here.

If I were a sculptor

One paradoxical aspect of technical leadership is that, in general, it involves a switch from solving technical problems to solving people problems. Being proficient at the former doesn’t necessarily imply any level of aptitude for the latter. A talented programmer of code doesn’t necessarily equate to an inspiring leader of engineers.

Dan McNeil – most recently Head of Engineering at iTech Media – embodies one potential solution to this paradox. From an early age, his focus has always been on solving problems. While coding has been one useful tool he’s acquired along the way to help him in this front, it hasn’t ever been the end goal in its own right. His focus from the outset has been on outcomes, and the particular tool used to reach these has been incidental.

“If I were a sculptor,” he says, “ – that’s a line from a song, isn’t it? – if I were a sculptor, I’d be much more interested in the sculpture than the chisel.”

As someone who has, in his time, managed dozens of direct reports and engineering divisions numbering 70 to 80, Dan finds himself sculpting people – their work and their career trajectories – far more than code or product these days.

Ironically, he has assembled a suite of tools with which to do so, centring on authenticity, transparency, and inclusivity. These differentiate him from the crowd of engineering managers, and indeed directly challenge many of the industry’s unspoken assumptions.

And then it was maths

Dan’s journey into technology reflects his focus on the end result.

“Maths was always my first love,” he says. This love led to a string of home computers, starting with the ZX81 and continuing with a Spectrum 128 and a Commodore Amiga, to appear in his early life. Back then, his mother would diligently enter the software code, which was then required to be entered by hand from magazines, into the machine, at which point young Dan would become obsessive about understanding how it worked.

“Nowadays, I would talk about things such as flow of control, but back then, it was just: ‘how does this sit together?’”

Despite this, it never occurred to Dan to study computer science.

“When it came to picking my A levels, it was maths, further maths, further maths special paper, Cambridge entry papers in maths… and then it was maths!”

The toolkit

Despite his preference for the end result, it’s worth examining the toolkit Dan uses, as a manager, to create these flourishing careers – or, more accurately, to create the kind of environments in which they can flourish.

This toolkit is rooted in one of his first positions after university. Dan spent a combined ten years at Symbian and, following the company’s acquisition by Nokia, the Symbian Foundation. For most of this period, Dan was a Customer Engineering Consultant: the face of Symbian, embedded within the engineering teams of the phone manufacturers implementing Symbian’s software.

Here, Dan was introduced to the other type of challenge that grabs his attention most: those concerning people. The demands of acting as the face of one organisation within another taught him the fundamental tenets that now comprise his managerial philosophy: transparency, authenticity, and inclusivity.

Everything that can be shared

Management, like consulting, often involves acting as an information gatekeeper between two parties. Dan’s take on transparency takes account of that.

“I believe that everything that can be shared, should be shared.

“If somebody came to me and said, ‘What’s my colleague’s salary?’ I can’t tell them, but I can tell them why I can’t tell them. And that’s what I mean by transparency. It doesn’t mean that I blurt everything out to everybody, but it means that I either tell people things or I explain why I can’t share that information with them.”

At Symbian, Dan was privy to information that couldn’t be shared with its customers, and conversely gained insights through working with its customers that couldn’t go back to Symbian.

“If the manufacturer said to me, ‘We’d like to do this,’ I might just say to them, ‘I wouldn’t recommend doing that, but I can’t tell you the details of why, because it’s confidential.’ Obviously, if they don’t trust me, that’s useless. When they trust that I’ve got their best interests at heart, they’re going to say, ‘Okay, we trust you.’”

The right way of doing things

As such, authenticity is a key pillar of Dan’s approach. His take on transparency falls apart if it isn’t met with trust, which in turn relies on authenticity on his part.

“If you are authentic, honest and kind, you can still have tough conversations. You can still have conversations about performance. You can still do all the tough bits of management, but you do it within a space where people feel safe. So people feel comfortable to have a conversation with you where you say, ‘Look, I don’t think this is working out,’ during their probation, or to have a performance conversation with somebody whose performance has dipped.

“If you come from a place of kindness and curiosity, you will actually get to the bottom of what’s going on for that person. I don’t believe anybody wants to come to work and do a bad job. So you understand what’s happening and you can genuinely support them.”

He tells an anecdote from a previous company, which posed an exercise to its managers. A youth sports team, with a squad of 20, has progressed to the next stage of a competition. Only 15 squad members can be taken through to this stage. The managers – all of whom, besides the HR Manager, were men – were asked how they would decide who to progress.

Besides the HR Manager, Dan was the only person whose solution suggested including the squad members themselves in the decision-making process. Everyone else suggested some form of quantifying each squad member’s performance, then informing them of the decision once the ideal 15 had been identified.

“I came away from that initially thinking, ‘Great, I’ve got something different to offer.’ But actually, my voice got smothered. The others tried to coach me into thinking more like them, because that would make me ‘a better manager,’ rather than this lone voice who was saying ‘Maybe there’s another way of doing this.’

“I think that taught me to be more true to my belief in the right way of doing things.”

Being himself at work was a long journey for Dan to begin with, and in many respects it is still ongoing.

“I’ve been openly gay now at work since back in my Symbian days, but every time you start a new job, there is the question, as a leader coming into the organisation, of ‘Is this a safe space for me to come out or not?’ And it’s very easy in 2022 to say, ‘Well, all tech companies are.’ Well, actually, they’re not.”

Over time, Dan has learned that authenticity is less to do with conforming to those around him, and more to do with being himself.

“If I conform to think the same way and do the same things as the people around me, that’s the opposite of diversity. You want people to come in and think differently.”

Everyone tries to fix introverts

Dan’s own journey and learnings, especially to do with authenticity, have fed directly into the third pillar of his managerial philosophy: inclusivity.

As above, Dan feels that progress is still required on the industry’s inclusiveness as far as the LGBTQ+ community is concerned. Women, also, are under-represented. Dan cites figures suggesting that female representation in tech is actually falling from 10-15 years ago.

Corporate cultures that centre around stereotypically male activities may, in part, fuel this problem by creating non-inclusive environments for women.

“Let’s hire more women. Let’s aim for a gender balance. But it’s not just about finding and hiring women who fit the existing culture, but about changing the culture to make it more attractive to women.”

It is, however, in neurodiversity that Dan thinks the industry has the most ground to make up.

“Generally, it’s seen as not acceptable if corporate culture is exclusive of a group of people because of their gender, or their gender identity, or their sexuality or their religion or their race. Where we haven’t yet got is where we interrogate company cultures to say, ‘Is this inclusive of people who are not extroverts? Is it inclusive of people who are on the autism spectrum? Of people who are not comfortable speaking up in loud groups? Is it inclusive of people who suffer with anxiety?’”

There is a counter-intuitive aspect to this. The extrovert-heavy tech company culture is seemingly at odds with the “non-social” IT geek stereotype. When pushed on how this discrepancy can exist, Dan says:

“Entrepreneurs tend to be extroverts. And I know people will say, ‘Oh, there’s quiet entrepreneurs who aren’t social,’ but it’s different to being social. Somebody who has founded a company has had the self-confidence and the self-assurance to put themselves out there and talk about the company.”

In other words, company cultures have a tendency to reflect their founders’ personalities. This has consequences for the people who work there, and how genuinely diverse and inclusive they can be.

“Everybody tries to fix introverts. ‘Oh, you should come out of your shell more. You should relax more. You should learn how to enjoy yourself.’ Nobody tells the extroverts to calm down and meet in the middle!

“If there was somebody in the office who never talked to anybody, a manager who wasn’t that aware of neurodiversity might say, ‘I don’t feel like you’re communicating very much. Is there anything we can do to help you speak up more?’ But if somebody’s walking around the office, high-fiving everybody and whooping, is any manager actually going to have a word with them and say, ‘Look, your behaviour is actually making some people uncomfortable’? Probably not.”

Over the years, Dan has cultivated the art of honesty when giving his reasons for not attending company events.

“For years I said, ‘I can’t go to the Christmas party because my second cousin’s dog is having a wash,’ and that kind of thing. But in the end, I just said, ‘I’m not comfortable in that environment.’”

Taking this bold approach has prompted two forms of response in Dan’s colleagues. Some attempt to cajole him, imploring him to give the big, loud social events a try.

“The number of people who say, ‘Just try it, I’ll go with you. Why don’t you come and talk to me?’ But if you organised a mountain climbing expedition and you had somebody in the office who had a bad leg, you wouldn’t say, ‘Why don’t you just try harder on it?’ You’d say ‘No, you can’t do that.’

Others, however, have confided in him privately that they envy his honesty in giving his authentic reason for not attending such events. While Dan doesn’t consider himself a self-assured person, those around him seem to perceive him as such.

“I still don’t think my self-assurance is real. The ‘self-assured’ me is a learned behaviour that I have gained by watching other people who appear self-assured and thinking, ‘What can I do to appear like them?’

“Sometimes it misfires. Sometimes I come off as cocky. Sometimes I come off as arrogant because I overshoot it and it’s not because I am those things, it’s because I have seen other people acting that way.”

Enjoying the challenge

Speaking to Dan reveals a complex, nuanced picture of what a person’s best work might look like. He eschews the traditional quantitative metrics by which we tend to evaluate managers – “How big is your team? How many direct reports?” – and focuses his energy on the qualitative aspects of his leadership remit.

“The complexity of the people stuff increases as you get more people. The coaching you need to give to managers increases because as you get up to 70 or 80 people, I can’t get directly involved. If it’s a team of 20 or 30 people, if I need to or if it’s useful, I can get involved in the more complicated HR cases or I can lean in closer to technical decisions. And I could do that to a certain extent in a team of 70, 80, but not really because there’s just so much, so actually it involves a different style of management.

“I think that’s a useful, healthy style anyway: to empower the managers within the teams to be able to run their teams in a way that works, and have checks and balances to make sure that everything’s okay and that I’ve got evidence everything’s okay and I can spot when things aren’t, but without me being in the detail of what’s going on in the teams every day.“

Carving a group of sculptors who can shape themselves and their teams autonomously, in other words, is more productive than trying to chisel every detail into place himself.

Ultimately, for Dan, the defining question over whether he is doing his best work is: “Do I enjoy the challenge? Or do I find the challenge frustrating?”

This typifies his own approach to the two fundamental facets of technical leadership: technology, and people. For a man who found coding in many ways frustrating, but who was drawn into it as a means to the end of solving interesting problems, the cost-satisfaction scale was perhaps inevitably going to end up tipping towards the more human problems.

It is tempting to be surprised that a natural introvert should be drawn in this direction, but as Dan has learned along the way, it is often what makes us different that conveys our true strength. His transparent, authentic and inclusive style has been directly informed by his own experience, and enables him to act as an example to others who lack his learned self-assurance over how to pursue their own best work.