The Funny Thing About Feedback

Have you ever gotten feedback about something that you completely disagreed

with? Maybe somebody thought that you did a project the wrong way,

or maybe it was done correctly and they just disagreed with some aspect

of how you did it, what tools you used,

the approach to people you talked with,

or perhaps there was something so political and social and out of your

control and something you'dn't even consider that they just feel the need

to jump down your throat about.

Receiving feedback.

can be really tricky aspect of being in the workplace.

And the only thing that's as difficult as receiving feedback is giving feedback.

Wherever you have to tell somebody something difficult and challenging,

or even figure out how to praise somebody for work that they did,

the art of giving and receiving feedback is super challenging for autistic

and neurodivergent folks, especially.

something that I've encountered a lot of the time is a lot of that feedback

can be wrapped in a lot of social layers.

A lot of those reading in between the lines to say,

Hey, you did a great job on something,

and maybe you should think about this thing next time.

There's a really weird thing when you hear feedback like that.

When when someone says to you,

maybe you should do something or consider doing something or other loose terminology

doesn't really have teeth. It doesn't clearly communicate what the person

is trying to do. I have had this happen to me too many times when I'll work

on a project, work with somebody,

or do something, and I'll get feedback which includes a lot of words like

you should, you could, you might,

maybe, lots of very soft kind of halfway terms that don't really communicate

what the actual state that I

need to get to is.

There's a big difference between somebody telling me that I should do something

and that I could do something.

Telling me that I could use this tool in the future just means hey,

there's this technology or this platform or software that's on the shelf that

you can use if you want to. Whether you use it or not is up to you.

There's no harm. It's just there.

But saying that I should do something.

means that it's more of a directive,

more of a ask. It's this is something that you need to use as part of your work job,

and it is something that we strongly recommend.

There's a very subtle difference between just that one word,

could and should. I have gotten hung up in the meaning of this word too too too many

times to count. It's especially frustrating.

No.

Nothing is more annoying when I try to ask for details when somebody says that

I should do something a certain way or I should use a certain tool.

I ask the obvious question, why?

Why do I need to or why should I use this tool,

use this procedure, work with this person,

follow this process? And sometimes I'll just get told,

that's the way that it is. And I'm not given any more information.

I'm just that this is how we've done it.

This is the way that it's been done.

And

You've got to do it this way. Can you imagine how exhausting that is to just

be told you gotta do it this way and we're just gonna lay it onto you like

it is and not give you any information?

The stubborn autistic version of me just rebels and fights back against that

because I want nothing more than to understand,

to have a clear comprehension of what I am being asked to do,

and have a full grasp on the tools that are at my disposal.

And then figure out, okay, why should I do it this way?

When this has wrapped up into feedback,

you might have heard the term of sandwiching feedback.

It's when you kick off some series of feedback with people by saying a good

thing, a not good thing, you call it a bad thing,

and then another good thing at the end of it.

It's kind of the soften blow of whatever the bad thing in the middle of it is.

And this sandwich method of giving feedback

the mileage can vary based on what you're trying to communicate.

Because it doesn't matter if you sandwich really,

really, really tough or really,

really, really bad feedback in the middle of two good things.

It's like, hey, you get a good job in this project.

By the way, you ran over budget by two times and the people worked with

you really well. Good job. Like why would sandwiching even work in that department?

Even

Why would sandwiching work in that department?

It just feels like you're trying to weasel your way out of being the bad guy when

something really tough has happened,

and you need to convey that or you need to hear that.

When it comes to having to process that feedback,

you may find yourself in the position of somebody

When it comes to processing and receiving that feedback,

you may find yourself in the position of trying to figure out,

okay, what do I do with this information for next time?

Maybe using a budget is not a great example,

but maybe another example of this could be

Maybe a budget isn't the best example.

A realistic workplace example that I've run into way too many times is simply

talking to specific people or following specific procedures in order

to get something done that I have to do.

Could be a technical project, could be a proof of concept,

architecture, document. There's been a lot of times when I have quote circumvented

processes or procedures or standards for the way that something should have

occurred. And I still arrived at the same result.

I still did what I had to do. But time and time again,

I've been told by people, hey,

when you do this in the future,

you have to do it this way. And my response is like,

well, I did what I had to do. The same outcome still occurred.

Nothing was hurt. Nothing was lost.

What's the problem? at the time that might sound like a naive thing to say.

It depends on the complexity of what we're talking about.

One specific example was when I was looking at one of my first ever jobs

and I had to make a change to an API for one of the UI systems that we were using.

A UI system is basically like the theme or the visual brand of a website.

And it's a way that developers across organization can be consistent and uniform

and how they customize a look and feel of pages that customers see.

And I had to make a change to this for some reason to support a project that

we were doing. And my manager said,

Okay, do whatever you have to do to make that change.

And I'm like, Okay, information received.

I'm gonna do whatever I have to do to make that change.

And in the moment it was a very literal

digest an understanding of that ask.

Do whatever you have to do. And obviously I went up to the UI system team

and I said, Hey, I have this change I need to make.

What would you like me to do to communicate and broadcast this change?

They told me, I double checked and made sure that it was okay.

And then I went ahead and did it.

And like a day or so later, I got what I kind of call a nasty gram,

a not great message from somebody being like

Hey, why did you circumvent or skip this whole process?

It was a very alienating message from somebody.

It was a very alienating message because I thought that I'd done everything

correctly. I thought that I'd done everything by the rules.

I wasn't attempting to circumvent any process.

I was just doing what I had understood to be the correct way to do this.

And someone kind of barged into my DMs and said,

Hey, actually you did this completely wrong,

you had to do it desire way. And in that moment I'm trying to process

and understand, Hey, I thought I did this correctly.

I talked to these people. I didn't

name names at the moment, but I said I posted in this channel,

I asked people for what to do.

They told me what to do. I made sure and reinforced my understanding.

And then I went ahead and followed their instructions.

That was what I was writing out in the message to them.

I started getting a little bit heated and excited in that moment.

And before I hit send, I went for a walk,

got some water, took a deep breath and came back to it.

And I realized that what I was sending was pretty heated and

a little bit angry at them and this individual was a very senior leader

and more so the messenger for this process and not anyone responsible for the failure

communication that had led to me doing what I had done.

And I looked at it and I'm like,

maybe I need to back off a little bit.

I need to process these feelings a little bit and then get back to them

and try to defend myself generously,

but then also give them some feedback.

When I was given this feedback

It can also be an opportunity for me to give them feedback about a process that

allowed me to end up in this state.

When these sorts of things happen,

when a system breaks, someone ships a bug,

someone makes a bad configuration change.

There's lots of different reasons why a system,

application, a process, whether it's technical or not,

breaks down. And a lot of the times it can be driven by the decisions of a human,

but largely those decisions were allowed to occur because of some gap or omission

in process in system architecture or guardrails to

prevent that scenario from happening.

I've been software engineering for many years now,

and I can count on many hands the number of times that I have broken something

in production, not because I was intentionally making a mistake or being

neglectful or rushing something,

but because I did what I thought was the correct way to do something,

and I either didn't have the right guardrail to stop a regression from

occurring, or I just simply didn't know any better and couldn't have known

any better.

And I've had a mix of managers who have been able to handle situations like that.

Some managers like to point a blame game and say,

Shea did this thing wrong or Shea committed this bug or Shea shipped

a problem into production and it's his fault.

And that's alienating. And I feel very awful when someone points the finger

at me and says, Shea is the reason why this part of the application

was misbehaving or was down completely or something.

Imagine if somebody said that to you.

If you were working on a project or working in some sort of system,

and out of nowhere you're doing your job,

someone kind of comes up to you and points a finger and says,

You're the reason why this was down or not working,

or this customer had a problem and came in to complain about this the other day.

Doesn't that feel awful? Then that moment,

the feedback that is being received is just such a downfall.

It's so exhausting to have to listen to that.

And then you have to go about the rest of your day and figure out,

okay, like how do I bounce back from that when I'm just alienated for something that

I did. We're humans. We make mistakes.

It happens. If you aren't in a position where you're causing a couple of mistakes

and mishaps, are you working on anything that's really important in the first

place?

I'm not recommending that you do anything super risky or dangerous or perhaps

haphazard in your workplace, but I do think

But it's important to note that sometimes you are going to work on something that's

high visibility, high importance,

and ship a feature or work on pr a project and fail to consider some use case that

you could never have reasonably predicted,

no matter how much research you did,

someone's going to find some way they want to use your system that doesn't work

for their use case and they're gonna find that it's a bug and they're gonna come

to complain about you. Or there's going to be some other feature or some other facet

of the system that you could never have predicted in a million years,

and then

it's suddenly breaking, or some other edge case that we could never consider

in our lifetimes. In a world of AI,

it's a little bit easier for us to have a better understanding of its use cases,

but by no means is that an exhaustive solution either.

This boils down to the point of when you are receiving tough feedback as

if you are being blamed for something or listed as being responsible for something,

it is an opportunity for you to give that feedback back.

And say, hey, the reason that I fell into this black hole that this regression

was introduced was because I was following these systems and these guidelines.

And anyone else who was doing the exact same thing as me could have done the exact

same thing and fallen into the exact same black hole.

So rather than blaming the individual,

blaming me, let's try to reinforce those systems to make them better.

That way this particular chain of events does not happen again.

the call it a domino effect, call it a ripple effect,

the butterfly effect. There's a lot of situations in which something that I have

done, whether I introduced a regression or didn't consider a use case,

was not because I was being neglectful or being ignorant,

but because I lacked the guardrails or the reinforcement that I needed to know that

something that I was doing was going to accidentally introduce a regression

or cause a bug or misbehavior somewhere else.

And that is feedback for me to say to somebody else,

to say, let's

Help other people like me and unlike me to stop a thing like this from happening

again in the future. It takes that moment of being able to process what I'm hearing

and then say, okay, I heard this person,

I'm hearing them out. They are telling me that something that I did caused a problem

somewhere. I acknowledge that.

And this person may be a little bit hot headed,

they may be upset, they're

fighting fires with different customers and I'm not having to deal with,

I'm just at the end of that chain and they're right in the middle

of the communication chain. And they may also be feeling a little bit upset

and emotional over something that they had nothing to do with.

They're literally just a messenger.

So that's not an opportunity or invitation for me to jump down their foot either,

because they're fighting fires,

I'm fighting fires. We're all firefighting on the same team.

So we should want to get to the same outcome together and not be hostile.

Whenever I'm giving feedback

back to that individual or to a person that's related or to another system,

I have to be considerate about them and what they're trying to do in a situation

and also hear them out. It's so rare,

I found, that anybody is ever truly willfully neglectful or rushing

or haphazard in their work. By and large,

99% of all of the

regressions, bugs, big issues that I've ever seen in my software engineering

career can be boiled down to people not understanding how systems worked

correctly, or they relied on some assumption being true when it wasn't.

That's true outside of software engineering as well.

And I can count on one hand a number of times somebody shipped a change because

they were rushing or were not being considerate of making sure that a system

that they were working on was actually

behaving the way that it was supposed to,

given the set of changes that they were trying to commit.

Operating off the assumption that people aren't trying to be malicious,

we have to be blameless. The organization Atlassian,

who makes the software Jira and Confluence that you might be familiar with,

has the concept of the blameless postmortem,

which I'll include in the description of this episode.

And the blameless postmortem describes this very scenario.

where something bad has happened,

we're in a situation where a bad event has occurred,

and we now need to understand,

rather than any one person having caused it,

what parts of the system allowed this series of events to unfold,

this domino effect to fall, and then how can we stop this from happening again

in the future? That greatly alleviates the pressure that any one person feels to give

or receive or process feedback.

Because we're now not talking about people.

We're talking about systems. We're talking about technology.

Technology doesn't have feelings.

Technology is a system that we build and we maintain.

And most of the time it is meant to be deterministic,

which means that if you give the same set of input,

you'll have the same output. And obviously things can happen and bugs can occur.

And sometimes we rely on it to be deterministic,

and is isn't always the case. But by and large,

a deterministic system is supposed to behave in the exact same way time over

time

again.

And if us as humans are observing that that isn't the case,

we can give feedback about the systems to say,

okay, what's wrong with this system and how can we make it behave more

to the way that it's supposed to,

or that we think that it should behave,

if we have to change the parameters within which it must behave.

That doesn't just apply to technology,

it applies to workplaces as well.

One of the biggest things that I've encountered in my time is asking

for accommodations and trying to

figure out how I'm going to be successful in my own job is giving feedback about

that sort of stuff on my behalf or on behalf of others who are just trying

to do their job. There are impediments that are in place to people

who are neurodivergent who are just trying to do their jobs and just trying

to get through. For some reason are met with roadblock after roadblock.

And these impediments aren't being put up by humans who are being

malicious or ableist or otherwise trying to be difficult,

they are reinforcing parts of a system that simply aren't designed to work

for neurodivergent people. So rather than giving feedback and saying this

individual, this manager, this HR rep,

this peer is being really difficult,

and that's it's a tough emotional moment.

You want to feel like there's a a a face you can put on the problem,

that there's a name you can have.

pointing to somebody and say, this person is part of the problem and I have

to do something about it. That's a very impulsive answer,

and I'll freely admit I've felt that a lot of times.

I'll want to scream at somebody's name.

I'll want to have their name in my mind.

I'll want to say I'm gonna do it.

I'm gonna figure out how to take care of this problem.

It's a very hot-headed emotional response that I have felt way too many times

in my past. And it's easy to want to fall in that trap of saying,

A human caused this, so I have to find a human to fix it.

But when I am in that moment of trying to understand,

okay, this person's probably just doing their job.

They're not trying to be mean to me.

They're just trying to reinforce or stand up on behalf of some system that they

represent, whether that's technology,

whether that's an HR system.

some internal process, whatever it is,

they're not trying to be mean.

It might not change the fact that they are sounding coming across as mean,

but it they are not trying to be mean to you.

It's not personal. So let's take a step back then and apply that same blameless

postmortem process to something like an accommodation in the workplace.

Such an accommodation can be very simple.

It can come back to a lot of those interview questions that are nice to have

in advance of an interview, those soft skill tell me about a time when questions.

I have a whole episode about those sorts of questions as far as answering them.

But something that I have found to be very helpful for me is asking the interviewer,

hey, can I have a list of what those questions are going to be in advance

of a conversation?

Now these are not interview questions regarding something very technical or hard

skill based or things where you're trying to cheat on a test,

so to speak, but they are higher level soft skill emotional questions,

behavioral questions that seek to learn more about me.

And there's no cheating on those.

I need to have an answer to those questions.

Something that I struggle with as far as my brain articulation is being

put on the spot to have to answer those questions in a high stress environment.

All I really want to do is curl into a ball and not answer those questions.

But knowing what those are and at least having a chance for my mouth to say those

words can be very helpful. I had mixed signals in trying to get these sorts

of accommodations put in for myself and for others.

And oftentimes when I'm not allowed to do this,

somebody will say, We can't do this because we'd have to everybody else.

I can be mad at this individual,

but it's not.

Their fault specifically. They're not the ones saying no.

It's a decision that's been made far and wide and above them to not do this.

And when I receive that, all I want to do is try to understand it from their

perspective a little bit, try to process that,

and then say, Okay, I hear them.

This is something that they can't control,

but what recourse do I have to try to change their mind,

try to understand or articulate my perspective?

Try to help them understand and try to change the system.

And it goes beyond changing a person's mind.

I have to change and fight against a system that is fundamentally

not compatible with my brain and who I am.

And sometimes I've had success with that.

Sometimes I haven't had success with those.

It's the times when I have not had success that I realize this is a function

of the company's culture. If I can't change that system,

if they're not willing to accommodate me.

then that is a reflection of their perception of neurodiversity

and disability, and maybe it just isn't the right workplace for me.

In companies where I have had the opportunity to change systems like this,

whether it's about an accommodation,

about a system, about removing the blame of a human from a problem that they were

implicated in, it is a positive reflection on my ability to speak freely and honestly

about things that I struggle with and get implicated on.

The last thing that I wanna do is get upset that I caused a problem.

And don't get me wrong, I can still be frank and honest and say,

Hey, I had a hand in causing this issue and this problem as a function of these

systems what should have stopped me.

I can still be honest and reflect about that.

But it's another thing when someone comes down on me and really shuts me down

and says, This is your fault, you cause this whole

system problem.

When you are in the middle of that moment,

it helps to really break that down to say,

I'm hearing you. I understand.

I need to process this first. And then let's find a way to make this better.

Let's move forward. Let's try to be constructive about it.

Let's try to remove the human from it as much as we can.

And then situations where it does come down to something that I did or said.

There are scenarios which come more interpersonal,

more social, when it's not something that I relied upon and is

me or my understanding of something that may have caused something to happen.

It does still take time and emotion and energy to work with your team

to understand, to receive, to process that information,

and then to be try give that feedback back.

That way I'm not falling into the state where someone has to have an uncomfortable

conversation with me. I don't want someone to have to come up to me and feel awkward

and be like, hey, do you have a couple minutes to talk?

Because I know what that conversation means.

And it's not great. And on the other hand,

I don't want them to not give me that feedback either.

When you're in a situation, if you are giving feedback or receiving feedback,

think about the human. Think about trying to understand the whole breadth of events

that allowed us to occur. And let's try to understand how we can help everybody give

and process and receive feedback even better.