Saturday, January 06, 2024

The Technical Part is Never the Hardest Part

Adapted from a presentation at the University of California San Diego for IEEE in November 2023. 

Video of the talk can be found here: https://youtu.be/BhxrxITHB_o

When we think about technology and society, and how our technology should serve people, we often think of efficiency, entertainment, and productivity increases. We tend to believe that technological advancement is inherently good, and we set things up to where not much stands in the way of claimed technical progress. Many engineers produce highly technical work, throw it over a wall, and expect it to be used as intended and for positive purposes.

However, the technical part is never the hardest part. The people part is always the hardest part. And if you do not design with this in mind, what you work on can fail to achieve your goals, or even worse, do much more harm than good. 

I’m Michelle Thompson and I’m an engineer, executive, and entrepreneur. 

Let’s address something right away. The technical part is actually very hard. People spend years in training and many more years more employed doing difficult technical work before achieving even modest success in science or engineering. There is very little worth doing that is easy. The technical challenges we tackle are highly complex. Failures, setbacks, and roadblocks are ahead of you, all the time. It’s easy to think that’s the whole story. But, it isn’t. 

This is a talk about advice on how to be a better engineer or scientist. And the first and most important bit of advice I have for you is Do Not Give Advice. Unless it is asked for. And unless you can give it as a gift. Listen carefully to the person you want to help by giving them advice. Are you being asked for a Solution or are you being asked for Sympathy? If it’s not clear, then ask. If it’s sympathy, and in a professional context, then provide it. Ask them to keep explaining until they have complained themselves out. And then keep this confidence to yourself. There are exceptions to this, such as mandated reporting of abuse, illegal behavior, or self harm. 

Are you being asked for a solution? Do you have something productive to say? Then offer your solution as a gift. Gifts have no strings. Advice given with an expectation of control or compliance is not advice, it’s management. 

The purpose of a system is what it does. Not what it was designed to do. Not what you want it to do. Not what you need it to do. Not what it is expected to do. Not what you hope it does. The purpose of a system is what it actually does. That is the purpose.

It can be very difficult to listen to people that are telling you that your system or procedure or rule or code or product hurts them, or others. You may believe that it’s their own fault, that they are using it wrong, don’t deserve to have access to the product or design in the first place, or do not understand what you have created or enforced. That’s fine, and there’s space for disagreement. Not every system serves everyone. 

However, the purpose of a system is what it does. When people bring proof to you that your system is doing something harmful to them, it is much more likely that they are right, than you are wrong. A good engineer prioritizes fixing the system instead of attacking the messengers, users, members, or customers. There are times to defend the status quo from unnecessary changes. Be very sure you are defending a status quo for solid reasons. Be willing to do an honest review. Document what you see, even if changes are not possible. The next design will be much better informed. Science publication often ignores negative results. However, these results are incredibly valuable. Do the thankless work of recording what you see. You will benefit yourself and others.

The purpose of a system is always emergent. The effects and consequences and repercussions of a system really do not care about your intentions or assumptions that drove the design. Don’t argue with ground truth. Learn from it. 

And, there are always unintended consequences. A good engineer looks for these, anticipates these, and welcomes these. They will teach you what you should be looking at to fix the current design, and what you should be starting off with on the next design. 

Things worth doing are rarely easy. Exceptions are things like brushing your teeth. If it’s worth doing, other people probably haven’t already done it to death. And, not all hard work is worth you doing it. 

A system is defined not by the rules but how they are enforced. Rules that are enforced capriciously or only against one particular group indicate corruption or a police state. 

There’s a big difference between rules and boundaries. Rules are things we expect others to do or not do. We expect rules to result in changes or modifications to other people’s behaviors. There are penalties for disobeying rules that are usually enforced by some sort of external authority. 

Boundaries are conditions that are enforced by ourselves. We notify others that we have a boundary condition, like if you yell at me again, I will leave the room. Or, if you don’t pay me on time again, I will quit. Boundaries provide a clear description of what an individual will do if certain behaviors continue, but do not attempt to control or coerce changes in behavior in others. The choice to change the behavior is entirely up to them. The repercussions are enforced by the individual affected on what they can control, which is themselves.

In situations where rules are not enforced or do not help you at all, boundaries give you control and agency. Boundaries reduce harm and provide a framework for surviving difficult situations. What boundaries do  you have? What would you do if you saw something illegal, immoral, or unethical? What would you do if you found out you were being treated differently than others? What if that difference caused harm to you or others? Is there a situation in your life where you really wished someone had behaved differently? Is there something you wished that you could have done differently in the past? These are opportunities for developing boundaries that will make your future self happier and more capable as a designer and problem solver. We can’t make our best designs when we are afraid or stressed out. 

The technical is social before it is technical. Nothing technical exists in a vacuum or apart from people. 

Do not trivialize use cases. Poor use cases lead to poor implementations of otherwise excellent technology. Use cases need to involve actual humans. Use cases need to involve a variety of humans. If you do not do this, if you do not have or listen carefully to feedback, your design may end up hurting people. 

Your intentions and expectations of how the design is going to be used is not a replacement for what you get from listening to current and future users. You get to decide what’s worth listening to, but in order to get good feedback, you have to put in the work to make it possible for people to give it to you in the first place. 

You will be constantly confronted with unethical behavior. There may be no repercussions for unethical or illegal behavior. You will have to decide what you are going to do about it. Choose carefully.

This can be very hard. Your job or funding or relationships or reputation may be on the line. Everyone else might be doing it. People will make fun of regulatory processes, safety requirements, end users, management, and so on. Stick up for the right way to do things, especially when no one is watching. 

Money or power doesn’t change people.

An influx of money or power simply reveals who they really are.

Good governance is the entire game. Be part of good governance, even when it’s hard, or when  people in charge fail to follow their own rules. 

Do you recognize this image?

This is from a very famous and effective 1940s advertising campaign. How did it come about? Most of the US fire fighters went off to fight in World War II. Research revealed that 9 of 10 forest fires could be prevented, if people made small behavioral changes. An advertising campaign was designed and deployed to get people to make small changes. 

It worked. The resulting fire prevention saved a lot of lives and property. 

There were, of course, unintended consequences. Fires serve a purpose in the ecosystem. Decades of fire suppression lead to fuels imbalance and wildfires that were difficult to control and fight. 

Similar to this ad campaign, only you can prevent toxic behavior that wrecks technical work. It’s you. You’re it. 

You will have human resources. You will have great managers. You will have wonderful co-workers. If you want a clean and healthy job site, it’s something you must actively maintain. Suppressing toxic behavior also has unintended consequences. Those consequences will have to be recognized and adapted to in order to make further progress. 

It’s not always about who you are talking to. It is about who is listening. Bystanders are in the long run more important than targets. Especially when the target is invincibly ignorant, or you can’t win. 

Do not forget your indirect audience. Seeing someone stand up to a bully, or stick up for ethical funding procedures, or speak out against falsifying test data, is crucial to future health and success, even if you are attacked or punished for speaking up. 

Assholes will win. If you find yourself in a situation where repercussions are not enforced for bad behavior, quit. Do not be afraid to quit. Even if it doesn’t directly affect you. Even if the bad behavior benefits you. Why? It eventually will. You just haven’t been affected yet. 

Get used to thinking, “Not on my watch”. Encourage others that are also ethical engineers. Add them to your network. Take them to lunch. Develop strong ties with them. This will pay off. 

What do you do when you have the situation where you have to confront that “This wasn’t what I was hired for”? 

Likely you will do wildly different things than what is in your degree. You will have to adapt, learn, and come up to speed on new things all the time.

If you are hired for (or to develop) specific expertise, and you are not being listened to, are routinely overruled, or your work erased, deleted, or trivialized, find another job and quit. 

Kindness is contagious. However, the incubation period is indeterminately long. 

Ambush meetings? Just say no. 

What is an ambush meeting? It’s when the true topic of discussion is kept hidden until you show up. The organizer may also hide who will actually be at the meeting.

Call it what it is and consider not participating. This may have repercussions, but going along with it will result in worse treatment. 

Ambush meetings clearly communicate that you are not valued as a colleague, employee, or collaborator. 

A related topic is pull-asides. If you are approached in the hallway and asked to commit to something, no matter how innocent it sounds, thank the person and tell them you will go think about it and get back to them later. Do not agree to anything when caught off guard in a pull-aside. These have no written agenda, no paper trail, no acknowledgement of extra duties or responsibilities. Do not let your helpful and generous nature be taken advantage of, whether it’s intentional or not. Be courteous but clear. Meetings need to be transparent, have agendas, and happen on equal terms. 

Listen first. You will never make a catastrophic mistake by listening.

Eavesdropping is not listening.

Remember whatever you happen to hear.

It’s ok to say “That is none of my business”, and keep an opinion to yourself. 

All of this advice comes from hard-earned experience, and has served me and others very well. Your experiences and your stories are just as valid. If you find what I have said useful, please share it. If you would like to talk more about what I have shared, please get in touch. I’d love to hear from you.







 

No comments: