I moderated a Rice University panel with six recent Computer Science graduates to learn how they were faring in their transition to their new post-graduation world. Luckily, for computer science majors, the job market has remained relatively strong despite the pandemic. The jobs were already easy to do remotely, the companies already invest in and use remote communication tools like Slack, Zoom, and Github, and the tech industry has seen increasing use of its products while everyone is stuck at home. Here is what I learned.
All of the working members of the panel had interned before at the places they landed. That made their remote transition easier because they already knew the culture and their team. This is an unanticipated benefit of those internships that organizations offer.
Some moved to the city where their new job was and, if they had friends there, they were meeting in parks socially. Several were glad they hadn’t moved and were relying on their ‘home town’ friendships.
The new graduate student had moved but was taking classes remotely. He was able to get to know fellow graduate students in the classes that had breakout sessions, but it definitely was harder.
The big companies were still doing two week orientations – just online – with a combination of talks, labs, and icebreakers. I would like to have dug into that more. What on earth is two weeks of orientation online like?
The key to the social activities seemed to be having a variety to try out, because some are awkward and some work well, which varies by person. Some of the social activities are clearly helpful for work life and others work better for building friendships. Lunches and happy hours were more awkward, but still good for team building. Some companies were offering ways to have a randomly chosen coffee chat, and ways to get a mentor.
One company offers monthly wellness in-days, rather than a day off. It is a day in, but with work-life-balance themes (health, yoga, earth day).
Since this is a CS panel, folks were taking advantage of social slack channels (pets, alone-together, games), and online game groups organized through work (Code Names, Jack Box, Scrible, Brackets).
Not having a commute was a real plus.
As you might expect, working hours have shifted. Several mentioned working long hours without realizing it because there is no transition, and others had shifted to working later into evening hours to take advantage of outdoor activities earlier in the day.
They all missed being able to ‘roll your chair’ over to a colleague and ask questions, chat in the break rooms, etc.
Product managers are responsible for creating and delivering the right thing to their customers.
Product Managers are sometimes called product ‘CEO’s’, because of their central position of authority with respect to the product, and because of the need to communicate the vision for the product both to an audience of ‘investors’ (the company leadership) who must provide people and resources, and to their own team who must deliver the product. They are not ‘owners,’ however. Ownership conveys the wrong set of skills. Product Managers aren’t buying and investing as an owner would, and they aren’t deciding where the team invests time and energy based on their own personal preferences as an owner would. Instead, a good Product Manager has to learn the needs of their customers, and figure out how their team can fulfill them to achieve the organization’s strategic goals.
Great product managers are skilled at determining what the right thing to build is with the consumer in mind, communicating that to leaders, colleagues, and team members, and then working productively and flexibly to deliver the right value to their customers.
I recently gave a talk to Rice University Computer Science Alumni as part of a panel on Product Management as a career, and you can access my talk and slides below. In this series of posts, I will be going into a lot more depth to explain more ‘tools’ for the product management toolbox and how to use them effectively to create useful and beneficial products.
Students are doing homework after a full day, and may be caring for siblings, working, and helping out at home. Some of them don’t have adequate tech or space to work. Homework is a second or third shift for them and may be increasing educational inequity.
Is ed-tech exacerbating inequity?
I have been thinking a lot about where ed-tech might be exacerbating existing inequity. And that led me to read a colleague’s tweet of “Homework is a Social Justice Issue”, originally published here in 2015. It talks about the underlying assumptions being made when we give homework, especially in K12: that students have the time, background knowledge, and tools to do school work at home. If students are working or taking care of younger siblings, they don’t have the time. If the type of work often lures in parents of affluent students to help, then they probably don’t have the background knowledge yet. And if the homework is on a laptop/phone and requires internet access, or requires space to organize and maintain materials, they may not have the tools. We must take these environmental realities into account when designing and building educational software that will meet the needs of students from all walks of life.
Long hours don’t work.
I recently realized that the people I meet with after 4pm aren’t getting the same creativity and deep listening as people that talk to me at 9 or 10am. It made me wonder why we are asking students to do a second or often third shift, when the research on the harms of long hours to productivity of overwork are so clear (here’s a summary of the harms) and similarly there are real harms to work quality (see this study on long medical shifts). Do you want someone in their 18th hour doing brain surgery on you?
When and what to assign?
So, even IF students have the time, background knowledge, and tools, does it really make sense to ask them to work a second shift? Students do need time to grapple with hard problems, and many students need quiet to work. So it isn’t an easy problem to fix. The article suggests that if you are assigning homework in K12, you should ask yourself these questions.
“Does the task sit low on Bloom’s Taxonomy? In other words, are students likely to be able to do it independently?
If not, does the task build primarily on work already performed or begun in class? In other words, have students already had sufficient opportunity to dig deep into the task and work through their difficulties in the presence of peers and/or the teacher?
Does the task require only the technology to which all students have sufficient access outside of school?
Can the task reasonably be accomplished, alongside homework from other classes, by students whose home life includes part-time work, significant household responsibilities, or a heightened level of anxiety at home?” https://modernlearners.com/homework-is-a-social-justice-issue/
How could ed-tech help?
Homework systems and courseware could make it easy and safe for students to provide feedback on their assignments, including individual questions and tasks within their assignments. Rather than focusing so much on giving analytics about students, ed-tech could provide instructors with analytics about the assignments, questions, and tasks they give. Which ones seem to require a lot of prerequisite knowledge that students don’t already have? Which ones seem to help students do well in the course? Which questions behave like “weed-out” questions? Maybe ed-tech should find ways to collect demographic information and measure outcomes to report on inequitable results, while protecting student privacy.
I am interested in hearing your ideas, too.
See you earlier tomorrow! And by the way, I have started making sure that the people that I mostly speak to later in the day occasionally meet with me at an earlier time, so that they get the benefit of my full listening capacity and creative potential.
I wasn’t expecting to learn anything related to product management and software development in a book about how we age and care for aging family, but I did. I have just finished reading Being Mortal by Atul Gawande, who also wrote and conducted the research and transformational changes in The Checklist Manifesto. (Image credit: Public domain: https://commons.wikimedia.org/wiki/File:Stethoscope-2.png)
From doctor-knows-best to patient-knows-best. Gawande talks about the changing role of doctors over time. In our grandparent’s era, ‘doctors knew best’. That was the age of the authoritarian doctor who made the decisions and was trusted to do so. Now, in contrast, for the most part, doctors are considered technical experts who can share information, but decisions ultimately rest with the patient. The idea is that the patient knows best, when given all the facts. However, when patients face important crossroads in their treatment and there are many uncertainties, neither approach works well and both lead to escalating interventions and, often, miserable people.
Both lead to suffering. The authoritarian path didn’t work well for patients because it didn’t take the patient’s fears and hopes into account at all. Without the patient’s preferences, doctors recommend actions within their own sphere of expertise. Surgeons recommend surgery rather than hospice because surgery is what they know best. But Gawande, who was trained in the current technical-expert-sharing-information model of doctoring, illustrates how information sharing goes just as wrong when it comes to delivering the experience that patients would want. He tells several stories from his own practice, where patients clearly said, I don’t want to suffer, and I don’t want pointless heroics, but then choose to proceed through many, many rounds of painful procedures with very low probability of success. Why is that?
Software development has the same duality. In software development, we also have this same duality. The authoritarian model: Which employee is the ‘owner’ of this product? They should make all the decisions about what to develop, and be responsible for the consequences. Or, alternatively, the ‘Information’ model; let’s have the expert (product manager) gather the facts and present choices to leaders and other stakeholders; or lets develop objective metrics to guide us. And similarly, it can feel like we see-saw between decisions made with too little information and decisions that feel like the information was there, but it was never pulled together into the right decision. So I was very interested in why neither approach is working for doctors and patients, and what might be a better approach.
Why the informed patient model still fails. Gawande’s analysis of the informed patient that still makes the wrong decisions is that they don’t have the experience or the medical model to make the decision, even when they have all the facts. So, assuming you aren’t an astronaut or experienced physicist, think about it this way. If I put you in a space capsule, ask you where you want to go (which is what the doctors-know-best doctors forgot to do), and I tell you a bunch of readouts and their percentage likelihood of being correct, and then ask you whether to launch, you still aren’t going to be able to make a good decision, because you don’t have a model in your head about how all those measurements add up. Gawande specifically talks about how a patient might be imagining that a particular procedure with a high likelihood of success could extend their life by years, when in reality it is likely to be weeks, not years. The patient doesn’t have the experience to put all the information together into a coherent model and make a good choice.
So now what? So, is there a middle ground? Gawande describes a model where doctors gather even MORE information about what a patient WANTS by using four questions that come from the world of hospice. Then, the doctor combines the patient’s answers with their professional experience to guide patients in making decisions that are consistent with the patient’s own desires.
Learning from hospice nurses. The four questions are also interesting. 1. What do you understand about your situation? 2. What do you fear? 3. What do you hope for? 4. What trade offs are you willing and not willing to make?
Ask, tell, or guide? A middle path to product development. In the world of software development, many organizations (including the one I work for) hire Product Managers to lead product development. In specific, Product Managers are responsible for deciding what features should be added to a product and with what priority. So the question is “Are Product Managers owners (the authoritarian model), expert consultants (the information sharing model), or expert guides (the new model Gawande proposes)?”
I would posit that the same insight Gawande has about doctoring is the right insight for product development. Product Managers don’t own their product. The product isn’t FOR them and there are too many critical stakeholders for them to be owners. But they also can’t present information and expect decisions from business leadership, precisely because the business leaders don’t have the full context and understanding of the detailed workings of the product and market. The product managers DO have that context.
My key insight from Being Mortal is those four questions that hospice nurses taught doctor’s to use to help them guide their patients. I am curious about whether those questions can be adapted to gather the right information, especially from business leadership and organizational stakeholders that don’t directly interact with the product, to allow Product Managers to wisely incorporate their requirements into good decisions.
So here are the four questions again
What do you understand about your situation?
What do you fear?
What do you hope for?
What trade offs are you willing and not willing to make?
Frankly, they almost work as is. I would only change the phrase ‘your situation’ in the first one to match the context. It could be ‘what do you understand about our goals’, ‘what do you understand about our revenue position’, ‘what do you understand about our strategy for …’
I am going to give these a try. Let me know if you do too!
One of the biggest privileges of leadership is building on the brilliance and creativity of others. What I can do on my own is small compared to what I can do as part of a team. And, hopefully, what I have learned over the years helps the ambitious, creative, brilliant people that work with me achieve meaningful goals. It is definitely a messy business because people are messy, precisely because of the unique talents and perspectives we all bring. The following are not exclusively my ideas, but I have tested and tested and tested them over again, and they have proven their value. Where possible, I will tell you what sources I based these strategies on.
Some meetings are key. You have to meet with people one on one every week for at least 30 minutes.
Why one on one? Because when something is uncomfortable or going wrong it either won’t come out in a group meeting or will come out sideways and create the additional need for understanding and repair with a lot more people.
Why once a week? Because if the frequency is less than that, the vacations, travel, and illness that occasionally derail these meetings create breaks that can span three to four weeks and a month is definitely too long for a problem to fester.
Why 30 minutes? It takes 30 minutes to talk about a complicated subject. I actually have found that if I meet with someone about projects AND people (including themself), I schedule 45 minutes minimum because the complicated subject often comes up after some simpler things get discussed.
The power of “What is up with that?” I learned this respectful strategy for recovering from failures from The 7 Habits of Highly Effective People by Steven Covey and the wonderful parenting book how-to-talk-so-kids-will-listen-and-listen-so-kids-will-talk by Adele Faber. The basic idea is that, when you think something has gone wrong, the most important factor in resolving the problem is understanding it.
The first step is to describe the problem non-judgementally. So, for example, the non-judgemental description part might be “I noticed that we aren’t going to deliver feature-x by time-y“ or “I noticed that we had an outage yesterday,” or “People looked tense in meeting z,” or “We collected this data, and I thought it was pointing us toward doing x, but then we did y.”
Then you ask “What is up with that?” to the person most likely to be responsible and/or have critical information. (For non American English speakers, you can try “What happened with that”? Or “What is going on with that?”)
As a leader or manager (or team mate) it is your responsibility to discuss any setbacks your team faces, but no one is perfect at handling these conversations. This technique works for anyone, but it is particularly useful for both under and over-reactors. For those of you who might prefer to avoid conflicts, it gives you a way to discuss something in a simple, factual, non-confrontational way. It also works for those who tend to jump to conclusions and overreact, which could intimidate the receiver of the message, by instead giving the receiver space and respect to respond.
The key to this technique is not to overload either question with whatever stories you might be telling yourself about why or who is to blame. Leaving those stories out preserves trust, maintains a team atmosphere, and keeps the person you are asking on your side and un-defensive. The form of the question is important because it is neutral and open to the information the person you are asking has. You will be surprised what you learn. From a heart-felt “I screwed up and here is how I am fixing it” to “Oh, because we got an opportunity for even better feature la-di-da” to “We didn’t have this important thing we need. Can we work together to figure out how to get that?” It takes a ton of practice, but the good part of this is that the more you do it, the more you trust that you really do have colleagues working with you and not against you.
Kathi Fletcher 
