A long time ago we had to do this exercise called “Ethics Moments”, I think many companies run these, they are pretty common. I liked the format, the scenarios though were not relevant to my engineers. They never face issues with Bribes from local government officials for example. They do however, everyday face what I would call “Technical Ethical” issues around technical debt, collaboration with other teams, execution decisions, etc.

So I decided to use the format but create scenarios more relevant to day-to-day for engineers. And as a play on words used the Term “Tethics”. And got engineers talking about what to do in certain scenarios relevant to day to day.

So let’s dig into some details.

Why are we here?

As engineers, we do things the right way, but we often seem to only limit this to a moral and ethical scope. With Tethics moments, we want to open this discussion of integrity also to the technical work we do. What is the right way to deal with technical dilemmas without hurting the product in the short term or long term? This can be very subjective, and on top of that, we also want to move fast, so how do we solve these problems so we can move fast tomorrow as well?

Create the Scenarios

A scenario should be a dilemma, and something that happens day-today.

I regularly have beers with my engineers, and sometimes when I do, I hear some crazy stories about code reviews, design reviews, etc generally when people are working with teams less mature or under pressure. Pressure is one of the main reason for technical debt in my opinion.

You dont have to be a beer drinker to create scenarios, but you do need to create a comfortable environment (RE: psychological safety, topic for another post) where your engineers feel comfortable speaking out, and this will help you find these things, the ones that come up more often are the ones you want to use for senarios.

I break these up into 3 sections title, description, and notes for the session leader, the notes help guide the conversation in the right direction, which should happen in a leader session anyway, which I’ll go into next. But the reason you need guidance is sometimes your engineers dont understand that they can push back, sometimes they think “this is the way things are” and when this is the case, you need some guidance so the session leader is confident to break them out of this.

I’ll give you an example of one of ours that I think will be relatable to a lot of orgs.

Scenario:
Owner vs Contributor

Description:
You are a system owner for “Generic Frontend System 2”.​
A backend team has sent you a large pull request for review, without a prior design review or any notice the work is coming. ​

It looks clear from their PR that they don’t have the best ReactJS skills, and it needs a lot of reworking, they’ve even managed to introduce a new state management library in their work. On top of this, the fact that it’s so large means it will probably take the team many days, or even weeks, to make all the needed changes.​

When you raise this with them, they say that they are on a hard deadline with Product changes, need to get this into production fast to meet their KPI for the quarter, and argue that it’s still functionally working, even though the code is not up to standards, so they ask if you can let it pass anyway.​

What should you do?

Notes for leader:
In the end it up to the system owner (you in this scenario) how they handle this, if you have push back against what you want (e.g. them fixing their code) and you don’t like it, escalate straight away to manager and higher if you need.​​ You’ll get support for this.

A common practice though, is that if its not “too” bad, getting a commitment from the team that they will immediately work on a fix after it’s merge, and bringing their manager AND PO into the room to make sure everyone is clear on the commitment. The PO is the one that a) has the most control over the sprint backlog and b) is most concerned with getting it into production that fastest, and may also be the one that tells every “its ok to wait”, you’ll be surprised.

<end senario>

So you can see we are leaving it pretty open here, in our company, system owners are the one that ultimately are responsible for the technical debt of their system, it’s part of our ownership culture, so it’s up to them how they handle it, there is guidance there because sometimes our system owners dont feel empowered, sometimes teams are under a lot of pressure and get into ruts, so this type of encouragement helps them get out of it.

The second part of the notes is talking about compromise, because sometimes you need it, but its ultimately up to you how you do this, its just one suggestion.

How to distribute sessions top down

“Top down” is usually a trigger word for me, living in South East Asia, where many companies have a bad top-down cultures. But in this case its not, its important for leaders to help shape a good culture, and this is one tool for helping.

The first session you should run is one with your leaders or managers, run them through the scenarios. Then they get your direct feedback on what is your expectations of how engineer should be dealing with these through the conversations. This is needed because ultimately if an engineer sees a problem and escalates and everyone is aligned they’ll get support from the top, if we arent aligned they might not and this will cause a problem for them.

After this tell them to run with their directs, and so on, for larger numbers of direct report you can run session with leads and send them out, or run multiple session, varies with your org structure.

Finally the session itself

How to run a session?

• Use the deck of scenarios (have at least 6-7). As a Tethics leader, you should read through them and pick 3-4 you feel are most relevant for your direct reports or team members (depending on how you are running it).
• Schedule a 1-hour session with direct reports
• Limit session size to 4-5 people maximum – if you have more people, then schedule multiple sessions.
• Fewer people means more people will speak out.
• Read a scenario together, then 15-20 minutes go around the group to ask what each person thinks the right thing to do in that scenario would be. – There is no right or wrong answer to most; it’s about an open discussion.
• Repeat the process for your selected other Tethics leaders to run with other people.

Are you the moderator?

• Ask each person to talk and have their say one at a time.
  • Choose a different person to start talking for each scenario.
• Don’t interrupt people as they are talking.
• Save your personal opinions on the subject for the end of everyone else talking.
• Focus more on commenting on others’ opinions than voicing your own.
• Try Lead people to a better conclusion by questioning (RE: Socratic method of coaching, another topic post) rather than disagreeing.

And that’s it, please let me know if you try this and what your stories are in the comments.