Moms Are People, Too

One of the most frustrating aspects of working as a mom in tech is working with team members who don’t understand that I sometimes have family obligations.

Not all women in tech have families, and I’m certainly not here to begrudge those who don’t, nor belittle those who are consciously choosing not to (in fact, I applaud you).

Many, many men in tech have families and family responsibilities that often surpass mine.

In my experience as a technical project manager, though, it seems that the majority (but not all) of my dev team members fall into three family-related categories:

  1. Dudes with grown kids who are teenagers, in college, or otherwise self-sufficient.
  2. Dudes with no kids who have partners who either work similarly demanding jobs and/or have gotten used to the uncertainties that come with dating, marrying, or partnering with someone in tech.
  3. Dudes who have kids but have a partner or other family member who is able to address the needs of the kids when the dude needs to address a work issue.

These dudes are (in general) easier to get in touch with and more able to spring into action when the servers go down at 10 pm over the weekend.

I’m not a dev, I’m a project manager, and most of the urgent situations do not require my problem-solving prowess, but my people-rallying, meeting scheduling, and communication skills.

I’m also a single mom with two kids, ages 6 and 8.

I’m not asking for sympathy.

I’m not asking for “special accommodations.”

I’m simply asking for understanding.

Before it’s said:
Yes, I knew what I was getting into. I chose to have kids. I chose to work in tech.

But I did not choose, and cannot choose, to put urgent and unexpected tech needs above the equally urgent and often unexpected needs of my family.

This means that when you need a PM to set up a conference call on a Sunday evening, I may be away from my machine, or not checking my work email, or not responding to texts, as I’m helping my kids to remember to brush their teeth and giving out hugs before bedtime.

While I’m doing this, I may not respond immediately. Trust me, had I known a meeting was needed in advance, I would have made accommodations.

This also means that during 7 am deployment calls, I’ll need to be on mute occasionally as I rouse the kids, again remind them to brush their teeth, find something for my daughter to wear that doesn’t offend her sensibilities, make two lunches, locate the lunch boxes, and put the kids on the bus.

During this time I will be temporarily away from my computer, unable to screen share while the team updates stories on the agile board.

My time on mute, my slightly delayed responses, and my temporary time away from my computer are not a reflection on my dedication to my job, my role, or my clients.

I’m simply doing my first job: Being a mom.

And sometimes, this has to come first.

Thanks for understanding.

Your intrepid project manager,
Kate

PS: This is a commentary on moms in tech, but the larger conversation of why our tech jobs are unpredictable and so disruptive to “life” is subject for another post.

I’m interested in that, too.

This article was originally posted on Medium on November 24, 2014.

I Wish It Were This Easy.

In the interest of continuing a fair and balanced dialog about what I think is a very serious issue, I feel compelled to write a response to “How Bad UX Killed Jenny.”

TL;DR: Fixing the bad UX that can potentially kill people — and already has — is going to be a very difficult task.

But that doesn’t mean it isn’t time to start.

When I read Jonathan Shariat’s article this morning, I experienced what can only be expressed, in a classic Twitter-in-cheek way, as ALL THE FEELINGS.

I had ALL THE FEELINGS for several reasons:

    • I worked at the Oncology Nursing Society for 12 years. I started out there as a copy editor and eventually ran software projects.
    • The article directly links oncology nurses struggling with a complicated user interface to the death of a patient.
    • ONS offers a Chemotherapy Certificate course that helps ensure oncology nurses who administer chemo are trained, certified, and prepared to handle not only the drugs, but also the emotional side-effects of living with cancer and undergoing cancer treatment. Chemo nurses who work in many hospitals and out-patient clinics are required to take this course.
    • The nurses referenced in the article may be people I know, or have met at a conference over the years. Regardless of the personal connection, I know nurses like them. I have hugged them. And I understand them.

Shariat’s article is deservedly successful for several reasons. For one, it has a great title, and even if I wasn’t passionate about UX and healthcare, I would have read it. In addition, it gets the conversation started. And that’s what we all need.

I see the solutions, however, as more nuanced.

Industries that could use the help of talented designers and developers — and my list of these is growing, from insurance companies to school districts to departments of motor vehicles — need help understanding why our work is so dearly needed. Leaders in these organizations have to understand the need, and place importance on it.

My struggle with the recommendations to do something — and I do appreciate the call to action — is that we need to do more than apply for jobs at these organizations and speak up. We need to find a way to influence and inspire the leaders who run them.

Because without that, and without the support from the top, it’s sadly too easy for talented, passionate people — people who care so deeply about a company’s mission that they will work nights and weekends to make it happen —to get very burned out.

It happened to me and it is happening to others.

Please get those jobs. Please redesign things. Please start it up and speak out.

Go to UX Conferences. But take your boss with you.

Hold a lunch event and watch Jared Spool speak. Invite the CIO.

Design a great site. And then find ways to measure — preferably in dollars — how this new design can positively influence the “bottom line.”

Test that great new site with real users. And ask the CEO to watch the session.

Because our designs can’t do it alone. And neither can we.

We need support and buy-in from everyone in the C-suite, everyone who signs the checks, develops the strategic plan, and sets the priorities.

This will be the hard part, but it’s the most necessary part.

Your great designs will come, and then — and only then — will they be able to make the difference we all need them to.

Thanks for getting the conversation started.

I love you all.

Unless.

Unless

Three weeks ago, I tendered my resignation at the company where I’d worked for twelve years. I spent nearly a third of my life there. When asked if I’d considered “not going out with a bang,” the answer was no; but my bang wasn’t in any way destructive.Driving in on my last morning, I found the right way to say goodbye. Below is my farewell letter to staff.

As I cleaned out my desk this week, sorting through twelve years of creativity, project plans, pencil-drawn wireframes, and printed-out emails scribbled with ideas, I had a chance to reflect on my time here. I’ve been given many opportunities to influence the course of the organization, and for that, I’m very thankful.

I’m thankful for A., who hired me, and who listened when I brought up the idea of making our employee newsletter into a website. I’m thankful to K., who gave me a server to host it on, despite her puzzled look when a copy editor came and asked for this. These events changed the course of my career here, and as time would tell, the course of my life.Over the years, I’ve been told that I care too much. Thing is, I can’t stop caring. I can’t stop caring about an organization like ours.With that, I’d like to leave you with a few thoughts.

Always fight for quality.
Anything less doesn’t count. Remember that everything we do, everything we say, and everything we put out on the Internet is competing against posts on Facebook, funny stuff on Twitter, and emails from Target, ASAE, ASCO, and everyone else for our customers’ attention and time. Make it good. Make it as good as possible.

Admit your mistakes.
We all mess up. We’re supposed to. And we’re supposed to learn from those mistakes, have a laugh, and move on. If you mess up, admit it. Fix it. Learn from it. I’ve had some epic fails during these twelve years, and each time I’ve spoken up, admitted my mistake, and moved on. If this is scary, it shouldn’t be — it’s liberating. I don’t hide the fact that I have a strict intolerance for errors, but I’m sure this letter has a copy edit or two that I’ll notice later, maybe tomorrow. But I’m human just like the rest of us, and it’s OK.

Listen to each other.
Don’t discredit the voice of reason simply because it speaks with emotion. If you’re in a meeting with someone who seems upset, there’s likely a reason. Chances are this person is feeling something that she or he is afraid to say; seeing something in a different way, despite what the group is discussing; or wanting to contribute but can’t find the words. Talk to this person and listen. Find out why. Because the people who show emotion are the ones whose personal goals align with the goals of the company. They care, and they have a passion for what we do.

Take it personally.
We all should. Yes, it’s “just a job,” but it’s a job we should all care about. To quote Erin Brockovich (Soderbergh, 2000):

Ed Masry: PG&E is demanding 90. In other words, everybody. Do you understand? This is serious.

Erin Brockovich: And what, Ed? I’m not serious?

Ed: You’re emotional; you’re erratic. You say anything, you make this personal, and it isn’t.

Erin: Not personal? That is my work! My sweat! My time away from my kids! If that’s not personal, I don’t know what is.

Remember that the work we do touches the lives of oncology nurses. These brave men and women hold the hands of mothers, brothers, dads, sisters, and kids during the most difficult times of their lives — and often, at the end of their lives. Remember that our organization helps nurses, doctors, and patients, and the work you do every day touches them in some way. Remember this, and do the best work possible.

By the time many of you read this, my account will be disabled, my years of service plaque will be removed, and my work here will just be a memory. Please keep in touch.

If you’d like to say hi, you can email me. I’m also on Facebook, Twitter, Instagram, Polar, SoundCloud, Vine, and whatever other social network crops up that seems cool and offers something new and lets me log in with an existing account.

I also have a personal website, kateda.ly. It’s responsive, so it’ll work on the mobile device of your choice, but the desktop version works nicely as well.

Goodbye, and good luck.
Kate

References

Dr. Seuss. (1971). The Lorax. New York: Random House.

Soderbergh, S. (Director). (2000). Erin Brockovich [Film]. Beverly Hills, CA: Jersey Films.

Support oncology nurses with a gift to the ONS Foundation.

This essay was originally posted on Medium on November 27, 2013, and has been backdated accordingly.

How HealthCare.gov Can Help Save Software Development

St. Isidore

St. Isidore of Seville, Patron Saint of the Internet

A tale of martyrdom

Since early October, it’s become much easier to determine where people fall on the political spectrum.

If they refer to the health insurance exchange website as the “Obamacare” site, they’re a conservative. If they refer to it as “HealthCare.gov,” they’re a liberal.

If they call it “not surprising,” they likely work in software development.

When the stories started to surface, I was in Boston, MA, attending UIE’s User Interface 18 conference. A few of us joked about the irony of being at a UI conference when the president was on TV talking about an “unusable” website.

Being a software project manager, I could picture how things went down and started to feel for the managers and devs who were in the middle of it.

At Boston’s famous Quincy Market, my buddy and I sat down at a communal table with some kind-looking older folks. After learning we were in town for a “website convention,” our new friends shook their heads.

“It’s a shame,” the gentleman said, “we have a nephew who works with websites. He says it’s really hard to get anything done. It’s no wonder this HealthCare.gov site is a mess, too.”

Knowing I could trust them, I shared my thoughts.

“Somewhere in DC is a project manager who saw it all coming, and hopefully, she went to her boss. Chances are she was told to go back to her desk and keep working. She’s likely losing her job right now. But at least she raised her voice.”

Unfortunately, she probably said things that nobody wanted to hear.

~~~

Failed software projects don’t just happen.

Failed software projects are a sprawling network of tributaries, with switchbacks and rocks and an occasional small waterfall. These lead into streams, then rivers, and eventually to an ocean of mismatched data types, trimmed zeros, and botched customer records, washing up on a beach littered with Mountain Dew cans.

Then everybody stands around a boardroom table and wonders what went wrong.

~~~

“It’s a management problem.”

As a software PM, I resented this statement. How could it be my fault if my devs don’t do their work? How is this a management problem when I’m such a good manager?

It wasn’t until I’d lived through a failed project or two that I realized the “management problem” everyone’s talking about isn’t our inability to make estimates, keep abreast of development, or keep an eye on the budget.

It’s often a fear of re-planning.

Re-planning is everywhere. How many times do you go to the store and only buy the items on your list (if you made a list at all)? How often does a dinner party go as planned? And, with kids in tow, how many times do you leave for vacation, school, or grandma’s house at the exact second you’d hoped to?

We humans naturally re-plan and revise every minute of our lives (this sentence brought to you by over 20 seconds of back-spacing).

But when it comes to software projects — especially large-scale and well-documented ones — there’s sometimes a fear of re-planning.

Because to many people, this feels like admitting a mistake.

I’m not claiming to have any insight into the planning of HealthCare.gov or to have a clue about what should have been re-planned. Yet, all the risk assessment matrices in the world won’t do you any good if everyone involved isn’t aware of them — or isn’t cool with changing things up if needed.

If re-planning isn’t discussed up front so that everyone understands, you’ll have some people — most dangerously, managers and higher-ups — who are afraid of it. Bottom line: Be cool with re-planning. It’s gonna happen.

~~~

“But we totally had a process.”

“So, are you guys straight-up agile, or agile with some waterfall, or strict waterfall, or what?”

Years of conducting developer interviews has me anticipating this question and trying to come up with an answer. Regardless of what your answer is, everyone has some kind of process.

For a while now, many companies have been “going agile,” mostly out of a desperate attempt to get people talking. Scrum and other agile methodologies seem like a perfect silver bullet for all the development teams out there that can’t seem to get anything done.

The world is filled with countless managers — including myself — who have thanked the Gods of Backlog for bestowing us with the amazing boon of the Daily Scrum.

It all seems so simple, right? Just look at the amazing benefits!

Requirements written in language that stakeholders can understand!

Daily meetings where we can actually discuss progress and impediments!

Time-boxed development cycles!

Not convinced? Wait, there’s more!

Retrospectives— postmortems!—where we can talk about everything that went wrong and then fix it!

Just call the number on the bottom of your screen to have this life-changing software development process delivered right to your door for the low low price of solid requirements plus tax, paid in easy, two-week installments.

Ok, enough silliness. Agile can be great — lots of very successful companies use it to pump out some really cool stuff — but agile for the sake of agile, or process for the sake of process, isn’t gonna cut it.

I’ve talked to folks who have worked on teams that keep moving ahead with sprints despite a need to stop, assess what’s going on, and re-plan.

“We kept getting behind and rolling stuff over to the next sprint,” they said. “But we had to have another sprint planning meeting the next day, so there wasn’t any time to figure out why this was happening.”

Teams sometimes keep using a process because they’re afraid not to have a process — they keep having daily stand-ups even though everyone says the same thing every day—and rush through those once-promising retrospectives because everyone’s too nice to say what went wrong and it’s time to start planning the next sprint.

I have no idea whether the teams working on the HealthCare.gov site were or weren’t agile, but I’m guessing their work had at least some of these elements. And when you keep using the process because it’s the process and you need to use the process, it’s easy to lose sight of what you’re actually doing.

~~~

“Software isn’t complicated. People, on the other hand…”

I was once talking to a woman whose development staff served in a staff augmentation role for clients. For one client, they’d gone through four PMs in one year and were about to introduce a fifth. The client was obviously skeptical.

“We hired these dudes coming right off of their PMPs,” she’d said.

But as soon as they talked to developers, they only heard the teacher from Charlie Brown.

Now, I love developers. Some of my best friends are developers. But, the more I talk to folks in my industry, the more I learn that this is unique.

I imagine that most PM-developer conversations go something like this:

PM: Hey man, how’s it going?
Dev: (Removes earbud) It’s going.
PM: So it’s all good?
Dev: Yeah bro, it’s all good.

Then the PM walks away and tells his managers that yep, everything’s on schedule, everything’s “all good.”

Chances are, though, that even if my mythical dev’s work is “all good,” what about the other guy? What about the dude writing the API? Or the new chick in the design department? How’s her stuff coming?

If PMs don’t actually talk to devs and ask real questions about what they’re working on, or don’t have someone else who can do this for them, “all good” can quickly turn into “total bullshit.”

And even if it’s not BS, “all good” might actually mean that:

A) the dev is totally going to pull an all-nighter to get this shit done
B) his work is “all good” but who knows about the other guy
C) both A and B
D) neither A nor B.

I’m not saying that all PMs should be devs in a former life. Hell, I’m an copy editor-cum-manager, and some of the best project managers I know couldn’t SELECT * themselves out of a paper bag. But they know what SELECT * does; they have a general idea of why you shouldn’t always use it; and they can talk the talk enough to be taken seriously.

It also helps to have a nose for BS and a good sense of humor. And when you’re talking to developers about estimates, it’s always a good idea to ask them how long they think it’ll take the team to do it, not how long it’ll takethe dev to do it.

(Believe me. I have a formula: dev estimate x 6 = real estimate. It’s pretty accurate, and takes into account communication, testing, deployment, confirmation, and things I forgot [TIF]. Give it a try and let me know what you think.)

~~~

“It just takes a lot of ‘giving a shit.’”
— J. Endler, musician, developer

Some people, at times myself included, are surprised that any software products work at all.

Truth is, a lot of them don’t, but most of them work well enough for us to keep our jobs.

It doesn’t have to be this way. Engineers — just like we say we are — have built bridges, nuclear reactors, and that giant-ass building in Dubai.

We put people on the freaking moon. So what’s the difference? Physicality? Maybe, as we can’t actually “touch” the API that runs our Google maps.

I think it’s more about risk. Say the bridge you’re building can’t hold trucks. What happens? People die.

If that hotel in Dubai has an elevator that’s designed incorrectly, people die. If your lunar lander can’t make it back to earth, people die.

Houston? Here’s the problem.

We all know that complex computer programs are running systems critical to public safety, and their failures can, and sadly do, result in death (think: Toyota break recalls).

But for the vast majority of people writing software, nobody’s gonna die. Nobody’s gonna die if your datatype is wrong. A few records might get botched, but nothing huge. Nobody’s gonna die if your site takes over 10 milliseconds to load.

And as another designer friend once said, “Nobody dies if I choose the wrong blue.”

Since no one’s gonna die, and more often than not, no one’s gonna get fired, what’s our incentive? Good companies know that good software sells products and builds customer loyalty.

But lots and lots of companies are putting out software because they need to get something on the web — and if it pisses you off, well, sorry, bro.

This is where it helps to “give a shit.”

In our high-paying, low-stakes world, all we have to do is give a shit. We have to give a shit from top to bottom, from CIO all the way to the guy who pushes the button to run the automated tests. Because even if what we’re doing isn’t going to kill anyone, we should care about it. We should want to do good work. We should all want lighter sites and clean code and better user experiences.

It’s our duty to hold our peers accountable for this, for our managers to hold each other accountable, and for the people above them to do it, too. But what do we even have to say?

“Hey dude, I hope you care?”

Which brings me to our martyrs.

For the first time in my professional life, and maybe for the first time since “the modern web,” we have an epic fail to talk about. A Hindenburg. An Apollo 1. And as much as it grieves me to say, a Challenger disaster.

On HealthCare.gov, something went wrong. Somebody messed up.

Or, a lot of somebodies messed up. Maybe a lot of somebodies were messing up, and nobody thought it was a big deal or had any clue as to what a big deal it was going to be.

These somebodies have given us a gift. They have given us the words we need to talk to our bosses, and our boss’s bosses: a cautionary tale.

And even if our companies aren’t anything like the federal government and our projects are only a tenth of the scale of HealthCare.gov, messing up and failing to re-plan, use a good process, talk to people, and give a shit will cost our companies money, and someday, maybe our jobs.

We don’t want that. We can’t let it happen.

To the PM I believe is out there: thank you for your sacrifice and for giving us what we needed.

I promise not to go forth in vain.

~~~

Special thanks Nick BialaszewskiBrandon MillerJason GodeskyKris Graham, and Justin Endler, all of whom totally give a shit.

Saint Isidore of Seville image via http://en.gloria.tv/.

 

This essay was originally posted on Medium on November 1, 2013, and has been backdated accordingly.