We are talking about equality and how we would like to have more female software engineers. In reality, the need for more female software engineers has nothing to do with equality. If the world had more female software engineers, we would see better software products solving customer problems in better ways, and more software teams would be happier, more productive, and delivered better quality architectures and code. Let’s talk about that for a change!
In the gender equality discussions, you can start from two different angles. The most common and easiest to argue for is that all people should have equal opportunity and that we as individuals, as a company, as a society, as a nation are responsible for making that happen. No individual should be excluded from an opportunity due to race, gender, sexual or love preferences, religion, or any other trait, opinion, belief, or preference. The other angle is to identity how we are biased by the skewed representation of mostly men when we define the desired skills and competencies for the role software engineer. I have always argued that although harder, the latter approach is a much more powerful way to get to equality. Instead of trying to force female software engineers into a possibly false image of what a successful software engineer looks like, we should redefine what a great software engineers is. It will make better male software engineers as well.
So, what is the old image of a great software engineer? In the good old days, writing software was about wrestling with hard algorithmic problems close to hardware and where staying solitary for hours or days without interruption was the key to cracking the nut. The hero programmer would emerge from his cave (always a he) and triumphantly show the solution to a problem with code that nobody else understood. Back in the 80s there was a text describing how “real programmers” would do this or that, like adding a piece of code that discovered a new moon in a space program in just 40 bytes of free space. Everything was incredibly hard and the feat of a single person.
In this world, people who where comfortable with a job with limited interaction with others were favoured. This image still lingers. Software developers are referred to as geeky, shy, and with social inhibitions. Yeah, there are still a lot of coding problems of the old class, but in general, most modern software products, both consumer and business products, are complex systems that require many teams to collaborate on solving problems, be creative, and where deep empathy with the customer and users’ problems is essential to building a great product.
As an industry, we still struggle with too many engineers coming out of school believing that the “real” job is to disappear and code on their own. They will spend too little time understanding the context of the problem, the users, the alternative approaches to solving the problem, and will deep dive too quickly into the coding. Also, in focusing too much on the technical side of the problem, they might miss a much more obvious, maybe even non-technical solution to the problem. Or maybe the solution to the user’s problem is better solved by another team in the company. Even if they are the right team or person to solve the problem, there might be an on-going project elsewhere in the organisation that is relevant to consider when designing the solution. Also, most problems worth solving require a team effort, maybe even several teams. They need to develop a joint understanding of the problem, define a shared understanding of the best approach to solving the problem, and then work together towards testing out their hypotheses and iterate towards a solution that is likely going to be different from their original plan.
In an earlier blog post, I wrote about 5 skill sets that are necessary to become a great senior software engineer. Yes, there is an opportunity for becoming that super-expert who will have complete mastery over a very technical area, but 90% of the the senior roles are more about maturing as a leader and while continuing to increase the technical breadth and depth, the main emphasis is on developing further competencies that have little to do with coding. These can be how to establish trust in a team, make the team work as one, how to engage and further develop a technical proposal through building on other people’s insights, how to establish consensus, or how to engage with and get commitment from non-technical stakeholders in the organisation.
Even in the most technical senior roles, you struggle unless you master interpersonal communications, emotional self-regulation, trust building, listening skills, and a whole swath of other classic leadership skills. So many projects that go awry and so much technical debt that is accrued is a consequence of the lack of non-technical skills among the software engineers. Technical leaders can be the tech lead working closely with the product manager to come up with a technical solution to the customer problem that delights the user and that works for the company (also on a whole lot of non-technical aspects). Technical leaders are the senior technical architects who invest deeply in understanding a technology area and evolves that area for the business to increase differentiation and deliver true customer value worth paying for. Technical leaders are the engineering managers who care about their software engineers as humans, understand interpersonal interactions and how to get to the right decisions and build teams with trust. No matter where you look, the old stereotype of the perfect software engineer does not fit in.
So, look to where women typically excel as a group compared to men: We know that women as a group more often will consider the well-being of the group. They will more often detect and react to signs of discomfort, lack of trust, or the need for support. As a group they are more likely to consider a wider range of factors when making evaluations, while men are quicker to hone in on specific areas and go into execution mode. They are more likely to use empathy with others (including users and non-technical stakeholders) as an input into what they consider as important when making decisions. Women have, as a group, a stronger desire to understand the wider context and meaning of what they are doing and why.
All these competencies are the ones we need to make great software products. So, instead of only talking about equality as something we morally need, we should also talk more about how we can build stronger and more successful software engineering product teams by encouraging women to become and be the female software engineers we need!
At the end here, and before I get angry letters, let me clarify two points: I’m not claiming that men cannot successfully fill the gaps that I describe here. On the contrary, my understanding of what is required is mostly formed by looking at the most successful technical leaders I have known, most of whom are men. I’m just arguing that the skills and competencies we seem to be lacking the most among software engineers are the ones that on the group level can be found more often in women.
Secondly, I am not arguing that you can successfully go to senior technical engineering roles without deep diving technically and thoroughly understanding the technical space. I find that a deep connection to the technical challenges on a hands-on level is crucial to being an efficient technical leader. But once you get to the more senior levels, most seem to struggle more with the non-technical than the technical requirements for being successful as a technical leader.
Call to action: let’s encourage women to a career in tech for all the right reasons. Both in respect of women and for the sake of better software products! I often have open positions in my teams, reach out, we will see the whole you, not just your coding skills.
RSS - Posts