What to do about the lack of Women in Technology

This is a guest post by Amy Blankenship, one of the good techy women that our industry is so short of.  She makes some great points here – so her post is well worth a read.  Thanks Amy, for sharing your thoughts…

I’ve been thinking about the issue of why there are so few women in technology, relative to the number of women in the general population.

As I see it, discussions about women in technology often boil down to one of two viewpoints: either the problem is our fault, or it’s the fault of those horrible men.

The first viewpoint at least implies there is something we can directly do to resolve this issue, but it suggests that somehow we are deeply flawed.

The second suggests that the only way that we can fix it is to enlist men to solve it for us.

Neither of these explanations is very palatable to me, so I’ve done more thinking than talking about this. I’ve come to the conclusion that it doesn’t matter whose fault it is (if indeed assigning fault even makes sense in this situation).

Just as it doesn’t matter whose fault it is that the specifications are incomplete, or that a key subsystem is complete spaghetti. What matters is looking at the problem, pulling it apart, researching potential solutions, and doing what you can to implement those solutions.

Guess what? We know how to do this. We do it for a living. But often we confine this type of thinking to strictly coding problems.

Bring your tech skills to bear on other problems

To give you an example, I have worked on three teams in the past few years where the concept of “loose coupling” was actually controversial.

The first two times the answer seemed pretty straightforward—point out that the current code base violated accepted best practice and was an unmaintainable mess, and suggest that we change our practices to use more dependency injection.

The result of this was, at the least, difficult relations with other relations on the team and complete incomprehension on the part of management.

I was beginning to feel that all the time I’d invested in learning good practices was not just wasted, it was working against me. However, I hadn’t seen anybody blogging about this problem, so it couldn’t be all that common, could it?

If all of us who were working so hard to know how to minimize technical debt were consistently walking into places where their knowledge was going to put them at odds with everyone else, surely people would be talking about it.

Then I started with yet a third team where the code had, in my opinion, significant maintainability issues.

This time, there was a key difference, in that I’d been informed up front that no conflict would be tolerated on the team. So I did some more digging, and I found a few places where people did talk (quietly, diplomatically) about this issue.

And my key takeaway was that I needed to make it safe for the other developers.

So when I put together a presentation to give at our next group meeting, I was constantly thinking of ways that I could put things that avoided blaming or insulting the current developers, and above all trying to avoid disrupting our manager’s good opnion of them.

The result, this time, was that I was given the green light to rewrite the codebase.

In part, this is because I made a more careful choice of where to work this time, but I am convinced that the care I put into the political aspect was the biggest difference between the result this time and the previous times.

What I learned from this is that the political aspect is also a skill that can be learned, and that the previous failures I’d had did not mean that I “just couldn’t do it” (or that a bad outcome was inevitable). This is the same lesson I learned for technical skills when at one point I found it hard to visualize what the difference between padding and margin is in CSS.

With research and experimentation, I did learn to use those properties effectively.

Prioritize your self-development

However, the stakes for not developing my political skills have been much higher for me than whether or not I have any particular technical skill.

It can be the difference between getting the difference between getting the resources I need when I need them to meet deadline and failing to meet deadline because the graphics or the subject matter expertise or what have you are late.

It can also be the difference between being asked to renew a contract and not.

This experience has opened my eyes to how many things there are that I could have been applying the skills I have as a developer to, and I think if all of us did this, we could make a huge difference.

I approach programming problems like eating an elephant—by breaking it down into lots of smaller problems and solving those. And I think each of us has access to a different part of the problem where we can lead the way in solving the problem.

My piece of the elephant

One of the interesting things about my current position is that I am building assessments that companies use in assessing people who are applying to work for them, usually in management positions.

This has opened a window for me into what companies are looking for and how people are hired. Just exactly like understanding a new design pattern helps you solve a common problem better, understanding this process can help us be where we want to be.

By the same token, companies who want to encourage diversity can use Industrial and Organizational Psychology (which is what these assessments are based on) to not simply hire diverse people, but to find and/or train managers who manage diverse work forces more effectively to maximize its benefits.

And I think that it makes good sense for women who are in a position to affect these decisions to encourage their companies to do this—not just to help with the low representation of women in technology, but because it’s also really good business.

I recently found some research by a Procter and Gamble psychologist that explores the making of such an assessment. Professionally, I found this paper fascinating, since it goes into depth about how the materials that I see every day are arrived at.

As a person in the workforce, I find the appendix most interesting. It contains the diversity assessment, but it also contains a series of “benchmark” assessments that are commonly used to assess candidates.

I’d like to call out a few of these questions and what I think they tell us about what employers are looking for:

	True	False
1. I find it hard to imitate the behavior of other people. (F)
2. At parties and social gatherings, I do not attempt to do or say things that others will like. (F)
3. I can only argue for ideas which I already believe. (F)
4.I can make impromptu speeches even on topics about which I have almost no information. (T)
5. I guess I put on a show to impress or entertain others. (T)
6. I would probably make a good actor. (T)
7. In a group of people, I am rarely the center of attention. (T)
8. In different situations and with different people, I often act like very different persons. (T)
9. I am not particularly good at making other people like me. (F)
10. I’m not always the person I appear to be. (T)

It doesn’t say in the paper what the (T) and (F) mean after the questions, but I think it’s a good assumption that this is the “correct” answer. In aggregate, these tell us that employers value people who can present themselves as very outgoing and who are very good self-promoters.

In a way, this information is nothing new—we’ve been told for years that we need to learn to promote our work better—but what is new is the idea that promoting yourself, perhaps even to the extent of appearing to be more skilled than you believe you are, is a skill that companies value.

Eat your piece, too

This is just one insight we can get by looking at things with a slightly different eye, the eye that years of analysing problems before sitting down to code have given us. And I have no doubt that other women have access to other pieces of the puzzle that I don’t.

What do you know that could make a difference to the issue of getting more women in tech at all levels?

Eileen is a social business strategist, ZDNet columnist and author of Working The Crowd: Social Media Marketing for Business. Contact her to find out how she can help your business extend its reach.

Credit: National Archives and Records Administration