Women are cut out for the highest tech salaries

I spent yesterday with 500 people where many were programmers. Granted, many were beginning programmers, but they were programmers none the less.

You become a programmer when you start programming. You become a professional programmer when someone is ready to pay for your programming. It's that simple. Even "full time professional programmers" do other things than write code for most of their days.

Every day is a change of learning more.

“The time you use on doubting yourself is time away from studying and learning more” #MimmitKoodaa

— Maaret Pyhäjärvi (@maaretp) August 30, 2019

And yet, here I am *again* using time away from studying and learning more, like pretty much all my life. And the reason for it is my gender.

The event yesterday was #MimmitKoodaa, a Finnish initiative to bring women from other industries to programming. The 500 people were women. They were there because Finnish companies have started taking action in providing targeted free hands-on trainings specifically to teach programming to this demographic. Smarts are not divided based on gender and with software being the thing that defines our future, we won't be leaving our future for men only but want the best minds from all genders (including the ones not in the binary) to work on this stuff. Also, tech pays. And it pays well. Women are cut out for being paid well and work to learn to be worth all that money.

I'm writing this because I made the mistake of browsing through the #MimmitKoodaa hashtag on social media. I read comments of someone I know telling how women are just not cut out for programming and proof of that is that women in the industry are more often testers than programmers.

Having to use energy to walk away or address that shit is the reason why women still avoid programming.

When all your pull requests are specially analyzed for lack of aptitude, rather than assuming you're learning.

When all your programming assignments in school are met with "who did you smile to so that they wrote the code for you" by your peers (teachers knew better).

When you can't have a 1:1 meeting with your colleague without others making fun of you having something going on because one of you is woman and the other isn't.

When you speak in a meeting about architecture choices and the facilitator takes you to side after telling that "you're intimidating, you need to let the others do the talking" even though you really did not speak any differently than others.

When organizing meetings and other glue work is implicitly assigned to you, because everyone knows you care enough to do and they can get away with it by waiting.

When suggesting mob programming, your colleague tells you that you could motivate them by showing your breasts.

These are just few examples from what I go through. My list is a lot longer, but keeping lists drains energy from doing other stuff. Many women have lists like this. Many women choose not to share their lists to save their energy, leaving foolish people thinking there was no problem in the first place. But it allows them focus. That is why they are further in programming. And we have lots of examples of superb women programmers.

Fuck off telling women are not cut out to take big salaries. We are. We have always been. But we shouldn't have to take the extra shit for getting what you're earning now. For this amount of shit, you should pay us more. And women need the extra help in getting started because we've used our time on fighting that you guys got to use on playing to learn. That is why #mimmitkoodaa is a great thing.

Asking for a private discussion

Two years ago, I had trouble with a colleague. I was a tester, they were a developer, and I was unhappy with how seemingly carelessly they would push in changes, and leave no room for others to catch up and test any of that stuff.

Like often happens, I did not tell them. I tried making them change the way, arguing over the time, but I never went to the person and told them in their face how their actions made me feel.

Instead, I told my manager.

We work in this office with team rooms, so whatever I would say to anyone would always be a thing I would say to 10 people. Unless I asked them to step out into a private room.

My manager listened, and told me to talk to the person. Two weeks later, he asked if I had taken care of my problem. I said the problem was gone. But I never talked to the person. It felt too difficult.

In an open space, even the "can we talk - in private" is something everyone hears. I see people applying tons of ways around saying those words out loud - sending a message, putting a small meeting in calendar. And yet, when two people get up the same time, people notice.

It is hard when it is not in the culture.

A year ago, I became a manager. I had no other choice but to talk to people in private. And I found my way of doing it. I don't do scheduled 1:1's because that is people's choice. But I make sure we talk stuff in public that needs talking, and I always ask for that private discussion. It's in the role, it happens.

Yet, I still remember the first time in happened in the new role. I asked another manager, who happens to not be a woman as I am the only woman, to speak with me on a difficult situation I was facing as a new manager. The jokes on two genders in one small room were overwhelming, and while I walked away, I was toying between punching someone and never asking again.

I believe offices are better if private discussions are normal and natural. They often are that for the more senior members of staff, who easily go pick up someone relevant and talk over a cup of coffee. To get there, here's my thoughts on creating a place that encourages them:

• Tell people that this is expected, especially the  new and junior people
• Give them tips on how to ask for a private discussion (calendar seems to be the normalized way around where I work)
• Do something with the overall atmosphere where noticing who talks is relevant by talking generally more openly
• Hold the jokes of men and women working 1:1 - they are  harmful beyond your immediate understanding

Bag of Candy - A Conference Talk Design

Having listened to conference talks in scale, and discussed potential conference talks in bigger scale, I've come to explain people that the most impactful conference talks are ones that make you do something.

They could be giving you an idea with motivation so powerful that you remember their version of it when the time of implementing that is right. At least you'd go back to office mildly pushing for a change, until you again accept that the organization isn't moving anywhere on your ask.

They could be giving you guidance of how to do something well, with quality. And when you return to office, you will do things differently just because you now know how to do it better.

For creating a program for a conference, the hard part is that people don't often suggest either of these kinds. They suggest all kinds of other talks:

• "I read a book and now I want to talk about it" 
• "We build test automation for 3 years and I want to talk about it"
• "I lived a great life with many turns and I want to talk about it"

The problem with the first it is not directly rooted in experiences of doing the thing. Thinking the thing isn't doing the thing.

The problem with the two others are that they are "life stories", experiences that are framed through fast forwarding a life rather than starting with conclusions from that life. I think of these talks as "bag of candy". 

A Bag of Candy -talk is one where the main character of the story is the main message. It's like a bag of candy with all kinds of goodies: some hard ones, some soft ones, some black licorice ones (the best kind!), some fruity ones and even some sour ones. We all love different kinds of things, so there's a little bit of something for everyone. Everything in the talk is an invitation to start a discussion, but it leaves very little learning to the listener. You did not learn how to properly enjoy the black licorice, you just heard some way it is awesome. 

What if we would frame our talks around that one kind of candy, and illustrate the greatness of that with our experiences and stories. What if the audience left with a compelling idea of releasing daily, scaling tests like the speaker does, or being mindful in day to day job to do better instead of more. Just mentioning this idea does not stick. To make ideas stick, we need to walk our listeners to those ideas with us, illustrating from multiple directions. 

I choose one candy talks over bag of candy talks. Which ones do you prefer? 

Pull, don't push

What if you could start with the end in mind? You could be aware of all the good things you have now, imagine something better and focus on finding a step to that direction. This way of thinking, a step by step, pulling value out is what drives the way I think around software development.

Starting with the end in mind and pulling work to get all the way to the users, it is evident that nothing changes for the users unless we deliver a change. All the plans are pushing ideas forward, pushing does not have the same power as pulling. A concrete example of how something could be different is a powerful driver to making it different.

I'm thinking of pull scheduling today, and I reviewed yet-another-product-realization-process draft that seems to miss the mark of idea of power and importance of pull.

Pull helps us focus on doing just the work now that we need in delivering that piece of value.
Pull makes us focus on learning on what is worthwhile so that we don't get pulled on random things.
Pull enables collaboration so that we together make work flow.
Pull centers the smart thinking individuals who pull what they need to create the value upstream is defining.

When we know we need an improved user interface, pull helps us realize that we should get the pieces together for delivery, not for a plan.

Plans push things through. Planning is always there when work is driven by pull, plan is the continuously improving output.

Who is pulling your work? 

From Individual Contributors to Collaborative Learners

Look at any career ladder model out there, and you see some form of two tracks that run deep in our industry: the individual contributors and the managers.

Managers are the people who amplify or enable other people. Individual contributors are the one who do the work of creating.

The ideas of needing a manager run deep in our rhetorics. Someone needs to be responsible - like we all weren't. Someone needs to lead - like we all didn't. Someone needs to decide - like we all were not cut out for it. And my biggest pet peeve of all: Someone needs to ensure career growth - like our own careers were not things we own and work on. Like we needed a specially assigned role for that, instead of realizing that we learn well peer to peer as long as kindness and empathy are in place.

For years, I was a tester not a manager. And this was important to me. And in my role as a feedback fairy, I came to realize that as an individual contributor, there was always a balance of two forms of value I would generate.

With some of my actions, I was productive. I was performing tasks, that contributed directly to getting the work done. With some of my actions, I was generative. I was doing things that ended up making other people more productive.

One of my favorite ways of contributing became holding space for testing to happen. Just a look at me, and some of my developer colleagues transformed into great testers. I loved testing (still do) and radiated the idea that spending time on testing was a worthwhile way of using one's time.

As an individual contributor, I learned that:

• My career was too valuable to be left on the whims of a random manager
• Managing up was necessary as an individual contributor so that random managers would be of help, not of hindrance
• Seeking inspiration from peers and sharing that inspiration helped us all grow further
• The manager was often the person least in position to enable me to learn

In most perspectives, it became irrelevant who was an individual contributor and who was a manager. The worst organizations were the ones that made an effort to keep those two separate by denying me work I needed to make the impact I was after as a tester because that work belonged to manager.


Any of the impactful senior individual contributors were more of connected contributors - working with other folks to create systems that were too big for one person alone.

As I grow in career age, I realize that the nature of software creation is not a series of tasks of execution but a sequence of learning. Learning isn't passed in handoffs, with a specialist doing their bit telling others to take it from there. Learning is something each and every one of us chipped away a layer at a time, and it takes time for things to sink in to an actionable level. Instead of individual contributors, we're collaborative learners.

When the No Product Owner Breaks

Two years ago we did a 3-month experiment for "No Product Owner". We listed all the work we expected a product owner to be doing, recognizing a particular idea around prioritizing work and knowing about customers on a level where their priorities would somehow better reflect the needs of the business. And we agreed that instead of that old-single-wringable-neck-of-responsibility, we would not have anyone in that role, but we would do all the work we recognized on that list as a team.

The 3-month experiment turned into how things roll around here. And these have been the happiest, most productive two years of my professional career. Even with the fact that I've now also become the reluctant manager trying to understand why managers were ever needed and how that could become untrue again.

The first impacts of No Product Owner were evident and easy to see:

• Developer motivation through ownership.  Feeling you don't need permission to do what you know is right did wonders to what we got done.
• Emergence of monitoring. We refused to rely on feedback from those upset or active, and wanted to see the feedback in scale, even when the users were not pushing through all the obstacles to get the message to us.
• Owning up to all things maintenance. We opened our ears to hear what they said about us. We weren't picky on the per-process channel, but focused on hearing and understanding, and dealing with it as soon as we could.
• Frequent software delivery. Making a release was our choice. We paid attention to the costs of it. We released more frequently, collecting less stuff on the shelf.
• Unfiltered developer - end-user and 3rd party communication. Solving hard to solve problems in debugging calls, getting other 3rd party devs to understand the right details, and not needing to remove the damage filtering can do on understanding end user needs.
• Implementing beyond own "box". We'd use the internal open source model to implement things truly end to end so that "done" became something that was in the hands of our real end users.
• End-user documentation turned part of product. We started writing end user documentation, targeting our release notes as useful communication and working with marketing to highlight themes that had been bubbling over a longer time. 
• Discovering features never requested (measured useful). We would listen to problems not just as bugs to fix but as opportunities of designing better features.

Many people suggested we just used to have a bad product owner. This is not the case. Many people suggested that I just became the product owner. This is not the case either. What I did, however, is help people see when they might be dropping a ball. And I took some balls and dropped them, just so that other people could pick them up. What I keep doing is analyzing how we do and what I am learning as we are doing it.

At two years, I'm starting to look at the places where the No Product Owner approach is breaking for us. I currently model this as three levels of signals, where some we are able to work with and others need something we don't naturally have.

• Loud signals. Hearing what people say is not that difficult. It even works that they say it to any of us, and any of us deliver the message further in the team. If someone has a clear idea of a feature and they ask for it, this comes through loud and clear. If someone has a problem with out product and they figure out that it indeed is a problem and contact us, it comes through loud and clear.
• Medium signals. These are signals that already require some amplifying for them to turn into action. Like a badly written bug report from end users. Or need to create a monitoring view that shows a trend. We've improved in dealing with this a lot over the two years, and it looks to be an area that will grow.
• Low signals. This requires so much work, that we may need to  bring back a product owner role just to work on this. It is easy to miss relevant things that we should be acting on, because work required to make the information actionable requires significant amounts of work. Be it the "this feature isn't really very good" and making that into ideas of how it isn't good and what we could do to make it better, or seeing and innovating technologies that would change how we see the playing field. 

For the low signals requiring work, this work was missing for us already while we were in the with-PO mode. There was so much other work for the product owner that they were running with their analysis almost as much (or a little differently, but just as much) as the rest of us.  We need an analyst role that works (and coaches the rest of us to work on) on low signals and amplifying the ones of those that are important to actionable. Preferably so that they would understand incremental delivery.

It just might be that that is what we'll ask the product owner to be, or that is what I find my role growing into. Time will tell.

When Four Should Be One

There's a piece of wisdom that runs by the name "Conways Law". Conways Law states that organizations (or rather, communication structures in those organizations) will constrain software architectures so that your organizational structures turn into your software architecture.

For the moments when I was thinking we were somehow less impacted, with our relative success of having an internal open source model, I realized that while the architecture may not follow the manager-assigned organization, it still is very much impacted by communication flows and power structures that exist.

Our system test automation structures, however, don't fight the Conway's Law at all. Someone drew four separate organizational units, and at worst, I can go find four slightly different duplicates of similar tests. This post is my pamphlet to going into a war against these forces, when I really just probably should be making the organization pull a inverse conway maneuver and changing how the teams are structured.

I work in a situation where I have four, but I should have one. I believe that this would change by first changing the way we visualize the four, now as one. It would immediately follow on getting the three and the one most separated together. And then the hard work of introducing a new model of understanding what is an application test, what is a product test in a way that is not product team specific.

The Non-Verbal Feedback

I'm a tester (whenever it suits me) and as testers, we specialize in feedback. Good feedback is true and timely, and while we think of feedback as the things people turn into words, a lot of times it ends up being non-verbal.

We look at an application for the purposes of testing, waiting for it to "whisper" where it has problems. The application is my external imagination and all I need is to give it a chance to tell me the very quiet messages that I can then amplify. I need to be ready to listen to multiple narratives:

• does it do what we intend and reasonably expect it to do?
• does it have adverse side effects to anything we care about? 
• does it cause someone problems, either now or when trying to keep it running in production?

We amplify feedback, keep it true, and increase its power making it actionable. If we are timely, a moment later no one remembers the problem.

Similarly as people give feedback on quality of applications, sometimes we need to venture to an even harder side, giving feedback on the quality of the people producing our applications. It is easier to look at an artifact and describe its features we appreciate and don't than to do the same for our colleagues.

When it comes time for saying something about our colleagues, I find that we discover a human feature of conflict-avoidance. Leaving things unsaid is a choice many  of us make. Making choices of when to say and when not is something every one of us needs to learn.

As peers, we are asked to give feedback, but in case of a potential conflict, as peers we can more easily step away, say that continuing as if it isn't *that big a problem*. What I'm learning is that this is one of the many reasons organizations task managers to deal with small problems before they grow big.

Telling someone they should shape up their game isn't easy. It makes me feel awful, especially when it turns out to be a piece of feedback that may be hard for the receiving party. But all I do is turn something they're not paying attention to, something bubbling under, into words with the hope that through seeing it, you could do something.

When your pull requests get very little feedback, you could think of it as absence of errors, or what it truly is, absence of feedback. Why aren't you getting feedback?

When your colleagues don't complain about your work, that could be absence of errors, or absence of feedback?

What can you do to get to the absent feedback? And don't tell me "get a manager who turns it visible for you, as a service" and start servicing yourself. Feedback is the lifeline to improvement and absence of it is a road to stagnation.

The idea of turning implicit to explicit, invisible to visible and abstract to concrete could well be my tester guideline of what to do, I grow uncomfortable in providing this as a service while manager. It's something everyone needs to learn to do for themselves, and for their peers.