why your conference should have a code of conduct

I’ve been asked many times why a conference needs a code of conduct.  Depending on who’s asking, and whether I feel like taking on such basic education for a conference organizer, I give many answers: to increase attendance of women, to have a documented procedure of how to handle a situation, to do the right thing.

There have been many articles written about the problem of harassment at conferences.  The most recent to cross my radar quotes Leigh Honeywell:

“I’ve had enough crappy experiences at security conferences that I no longer attend them alone,” said Leigh Honeywell, a security engineer.

And that, conference organizers, is why you should have a code of conduct.  When people have bad experiences at your conference, they stop attending it.  When women have bad experiences at your conference, they stop attending it if they can’t come up with a way to guarantee their safety.  And when we have bad experiences at your conference, we talk about it.  I’ve avoided attending conferences because I’ve heard about bad behavior that goes unchecked.

If you don’t have a code of conduct that you enforce, you’re losing attendees.  It’s in the best interest of your conference, including best financial interest, to have a code of conduct.

the patient experience of in-patient versus out-patient hospital stays

I’ve spent most of the past year learning about access to healthcare and thinking about how we might improve the patient experience so that patients have better outcomes. It’s become increasingly clear to me that the healthcare system places a high burden on patients, and it is the patient who suffers when healthcare lets them down.

Take this article in the New York Times, New Medicare Law to Notify Patients of Loophole in Nursing Home Coverage. The article explains one of the many things that is all but impossible for patients to understand about healthcare: the difference between in-patient care and out-patient care. Most people think that in-patient care means staying overnight. Not so: there are many ways to stay overnight in a hospital, wearing a hospital gown and sleeping in a hospital bed, where you are not actually an in-patient. The Times article describes being under observation, which can technically be done as an out-patient and still have the patient in the hospital for many days.

The real problem here is the disconnect between what it means to be an in-patient versus out-patient. For the patient themselves, they rarely know if they are in- or out-. They only know that they are at the hospital, and that something is wrong enough for them to stay overnight. Patients have no idea about the strange intracacies of in-patient versus out-patient. To the patient, there is no observable difference between the two. They only find out later when the bill arrives.

Instead of fixing the underlying problem, this change is instead adding to the burden on the patient. Patients now have to be notified if they have stayed more than 24 hours as an out-patient under observation, they could have significant out-of-pocket costs for their treatment. Not only is the patient sick enough to require in-hospital observation in the professional opinion of a doctor, now the patient also has to worry about how all of this is billed. They have to know the difference between in-patient and out-patient. They have to find someone who knows whether the medical billing will be coded as in-patient or out-patient,. And they have to do it at a time when they are particularly ill-equipped to think about such matters.

It’s hard to be a patient. Let’s not add to the burden of being sick, and needing medical treatment, by also expecting patients to make decisions about their medical treatment based on arcane medical billing.

the state of the independent developer

I’ve been shipping software in various roles since I was an undergraduate student in 1997.  I’ve done tech support, technical writing, software development, and user experience in the intervening years.  I’ve shipped code in at least 8 languages, including Smalltalk and VAX assembler.  I’ve contributed to and helped organize several tech conferences, ranging from programming languages to women in tech.

Although I had been a Mac user for some time, I officially became a part of the Mac developer community in 2005 when I joined Microsoft to work on Office:Mac.  I was excited to join that team.  Not only did I finally get to work on Mac applications (and with people who had been doing Apple development for 20+ years!), I was part of a vibrant community.  I attended MWSF first as an engineer, and later as a speaker.  I met many people who have long since crossed the line from fellow developer to friend.

I was a part of the community for the transition from PowerPC to Intel and the corresponding transition from CodeWarrior to Xcode.  I was part of the community when the iPhone was announced.  I was a part of the community when iOS really took off, and when being able to attend WWDC was not just a matter of getting employer approval but also the luck of a draw to get one of the relatively scant handful of available tickets.

When I started working on Office:Mac, I observed that there weren’t a lot of large Mac development shops outside of Apple.  There was the Office:Mac team of ~250 at the time, and Adobe too, although I didn’t have a good estimate of how many Mac developers they had.  Then there were smaller teams, like Quicken for Mac, VMware Fusion, and The OmniGroup.  And then there were a lot of very small shops and single developers releasing great products.  One of the challenges that the Office:Mac team had when I was there was the dearth of software engineers who had both Mac development experience and very large codebase development experience.

Both the platform and the development community have evolved, resulting in significant impacts to independent developers.  As is obvious from the near-impossibility of getting WWDC tickets since it first sold out in 2008, the Apple developer community has seen an unprecedented influx.  Companies large and small have added iOS developers.  Independent developers have flocked to the platform.

A major point of change has been the App Store, first for iOS and then for Mac.  The proliferation of apps has made app differentiation difficult for developers, whether they are a large company or an independent developer with a great idea.  To attempt to gain users, not only has there been a proliferation of apps, but those apps are  likely to be free.

Free apps are, of course, not free.  Apps require developers, and developers have bills and a desire to keep paying those bills.  For a large company, the cost of developing a free or inexpensive iOS app is often absorbed in the costs of developing other products that are well-funded and that the iOS application supports.  The App Store has evolved other methods for developers to make a living, including advertisements and in-app purchases.

Which leads us to the state of the independent developer.  It was possible to be an independent developer and make a decent living at it.  Some developers, through a combination of skill and luck, found themselves doing more than just making a decent living.  As the price tag of applications has trended towards zero, it’s been ever-harder for an independent developer to be only an independent developer.  A good idea for an app, the skill to develop a great app, and a sprinkling of luck is no longer sufficient to make a decent living.

Independent developers often have to diversify their income. They might have to keep their day job and work on their app on evenings and weekends.  They might have to become writers or podcasters to ensure that they have sufficient income.  They might become developers in a corporate environment, taking advantage of all of the iOS developer opportunities that are available now.

I was overjoyed to see Samantha Bielefeld‘s take on the state of independent developers as she considered Marco Arment‘s move to make his iOS app Overcast available for free with an optional patronage model.  Her point that he is able to try this as a result of his unique position in the community and his other income streams is one that resonated with me.  If a well-known and well-regarded developer isn’t reaching an audience with a well-designed and inexpensive iOS app and thus chooses to make it free, what about everyone else?

It’s distressing to see a well-known independent developer seemingly throw in the towel on independent development.  It’s doubly distressing when that independent developer doesn’t seem to understand that the model of patronage isn’t necessarily one that will work for independent developers at all, let alone ones who don’t have thousands of Twitter followers or close friendships with well-placed members of the tech press.

What is the state of our community?  Are our options limited to either working for a big company or hoping that ad revenue continues to limp along?  How do we have a vibrant community of world-class apps and developers creating those apps if our users have become conditioned to free apps?

These are important questions for us.  Attacking Bielefeld for asking important questions is the wrong thing to do.  For all of us, whether we’re in big companies or independent developers, we have to consider our place in the community and how we’re supporting both ourselves and the long-term success of the community.  I’m hard-pressed to see how this constant drive to zero is going to ensure our long-term success.  We must stop shying away from important and difficult questions, and we must stop attacking anyone who questions this status quo.

the hallway track

On the first day of MacIT, it’s traditional for the members of the advisory board to say what they’re looking forward to.  Arek Dreyer went first, and he cited the hallway track as the thing that he’s most looking forward to.  He’s right: even at a conference with the most amazing content, the hallway track is often one of the most useful tracks at a conference1.  It’s a huge miss when conference organizers forget about the importance of the hallway track.

This afternoon, I got to be a part of the hallway track in action.  I was talking to another member of the advisory board and one of the MacIT speakers.  Someone came up to us, and asked what we knew about network security.  She referenced a question that she had asked during the security talk this morning.  None of us are network experts, nor are we security experts, but we’ve all picked up bits and pieces over the years.  She explained her situation as we looked at her error logs.

We came up with a plan of attack, both short-term to address the issue that she found, and long-term to address the likely root cause of the problem.  We talked about how to figure out what levers to pull within her organization to make it possible to do the long-term fixes.  We shared our own war stories about our own experiences with issues and figuring out exactly what dance is needed to get something done.  And we reassured her: yes, she really did have an issue, and yes, her issue is resolvable.

This is why I love the hallway track.  None of us had the complete answer.  Together, we were able to talk through her problem, brainstorm ideas for how to address it, and come up with what felt like the right way to address it in her environment with her team.  We worked together, came up with some potential solutions, and identified more resources that she can use back home when she doesn’t conveniently run into people in the hallway.  We all learned something in the process, and we helped out a member of our community.

That is the power of the hallway track.

  1. Now that I think about it, possibly most especially at a conference with the most amazing content.  Great content creates another opportunity for great hallway conversations

healthcare is more than the clinical experience

As I’ve been working at Genentech, one thing that has quickly become apparent to me is that healthcare is far more than the clinical experience.  That clinical experience, between me and my doctor or maybe me and a x-ray tech or something like that, is only one of the pieces of healthcare.  There are many aspects that are just as important as the clinical experience.

In “How hospitals hope to boost ratings on Yelp, HealthGrades, ZocDoc and Vitals”, the Washington Post says this:

When patients are asked to rate how doctor quality should be measured, clinical outcomes, such as getting cured of a disease, rarely come up, said Lisa Suennen, who advises health-care companies. Patients talk about whether a doctor or nurse was kind to them, or whether their experience was fast and convenient. It’s assumed that the doctor is going to treat their illness or condition.

The clinical experience is necessary, but not sufficient, to have a good healthcare experience.  The user experience of healthcare includes the clinical experience, as well as the ease of getting an appointment, the wait time before your appointment, how test results and next steps are communicated with you, whether your doctor follows up with you.

Perhaps this is a reflection of Genentech and its treatments, but I wonder if the last sentence is actually true.  Or maybe it’s true for lots of cases, and it stops being true when the diagnosis or treatment is difficult.  As a patient, it can be hard to assess clinical outcomes.  If I had a cold and now I don’t, how do I know if the clinical experience could have been better?  If I have a chronic condition, how do I assess whether I could have gotten a better clinical experience?  It’s easy to assess whether I feel like my doctor has listened to me, whether my doctor has treated me like a person and not a condition, whether my doctor is responsive to my concerns.

Healthcare is hard.  We have to remember that the clinical aspect is only one part of what makes healthcare hard.  We have to get the patient experience right.

you are not the user

In every role that I’ve had, I’ve had to remind myself and my team that we are not our users.  When you’re a software engineer creating a software application, it’s very easy to see yourself as the user.  It was true when I worked at IBM on databases, it was true when I worked at Microsoft on Office:Mac, and it was true when I worked at VMware on vSphere.

In each of those instances, while we as the application development team did use our applications in one way or another, we weren’t representative of our real users.  We had more knowledge of how computers and software work in general.  We had more knowledge of how our specific applications work, and many other related applications too.  We were far more likely to use our software deeply.  When I was at Microsoft, I learned that, as an organization, we sent and received significantly more email than other organizations of our size and general structure.  This meant that I couldn’t project from my usage of Outlook to other users.  I had more email, I had more folders, I had more events on my calendar, and I was far more likely to use deep features in that application.

I find myself having a similar conversation in healthcare user experience.  We are very patient-focused.  Being patient-focused is excellent.  We have a lot of empathy, which is also excellent.  In using the term “patient”, we can project ourselves into the situation — after all, we’ve all been patients at one time or another.  My doctor refers to me as her patient, even when I’m just in for a checkup.

But I am not the patient here.  When I project myself into the patient’s situation, it is easy to forget that I probably differ from the real patient.  I am a reasonably healthy and well-educated 39-year-old married woman in Silicon Valley.  Not only that, but I have also learned quite a lot about how healthcare works in the past few months.  Most patients don’t have the benefit of the knowledge that I have acquired.  And if I’m considering the user experience for the patient, they are probably not, or are no longer, a reasonably healthy person.

This point is very important.  Someone who is reasonably healthy is better able to make well-informed decisions.  We have a limited amount of cognitive resources available.  There are only so many decisions that we can make in a day.  That’s why habits are so powerful: a habit is (at least!) one fewer decision to make in a day.  If you always have a latte and a banana on your train ride to work1, you don’t have to expend cognitive resources thinking about what to have for breakfast that day, and thus you have more cognitive resources to use later in the day.  People who are in pain or who are stressed have fewer cognitive resources available to them than people who aren’t in pain or stressed.

In creating a healthcare user experience, I have to remember that our patients have probably had a life-altering diagnosis.  They could have had a long and difficult journey to get to that diagnosis.  They are probably tired, and in pain, and stressed.  They are already dealing with a difficult situation.  We have to create a healthcare user experience that doesn’t have an undue cost of cognitive resources at a time when the patient has few, if any, to spare.

  1. Yes, I have just described my morning commute.

the user experience of healthcare

I’ve worked for software companies for my professional life.  Coming to work in healthcare has been eye-opening for me.

The user experience is … well, let’s be generous.  Let’s call it “challenging”.  And it’s challenging for, as far as I can tell, everyone involved.

It’s challenging for the patients themselves.  Getting care is no simple matter.  There are decisions to be made, providers to find, waiting lists lurking.  There are healthcare and wellness apps which promise to help the patient in some way.

It’s challenging for healthcare providers.  We’ve seen an explosion in everything related to healthcare.  There is an ever-increasing amount of data.  Some of it is specific to a single visit with a patient, such as the results from blood work or an MRI.  All of this data, not to mention whatever notes are jotted down or diagnoses given or prescriptions filled, are aggregated into a patient’s healthcare record.  Any given patient likely has multiple of these health records, even if you only consider that a patient probably has a different health record with their primary care physician than they do with their dentist.  Keeping up with all of this data is difficult and time-consuming.

And that’s just the medical side of it.  We haven’t touched the administrative side of matters, which involves the patients, family members or other caregivers, the patient’s insurance company 1, administrators and office staff at the healthcare provider, and so much more.

All of this adds up to a bad user experience.  Some of the bad user experience is just annoying.  But, since we’re talking about healthcare, a bad user experience has risks far beyond annoyance.  A patient could choose to delay treatment because navigating the system just to get an appointment is too difficult and time-consuming.  A clinician could miss an important detail in the patient’s health record and prescribe the wrong treatment.  A data-entry clerk in the doctor’s office could make a typo that results in the patient’s insurance company rejecting the claim.

I’m sure you can imagine that I read “Why Health Care Tech Is Still So Bad” with much interest, and I agree with almost every word of it.  The only point that I disagree with is that it’s not enough for physicians to be unable to live without a given technology.  There are many technologies that physicians today can’t live without.  Whatever technology is part of getting the user experience of healthcare right has to make the whole process better for everyone, not just the physician.  If my doctor thinks the technology that gives her my health record is something that she can’t live without, that is almost useless to me if she refers me to another doctor who can’t access that health record.

There are too many moving parts in the system, too many stakeholders.  It’s not sufficient to get it right for just one of them.  We’ll probably get there in a piecemeal fashion, improving experiences for different sets of stakeholders at different points.  We can’t stop because we’ve gotten it right for the physician.  The user experience of healthcare goes far beyond the physician.

  1.  I’m being lazy here, there’s also public payers like Medicare or the Veterans’ Administration.

cultural shifts

I often get asked about the difference between my previous employers, all software companies, and my current employer, a biotechnology company.  There are so very many differences.  One that I feel every day is the knowledge that Genentech has very sensitive data.  As a result, we have strict corporate policies that cover a wide range of areas like physical devices and data retention.  I even have a separate corporate cell phone now.

It’s easy to see why we have such policies.  Consider this article from the Washington post about healthcare hacks.  It points out that some of the data loss has been from a stolen laptop or inappropriate disposal of paper records.  I thought I used to be nervous about losing my corporate laptop; the stakes are a lot higher now.  I was already the type who rarely printed anything out, and put anything that I did print straight into the confidential shredding bins once I was done with it.

I’m now even more careful with my devices and data.  I print less than I ever did.  I don’t even have a filing cabinet, which forces me to ensure that anything I do print is handled appropriately immediately.  My awareness of security, both physical and data, is so much higher now.  I’m also thinking more about the user experience of security and what we can do to engender better security practices.

“beyond the diagnosis”

In coming to Genentech and applying my user experience skills here, one of my first realizations was that a patient’s journey doesn’t begin with diagnosis, and it doesn’t end with the completion of treatment.  It begins with the early symptoms that the person might not even recognize immediately.  Getting to a diagnosis is not the start of the journey; instead, it’s one of the milestones.  For some patients, especially for many of the treatments that Genentech makes, their journey is a lifelong one.  For others, it ends not when treatment is completed, but when they have recovered and completed everything associated with their diagnosis and treatment.

We published an article called “Beyond the diagnosis” which explores a lot of these ideas.  I’m very happy to see others here who are thinking about the whole experience of being a patient.  This passage certainly resonates with a lot of the work that I have been doing in the past few months:

Sometimes the cause of a health problem is clear. Other times, it takes years to pinpoint what’s happening in a patient’s body. The uncertainty associated with noticing early symptoms but not understanding their causes can be as debilitating as a disease itself.

This article is a great way to think about what it means to be a patient, and what we in healthcare can do to improve the experience and the outcome for the patient.

a Macintosh girl in a Microsoft world

© 2010-2024 go ahead, mac my day All Rights Reserved