Friday, October 4, 2019

Job Crafting and Why Specialty Titles are Still Relevant

I work with a cozy 11 person DevOps team. I say DevOps, because we are running the development and operations of a fairly reasonable sized (in the millions) user base for a particular windows application product. We do ok, and I really like working on this, with these specific people.

These specific people are all individuals, 6 developers and 5 testers. That is at least the high level categorization. Yesterday was a particularly interesting day and I tweeted about it. 

Watching the ratio, thinking it is telling about the work we do in the categories of "dev" and "test" makes little sense. But watching the ratio as how many people hold the space for quality ("what do we really mean by done") and how many people hold the space for smart solutions ("how do we change things for the better") makes a lot more sense.

The testers implement features. The developers implement tests and explore. And this all is very natural. Everyone pitches in within what they can do now, stretching their abilities a little.

I think of the two main roles we hire for as centers from which we operate. When named a tester, you naturally navigate towards caring for quality, feedback and systems to give that feedback. Your home perspective is one of skepticism, wanting to believe that things could be broken. When named a developer, you naturally navigate towards adding functionality and internal quality to enable future work, and delivering changes to users to change their experience with the product. Your home perspective is one of believing in possibilities, seeing how things could work. When there is space for both perspectives in collaboration, better software tends to emerge.

I have been the solo tester with 15 developers around me, and holding space for quality feels different there than it does here. Here I am not alone. And a lot of times I find the best quality advocates are those I would block as developers.

I still call them testers and developers, because they still are testers and developers. But they are not binary. The testers are a little bit more testers than developers. The developers are a little bit more developers than testers. 

Seeking for both helps in hiring. It helps in creating a sense of purpose these people fulfill within the team while allowing the stretch. In the end of the day we need both perspectives and having people who feel ‘home’ in different roles help keep the perspectives strong.

There is no good word to move both into in a way that doesn’t send the message we give up on testers. There are people who want to be testers. Being a tester is great. Yet when seeking this one word, our gravitation is towards making us all developers.

I'm a big believer in job crafting - the idea that no matter what job you hold, you do little (or bigger) things to make it the job you want. The job that looks and feels like you. If you were hired for a purpose, crafting into a place where you forget what you came to do isn't what we seek. Understanding your purpose and value you are hired to deliver is important. But letting that stop you from growing, doing things smart or different would not be right. 

So if a tester developers features, they can still be a tester. If they don't test anymore, they should probably not be testers. Promise of a service that isn't there is just dishonest.

Friday, September 6, 2019

More Practice for the Feedback Muscle

Where I work, we moved this year to quarterly personnel reviews.

With two rounds behind me as engineering manager of a team of ten (max 15 on some rounds), I sometimes feel like I barely finish one before another one is already starting.

The way one round works is very similar to what we used to do "process supported" once a year. Automation generates a set of questions about your achievements, your learning and your goals for future. They are sent to the employee who fills them in. Manager can generate more forms all around the organization inviting anonymous feedback to collect info. And then the employee and the manager discuss that stuff together, planning forward for the next interval.

With 10+ people and 4 times a year, that is a lot of forms. And with all the colleagues I work with, that is even more forms on feedback their managers are inviting us to provide.

At first, I was thinking of the forms as a way of documenting achievements for posterity. After all, I facilitate a very productive team that not only does stuff, but actually provides value for end users. Everyone contributes in their own way, on ways I look at as unique and supportive to others. I'm a manager trying to escape management (clock is ticking, max 9 months to go...), so it only feels fair that the record I leave for future would help the future manager understand my reports successes.

I only needed one annual and one quarterly review to realize that the process needs to be played with. And when I say play, I mean more than "talk every day and make notes quarterly". It needs some serious play.

With my team, I announced we are doing it this time in pairs. This would work so that everyone again fills their own form and it gets sent to me. Then I assign everyone a pair, who is peer in the team. The pair will have the responsibility to fill in the bits of the manager, providing their colleague feedback. I will act as secretary and quality control person helping fill in gaps in relevant feedback.

Our quarterly review was feedback and feedback on feedback.

I learned that:

  • Everyone being the others manager, even if just as role-play was great
  • Everyone has relevant feedback and ideas to grow for their peers
  • In a pair + manager, both positive and negative feedback was discussed constructively
  • People generated ideas of what to try to do differently
  • I could add my pieces and views to the discussion that was much richer this way
Whenever some manager asks me feedback on their reports anonymously through the automation system, I always send an email to the person giving my feedback without anonymity. I believe anonymity only brings out the worst in people. It weakens the gift of feedback. It removes the possibility of a dialog and co-generation of ideas to improve things. It allows for resentment to build, and creates an atmosphere where you need to be guessing which one of your colleagues is unhappy with you in case on negative feedback. 

When I do this, I hear that it is culturally not possible elsewhere to do what I do - in the same organization. 

I hear people don't have the soft skills of giving feedback.

I hear people only talk about positive and don't speak of the negative. 

I hear people have no baseline of what really good looks like. 

The way I look at it, these are true for lack of practice. You need to build the feedback muscle. And just like with real muscles, those grow with repetition, practice and corrective feedback.

Giving feedback - radical candor - is relevant. If you hide your problems because they are hard to talk about, how do you expect to get good? If you don't share what delights you, how do you expect to get more of it? 

Monday, September 2, 2019

Breaking the Assumption of Review to Accept

It was one of the European Testing Conference calls, and I forgot to ask at the end of the call if they'd trust me to summarize the call in a tweet. I remembered I forgot only an hour later, and they were no longer around. I send a message asking for the trust, and the response taught me something of relevance I had had hard time communication before. The response asked me to run the message through them.

I felt deflated. I no longer wanted to write that tweet. I felt they did not trust me. I felt they wanted control over my tweets.

I sat on the response for some hours, thinking I would let it pass without tweeting, without saying anything. But eventually I responded and expressed how I felt.

"I do really bad with reviews (for acceptance), they suffocate my ability to do things. I do "you can ask me to delete" style of reviews." - I told them. 

"It's a tweet. Go ahead" and "I'm sure you'd look out for me" was just the response I needed.

They did not ask me to delete my tweet. I would have if they asked me to. The risk of me doing something irreversible was very low. There was no particular reason why the review needed to happen before the material was published as it could happen after. I would carry the risk of apologizing in public, explaining in public and reaching out to people with the odd chance that this time I failed at doing something I did routinely.

The tweet was something that made a pattern of how I prefer working very visible.

I build skills and competencies in me & people around me to do things without acceptance.
I expect things are discussed in preparation, not reviewed as final step.
I trust the doer to pull help when help is needed.

I was writing release notes for millions of users, all by myself. As we added another product, the product people wanted a review before publishing. I asked them to publish their own release notes.What we were already publishing routinely had all the info they needed. They just needed to add the review and republish. Waiting for that step did not make sense to me.

I welcome feedback on mistakes, to grow the skill. I kick out the testing-fashioned acceptance review, unless I see it is founded on actual risk.

I don't let people do this to me, and I don't do this to people. I've given up on being the guardian of quality and become the facilitator of quality. The work happens before and while, not after. And there's always the next cycle to act on feedback on mistakes.

Saturday, August 31, 2019

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.
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

Thursday, August 29, 2019

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? 

Tuesday, August 20, 2019

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?