While I’ve been finishing that book, I’ve also been finishing up this year of teaching at the University of Washington Information School.
For the past two quarters, I’ve been teaching a Capstone class for undergraduates in the Informatics program. With the support of an outstanding TA (PhD candidate Tessa Campbell), I’ve been leading my groups through the process of conceiving their own projects, researching them, and bringing them to fruition through design and coding.
It’s a capstone program, which means that the students are mostly in their final few months of their degree program. They are putting into practice the practical aspects of their education, creating portfolio pieces they can discuss in their interviews to become product owners, developers, researchers, designers, and other information-based roles.
The most important thing that’s possibly new to them is how to manage their collaboration, time, energy, and ideas across this long-term, large-scale project. They are truly the ones in charge of their projects; there’s no instructor telling them exactly what to do. It’s up to them to imagine the project, scope the MVP, research the feasibility of the technology, the experience, and the marketplace (for those who want to commercialize). For most of them, it’s the first time they’ve had this level of control, ambiguity, and dependency on their teammates.
As they work, I can’t help but reflect on how I learned to be a member of a team. I see a few students fall into my most-common trap: Overfunctioning. This was a word I was introduced to by my first manager at Xbox, and I didn’t really understand it for several more roles (unfortunately)!
You might be overfunctioning if you, like I have, see gaps to be filled in other peoples’ workload, and jump in to help. Helping is good, right? It turns out the problem with overfunctioning is not the helping, but in the jumping.
It’s great to help. It’s even good to be able to help in a lot of ways. But when I jump in to help too much, it has these negative effects:
It means that my teammates, managers, and the larger organization doesn’t understand the value of my work, because I didn’t let them experience (or even be aware of) the problems I was jumping in to solve.
My other teammates don’t get a chance to volunteer, because I jump in without letting other people even be aware of the problems I was solving.
Over time, I end up being expected to help out in lots of ways beyond my regular workload, which contributed to my work being undervalued.
What I’d like to teach my students now is how to help without jumping, by stopping to examine the work and the help that’s needed. That way, the extra workload gets acknowledged, which lets it be discussed and accounted for in the future. The whole team gets to recognize that these projects take more resources than they initially may have estimated, so they get better at estimating projects in the future.
But instead of jumping in to help my students learn this lesson, I’m trying to help them recognize and discuss it. Hopefully, they’ll learn this lesson a lot earlier in their lives than I did.
