Tuesday, July 19, 2016

How to Be a Leader, Shopify Style

Self-actualization, that thing at the top of Maslow’s hierarchy of needs: “what a person's full potential is and the realization of that potential.” Shopify cares deeply about growth, and aims to be a company where its people reach the self-actualization level of the pyramid. I think that’s pretty special, and it’s just one of the things that leaders need to manage during their time at Shopify.


For the last few months, I’ve been participating in what we call Lead Level Up. I’m not formally a team lead yet, though I have been in a bit of a leadership role and should become a team lead eventually. A lot of what we learned in the all-day kick-off is general enough to share, so I’m going to highlight the things that resonated with me the most. Most of what follows comes from our CEO and co-founder Tobi’s presentation that day.

An interesting fact is that Tobi and his co-founders/early employees didn’t know how to be managers. It was an entirely new skillset. Tobi admits he was not a natural manager; he found it difficult losing the tight feedback loop you get when programming. He admits he fought often with the others in the early days until they sat down and decided to respect each other by committing to being honest and improving their feedback.

Tobi ultimately believes that he was able to improve his own management skills by learning how to better give effective feedback. Everyone is bad at this at first, and there is no limit on how much better you can get. It can be really difficult to take feedback as the gift it is because your ego is so tightly wrapped in the exchange. When I was an instructor at Carleton, I learned how hard it can be to give good, honest feedback, especially if the other party (students, in my case) don’t entirely trust that you have their best interests at heart. I’m now learning to give feedback with radical candour.

A major tool that will help any manager is trust. Trust is more nuanced than a binary relationship. Trust exists between departments, and is fundamental to being highly aligned and loosely coupled (that is, fast-moving teams with high autonomy working toward common goals). When you start seeing a large amount of process being introduced, it’s usually because there is a lack of trust. Process is a prescriptive solution to a problem that isn’t terribly intuitive. It’s a bit like baby-proofing.

After trust is established, the manager’s job is to make their team better every day. If the team is not getting better, it is getting worse. Questions a manager can ask include whether they can remove any ambiguities or dependencies, have they helped someone have a breakthrough, etc. Focus on the high leverage activities that yield the greatest output for your team. Teaching, for example, is high leverage in all its forms. One-on-ones, while important, may generally not have high leverage.

Speaking of one-on-ones, how do you make them effective? Have them at least once a month. Take notes. Find your own style. Use them as a learning opportunity, and a chance to understand the other person. There will be hard situations, and they are only solvable if you have an extremely good read on all involved. Crucially, you must give good, honest feedback. And if you ever hear during a one-on-one that you have made a massive, positive contribution to someone’s life, then you know you’ve made it as a manager.

As mentioned above, managing is an entirely new skillset. Become well-rounded, focus on personal growth, read a lot (e.g. High Output Management and Thinking Fast and Slow). Become the guidance counsellor, the coach, the shrink. Help get yourself and your team to self-actualization, and you’ll do just fine.

Monday, June 6, 2016

Google I/O 2016 as an Anita Borg Scholar

Back in February, I ran an event to celebrate Anita Borg's birthday. I along with some Shopify colleagues focused on students not majoring in computer science; we invited them for a short talk, organized mentoring activity, and coding workshop. I got the idea from the alumni network of past Google Anita Borg Memorial Scholarship winners: we were invited to run events all over the world. Google program managers picked the most impactful events from each region, and the winners got to attend Google I/O all-expenses-paid. I was one of the winners!


I'm not a developer within the Google ecosystem, though I do use Google products to run my life. (Even more ironically, my husband is currently an Android developer.) As such, my experience of Google I/O wasn't going to be based on the talks per se. Instead, I focused on networking while catching a few talks that seemed interesting and relevant to my group back at Shopify.

Most of the AB scholars attending for the same reason as me stayed in the same hotel, and I was really grateful to be able to head to the conference grounds with one of them after arriving Tuesday afternoon (thanks Saboya!). We got our conference badges and then headed to the Women Techmakers dinner around the corner. There, I met a bunch of wonderful women, including some as passionate as me about computer science education. I also met up with some women with whom I submitted an (unsuccessful) Grace Hopper panel proposal. The event was lovely and I'm very appreciative of the folks that put it on.

Fellow scholar Saboya before the delicious food was served

The next morning, I/O proper began. Our group of scholars was extremely lucky to be given reserved seating at the opening keynote. Hosted at an amphitheatre, half the audience was in the direct, late morning sunlight for two full hours. We were in the front half of the seating area and therefore shaded.

The keynote itself had a really fun opening with animation and music that was totally my style. I wasn't terribly inspired by CEO Sundar Pichai, and it took a while to see any women on stage. But there were a few interesting announcements like Google Home and clever uses of AI in messaging, even if I still don't see how changing the font size in instant messages was ever considered note-worthy.




After the keynote, there was a flood of people having no idea where to go to get lunch food. The conference had to feed us because there was nothing else available anywhere nearby, but being so incredibly hot and sunny, it was not exactly comfortable to eat most places on site. Our group of scholars and friends managed to find a tree to sit under, which was again quite fortunate.

This was the best we could do for lunch. Many were stuck in the sun.

You may be starting to see a theme here about the sun. Many folks, including my work colleagues, were feeling sick from being in the direct sun during the keynote, and it was difficult to escape it the rest of the conference as well. The activities were all spread around the amphitheatre's parking lot with little shade available.

Talks were in air conditioned tents, but there was grossly insufficient seating in them, so long lines started forming an hour or even two before the most interesting talks. I was lucky to get into a couple of the rather popular virtual reality talks without dying of sun stroke, which was nice. But I only attended three talks in total because it just wasn't worth standing on pavement in the sun. Frustrating to consider that people watching the conference from home for free got better access than those spending hundreds of dollars to be there in person.

I spent most of the conference chilling in the shade, but because of the reasons I was there, I didn't mind. I had opportunities to chat with work colleagues as well as fellow scholars and new amazing women I tried to recruit to Shopify (still hoping to hear from some of them!). I'll never forget the many times I got to talk CS education with some truly amazing people.

Plus, you can't complain about the parties, assuming you weren't too exhausted by the evening to attend them!




Our scholars group got to meet up several times for meals at the neighbouring Google offices, and on the last day of I/O we gave presentations about the events we ran. So inspiring! I am really looking forward to keeping in touch with the group, and seeing how we might make an even bigger impact together.


All in all, despite the griping about I/O (no device giveaway!) and the very real issues with this year's venue (your take-home is heat exhaustion!), I'm very grateful I got to attend and that I got a lot out of the trip. Can't wait to meet up with some of the scholars again at Grace Hopper!

Friday, May 13, 2016

Innovation Needs Computer Science

On Wednesday, I gave a talk at an event called Ignite that brought together government and business folks to talk innovation. There were four lightning talks of about 5 minutes each, and mine was on computer science education. Below is a transcript of my talk.


This event is not focused only on technology innovation, but let’s face it: technology is everywhere. Computers are everywhere. And yet, most of us are just consumers of technology, rather than producers. I’m willing to bet that this applies to many of us in this room.


There is so much to gain from learning computer science, not least of which is to think in a new way: we call this computational thinking. You gain skills applicable to so many areas of life, like decomposition, pattern recognition, abstraction, and algorithm design.

And, if you learn to program on top of it, you can learn how to automate the really boring, menial tasks you may be completing manually right now. ;)

More generally, with some computer science knowledge, you can create things instead of relying on others to do it. How empowering!

Based on the benefits, I believe that innovation will increase as more Canadians understand at least some computer science.

So why aren’t more of us learning it?

There are two big factors that contribute: misconceptions about what computer science is, and problems with computer science education.

One of the biggest misconceptions of computer science these days is that it is just about programming computers. Many people aren’t interested in learning to program for the sake of it. However, computer science is actually not equivalent to computer programming; it’s about solving problems. It just so happens that programming is one of the tools used to realize a solution.

We have some cultural problems for computer science as well. Who do you picture when asked to imagine what a computer programmer looks like?

The Nerd

Perhaps more importantly, what does Hollywood have to say about it?

Even worse, an awful lot of people believe in the “geek gene”: you either have the brain for logic and programming, or you don’t. This is known as fixed mindset, but what we really want is growth mindset: the belief that anyone can do it if they are willing to put in the time and effort. You don’t have to be a genius to learn computer science; you don’t even have to love math.

And best of all, your main job doesn’t even have to be as a computer programmer! Because computers are everywhere, you can pick your passion and use computing to solve problems in that area. (That’s the thing that excites me the most about CS – you can use it to the solve problems you care about and made a real impact on the world.)

Unfortunately, even if we are able to clear the misconceptions of computer science and get more folks interested, we still have the issue of effectively educating them. A lot of people are interested in learning computing in theory, but don’t pursue formal education opportunities. The way we teach computer science just isn’t appealing to most.

For example, women are severely underrepresented in computer science. It’s difficult to recruit women and other underrepresented groups, and it’s even harder to retain them. Members of these groups face issues like stereotype threat and low confidence in their abilities compared to the majority group of white and Asian men.


Ensuring students get insight into what computer science is in K-12 is a big help. But K-12 teachers are generally not trained in computer science, and don’t know how to teach it. Beyond that, the lack of confidence many have of their ability to learn and do computer science affects their students’ beliefs as well, not unlike what happens with math.

Computing education research is also in its infancy. We are just scratching the surface on how to effectively teach computer science, especially to beginners. Pushing this research forward, and finding more effective ways to share results with teachers, is important.

So what can we do?

  • We need to give students in K-12 a more accurate picture of what CS is, and teach them fundamental skills so they can become producers sooner.
  • We should also scale informal education to help achieve this goal.
  • Curriculum and pedagogy at all levels should be carefully redesigned to be inclusive and engaging to a broader range of students.
  • Related to this, we need to support and encourage faculty in Canada to pursue computing education research.
  • We need to actively recruit underrepresented groups – “build it and they will come” does not work here.
  • We need to change the culture around CS and programming. This may be the hardest task of all if we don’t get broad buy-in, including in Hollywood.
At Shopify, we recently started building a new team that hopes to contribute to each of these issues. My role is Manager of External Education Programs.

Since we began earlier this year, we’ve started forming partnerships with educational institutions and experimenting with new learning models for computer science. We care about making learning computer science better for everyone, where “everyone” is as inclusive as possible.

I hope that everyone here today will also play their part, even if it’s just to spread the word about what computer science is really all about to the people you know.

Let’s make change together.

Photo by Matthew Usherwood

Thursday, April 28, 2016

'Take Your Kid to Work Day' Coding Workshop with ScratchJr

A new professional development day was recently added to our local school board's calendar. One of my colleagues, John Duff, made the brilliant suggestion to have a 'take your kid to work day' instead of scrambling to find babysitting. Naturally, I suggested we also add a coding workshop.

Little did I know that most of the kids in attendance – my own included – were between 4 and 7 years old. Grade 4 or so was the youngest I'd ever worked with before, and the idea of teaching kindergartners was especially foreign. Thanks to the helpful advice of a few kind folks (especially Kate Arthur of kidsCODEjeunesse), the workshop turned out great!

To prepare, I read through a bunch of The Official ScratchJr Book from No Starch. The book is awesome, and I definitely plan to use it to continue working with Molly. One thing that I especially liked was the curriculum connections listed out at the end of each chapter. If you happen to be a kindergarten teacher, and have access to tablets, I highly recommend checking this book out.


In case you want to run a similar workshop, here's a bit of info on what we did. The workshop was held in our coffee shop. We moved away a bunch of tables and set up our bear beanbags in a semi-circle in front of the projector screen. I AirPlayed an iPad to the screen for demonstration purposes. To get the attention of the kids, we did a "hands on head" thing: everyone, parents included, had to have their hands on their heads before I talked about the next thing.


Before the workshop, I sent out a doc with information for parents containing the following key information.

 What we'll be doing
We will be working with ScratchJr, which is a visual block-based programming tool. While not required, you might like to learn a bit about the tool ahead of time. On the website, you can get an overview of the interface, the sprite editor, and what each block does. There are also videos with tips
ScratchJr is officially intended for ages 5-7, but the appeal for this workshop should be broader. That said, older children might prefer being a “helper” for a younger sibling and/or trying out the web-based Scratch instead. The older kids could get the basic ideas in ScratchJr first, and if they get bored, they should be able to pick up the main ideas of Scratch fairly easily. 
We have arranged to bring iPads for those who said they needed them.
We recommend bringing your laptop with you, both to look things up about ScratchJr, and to switch to Scratch if desired.
During the workshop
The assumption is that you, as the parent, will sit with your kid the whole time and work with them on their projects.  If you are bringing two kids, you may choose to have them work together or separately. We are hoping to have extra volunteers who would be able to help if they end up working separately. 
We hope to have those participating in the workshop up near the projector, “circle time” style. We should use comfy chairs and beanbags to sit on in a generally circular shape. 
One of the techniques we plan to use to gain attention of the kids is “hands on head” – when we ask kids to do this, it would be great if parents did it as well. Once everyone’s hands are on their heads (and therefore not touching the tablets/computers), we can starting talking up at the front. 
Super important: Try as much as possible to not do anything for your kid. Make sure that you guide them, ask them questions, perhaps even make suggestions, but not do it for them. 
Try to stop your kids from playing with other apps on the iPad at first (perhaps turning off wifi will help?). Later on, if they get bored of working on their own projects, they might enjoy sharing their favourite apps with the other kids.
General workshop plan
  1. How to add a new sprite and edit it.
  2. How to add a new background.
  3. Example blocks (will ask kids what they think the blocks do before showing them; time to play will be after all blocks):
    1. Move right (what does the number change?)
    2. Turn left (what does the number change?)
    3. Say (how could you have it say your name?)
    4. Play recorded sound (try recording your voice!)
  4. Example of snapping blocks together (can you guess what will happen?)
  5. Start on Green Flag:
    1. Have them add this block to the beginning of a script (suggest a bunch of movement blocks to make the character dance)
    2. Have them press the green flag button at the top
    3. What happens?
  6. Repeat forever
    1. What happens if you put a repeat forever at the end of the script, then press the green flag?
  7. Save your project! Go back to the home screen to save
--

I was pleasantly surprised that we managed to keep the attention of the youngest kids for a whole hour. Later, at lunch, several of the girls excitedly exclaimed how much they loved working on the iPads / playing with ScratchJr. Music to my ears!




Sunday, April 17, 2016

Mastering Difficult Conversations

Do you dread bringing up a problem in your relationship because you know your partner will be blinded by emotion? Are your 1:1s at work just happy recaps of your weekend because nobody wants to bring up the hard issues? Sometimes conversations are just plain hard, but it is possible to learn how to have them effectively. I've personally learned a lot from Difficult Conversations: How to Discuss What Matters Most, and have even put some of it into practice already.


The book introduces three conversations that are really taking place in a difficult conversation: what actually happened, how feelings factor into it, and how the participants' identities might be affected. When you're about to embark on a difficult conversation with someone, you should first walk through each of these three conversations to sort out where your story came from as well as the other person's, to "explore your emotional footprint," and to reflect on what's at stake in terms of how you see yourself.

Then, you need to determine what your real purpose in the conversation is. Generally, it's a good idea to come from a place of learning, which means keeping your mind open to the fact that you could have been wrong about how you viewed the situation.

When it's time to talk, you want to start from the "third" story – that is, you need to "describe the problem as the difference between your stories." You have to pretend you're an innocent bystander, and invite the other person to become your partner rather than your adversary in sorting out the problem in front of you.

During the discussion, you have to be an amazing active listener (so much easier said than done!). Acknowledge, paraphrase to check understanding, question...and continually reframe to keep on track. Then, finally, you can get to the problem-solving stage.

A few key takeaways for me:

  • Never lay blame; instead, talk about contribution, and try to reframe the conversation to help the other person do the same. Every problem arises because of contributions from both sides, even if the split is 95% to 5%.
     
  • Pay special attention to feelings. They are always there, and they can get really complex. Even in a professional situation, it is ok – and important – to discuss how various actions and outcomes make you feel. It can help to sort through feelings before the conversation so you can unpack complex bundles of emotions and better explain your perspective.
     
  • Be mindful of your identity, and how it has been affected by the problem you are facing. The reason that the conversation is so difficult might be because you have to face the fact that you may not be acting in alignment with how you see yourself.
     
I've used the ideas in the book already to talk through how a friend might be able to approach their next 1:1 at work. The feelings story was of particular importance in this case, and not something that my friend would have talked about normally.

I have also found the knowledge useful when faced with a difficult conversation started by someone else. Where I might have normally become defensive and frustrated, we were able to resolve our problem somewhat quickly. (Now I just have to make sure I don't do the same dumb thing again.)

I think this book would likely have something useful in it for just about anyone. If you're in a leadership position of any kind, it will be all the more valuable.