Month: October 2019

Welcoming Women to our Teams Properly

Welcoming Women to our Teams Properly

By Lady Pain (Marta Manso) [CC-BY-2.0 (], via Wikimedia Commons

I’ve scarcely had the chance to work with women in my engineering career. They are very, very uncommon on teams I’ve been on and in classes I’ve attended. This article is actually not directed toward women. This writing is instead directed to the men this community is saturated with.

We are stronger in our teams when our teams are more diverse. Have you noticed? We get more ideas from our teammates when they come from different backgrounds from different places in the world. Diversity comes in many forms: age diversity, gender diversity, cultural diversity (which encapsulates all sorts of things), technical diversity.

When you get different people into a circle, if you are able to capture the different ideas in the circle, great ideas happen. I need people in my circle with different ideas than me to come up with a cumulative great idea.

Every time I’ve had women engineers to work with, I’ve found them to bring great talents to the team. I’m not sure if everyone else noticed, but they’ve been collaborative, observant, investigative, passionately skilled, and/or intuitively able to share vulnerable feedback I needed to hear. I don’t believe their unique qualities were fully realized.

There are well-established groups to promote women in engineering. I’ve never been to any groups to see them work. As a man, I’m not sure if I’m welcome. I probably am, but in this blog, my goal is to address how we welcome, encourage, and equip others in our teams to help them deliver their best.

My introductory Computer Science course in college was in the required curriculum. It was taught by the department-chair and we all took it. We worked through the lessons, and we did some labs in C/C++. The professor seemed to know what he was talking about. One year after I took it, a friend in my dorm took the same class. She had a very different experience! My friend is super smart, but she told me that this department-chair gave her disparaging remarks. These remarks were as if she didn’t belong in the computer-science lab, and she belonged in a kitchen somewhere. It was crazy to hear what would come out of his mouth. How could my experience be so different?

Here’s why my experience was different: I am male. That’s it. I was born with an XY chromosome.

My friend ultimately decided that computer science wasn’t for her. She moved on to a different curriculum. She became a successful pharmacist.

This experience dragged on my heart. How could a woman survive this type of harassment? How many women experience this? How could I not have noticed? When one of our leaders do this during a class (or during a meeting or other interaction), how many of us males consequently learn that it’s okay for each of us to also harass? Would we necessarily know if we’re diminishing someone’s participation on a team? Perhaps not!

The truth is there are many spaces in our technology communities where harassment is commonplace. From Stack Overflow, to Linux Kernel message boards, to our pull requests and water-cooler conversations down the hall.

My belief is that the women engineers I’ve worked with are so talented because they have survived so many obstacles. They’ve had to prove their worth over and over again and excel beyond normal expectations. They’ve pushed against the harassment and been forced to learn beyond what is normally expected of their male counterparts. Out of necessity, they’ve evolved into huge potential assets to the teams who get to work with them. Unfortunately, not all teams are ready to notice those unique qualities.

Men, if you have women on your team, I challenge you to notice their unique qualities. Give them broad bandwidth to make their unique contributions and for them to challenge your team’s standard point of view. They likely have excellent ideas on innovative ideas that they’ve not felt safe to share: it is your job to make it safe for them to share. Challenge your own point of view that you might not be noticing your teammates’ greatest abilities to innovate for your team.

Gender is only one of the many differences we have. Are there any other differences in our teams that prevented us from hearing great ideas?

What makes members of our team different is also what makes our teams better. Those differences give our teams an inventive advantage.

Additional Resources:
* Women in Computer Science: Assumptions to Avoid
* Girls Who Code
* MotherCoders

Curiosity And Bravery As An Engineer

Curiosity And Bravery As An Engineer

Sometimes I have a technical conversation with my son and I notice, “He doesn’t actually know what he’s talking about.” He struggles hard to say things he’s conjecturing on. It’s actually very easy to spot. And it’s not just with him: I think it’s easy to identify anyone in conversation when they don’t know the answer struggle to articulate answers they don’t actually know. Have you ever noticed this?

As a parent, it’s a great opportunity to help my son admit, “I don’t know.” It’s a brave thing to admit.

When I hear anyone say, “I don’t know,” it’s a huge trust builder! It becomes clear the other person had to admit that they’re limited. They are unable to answer. It is vulnerable. It is truth. It’s also an opportunity to connect: neither of us knows the answer to the question asked. It is hard to admit.

When I hear an engineer admit, “I don’t know,” I trust that person more. It specifically tells me that when he or she gives a direct answer, it means he or she does know it. I don’t have to second-guess their level of understanding as a listener.

I always want to know the answer to questions. There’s a part of me that feels incomplete with unknown answers. It is as I have a hole in my knowledge, and I take pride as an engineer knowing stuff. If I have a hole, I feel like an inadequate engineer, but that’s not real. It’s part of the journey.

The work of an engineer is not to know all the answers. Our work is to discover answers. It takes bravery to start this work.

In these moments I don’t know an answer is where learning begins. Curiosity is the activation-energy to learning. Curiosity is the right kind of response we can explore new answers and new ideas and understanding of how things work. These are also times when engineers can connect best: we discover an answer together.

Innovation is often a logical result of discovery: it might result in an amazing idea. We can be open enough to what we didn’t already know. We can take other kinds of experience we’ve had and apply them to a new concept we’re actively learning about.

As an engineer, the fewer answers we have solidified, the greater the opportunity we have for learning and innovation. I encourage you to bravely admit an answer you lack. Be ready to start the needed work of discovery.

What will you innovate next time you admit, “I don’t know?”

Democracy: Ownership Of Our Process

Democracy: Ownership Of Our Process

We do what we’re told to do. Every day. Every iteration. Every release cycle. We finish our software features, and our customers are happy about what they get. And at every iteration, we do better at making code, because we’re continuing to improve our software, our infrastructure, and our tests. In the spirit of the Scrum process, we’re also improving our process. We can call this continuous improvement.

If we are closely following the rules of Scrum, we’ve instituted a retrospective regularly scheduled into our process. Our goal during a retrospective is to make our process better. We typically have one for every sprint, we invite all the team members to the retrospective, we look at both the good things that happened in that sprint, the things that need improvement, the ways in which we can improve, and we make specific goals to improve our process.

It’s easy to fall into a routine each day at work. Retrospective might actually become routine. The more routine sets into our mentality at work, the less likely we are able to innovate. This is highly true also for our retrospective and the goals coming out of it.

A critical element of a retrospective is voting. As a member of a scrum team, we can vote about what is important to how we work. Managers don’t vote. Product owners don’t vote. C-level people don’t vote. Neither customers nor users vote. We vote as members of our scrum team, and with each vote, we own the process of what we’re doing.

Consider with me some ways to make the best of our retrospective process.

Mental preparation

We make complex software! Doing what we do, it is too easy to forget about all the things that happened in a sprint iteration! Just like we spend time thinking about software architecture before we start building software, we ought to spend time thinking about the successes and the opportunities we had to improve during the sprint. It’s best, even, to jot those things down as notes as they happen. We then would return to those notes during the retrospective.

As we make our notes, we would both celebrate things that went well and opportunities to improve. Consider, that some events might both have gone well and have been an opportunity to improve.

Dot voting, private voting

As stated above, voting is the real substance of ownership of our work. Let’s do voting right!

Each item on our lists is likely very different from the others. In a retrospective, we have lots of items to consider! It’s not realistic to vote just for one item. If we can use many votes, we can spread our concern across many items and prioritize what we need to.

I once worked in a team where we each had 10 votes. In the process, we had one member who waited until everyone else voted, and then placed all ten of his votes on a single item. One time, that item didn’t receive anyone else vote for it. In effect, this one member canceled every other person’s vote and controlled the direction of the retrospective. That was not team ownership, but ownership by one guy. Let’s try something else: private voting.

Our democratic process in the United States (and most places) means that we vote privately. We don’t know how others are voting until the very end when all the votes are cast. Were we to know how voting is going before we vote, that process would probably look very different. We might need the help of some software-tool to do private voting: it’s important to ensure team-ownership.

Following up on goals

Lest we fall into routine, it helps to follow up on what our goals from the previous retrospectives. We need to apply those goals to the work at our desks. This is more difficult than it seems!

In some cases, we can create work-items that have specific objectives to improve. Those work-items need to come into our sprint cycle (and be estimated and prioritized with other work). This can ensure the completion of those goals, but it could require competition with other goals from the product point of view.

In many cases, retrospective goals aren’t clearly about repeatable events, but about patterns in our process. It helps to have a Scrummaster come alongside what we are doing in the sprint (or possibly many sprints later), to help us ensure the best practices we agreed on as a team.

How we use the retrospective is an entirely good use of time within a retrospective. This sounds paradoxical, but it can be a very good discussion for a team to discuss how they ensure goals get best executed.

Software tools for retrospective

I’ve worked with a few different tools for retrospectives, and I can’t say that it’s important to use a tool, unless you have members of the team working remotely. As long as the process ensures the dignity of each vote and each member’s desire to improve the team, using a tool isn’t important.

Putting that aside, I’ve used these tools. FunRetro and Retrium are tools aren’t that different from my point of view. They make both make use of a GUI that looks like post-it-notes.

My favorite is a tool from Team O’Clock, where the interface is very deliberate to walk a team through the specific parts of a retrospective, helping a team stay timely with the meeting. It appears this software also helps move through daily-standup meetings and planning-poker, too, but I’ve not used this implementation.

In summary, doing a retrospective is a critical step in making a team own their process. It can help ensure each member is fully owning what they are doing, and they are more fully engaged in what they are doing. Each member can be proud of the continuous improvement process that they are a part of.

Theme: Overlay by Kaira Extra Text
Cape Town, South Africa