Ask HN: How do you fix engineering culture?

Without more data it is hard to know if the information in the exit interviews were valid. People might indeed be leaving for better paying pastures but we missed that.

Some of them hit home for me:

---

> It sounds like the product is "simple" but the reason for the large amount of code might be that there is no clear definition of the minimal viable product. The added complexity is possibly there because the UI/product team is piping in more requirements somehow.

That makes a lot of sense.

Pretty much all our app screens are extremely complex looking and full of different details. Actually, let me rephrase that: the whole system is completely inconsistent visually and each different screen has its own special widgets.

Interactions are not standardized and even tables have 20 different styles of text fields, which confuses our customers to hell, to my own chagrin.

All our screens are prototyped in Adobe XD before engineering looks at them, and that might be the root cause for (at least) the hardships at coding the frontend.

---

> I've seen incredibly smart engineers stifle and essentially belittle other intermediate/junior engineers over their work or ideas

You're right.

I've seen senior engineers talking down junior engineers. This is something that shouldn't happen.

---

> Giving engineers the room to develop design skills and make mistakes is important

> Systems can get complex and fail for a wide variety of reasons. Personally if I were the engineering manager and an engineer brought down the system somehow I would raise that as a cause of celebration without the connotation of death ("post-mortem"). Celebration since this is one step further in figuring out how to make the system more robust. A lot of time cultures promote an environment of fear where people are afraid of changing the code because things break. Continuously improve things so that it is harder and harder to break.

This is interesting.

Another poster mentioned we're trying to cater to "all kinds of developers". Maybe we should choose a specific profile?

The people I mentioned who complain that "things are going too fast" are also very averse to production mistakes and complain about it a lot.

That makes a lot of sense.

The multitude of complaints show me that we're not only communicating what we want to, but also we're failing at communicating what kind of engineers we want.

We're currently changing our hiring process, and I will give that feedback to HR and to C-levels.

That's really good advice.

Thank you.

> Actually, yes. They wrote the software that is currently used in production.

> But they don't want to touch engineering with a ten-feet pole. One time they complained that engineering was taking too long to finish stuff and engineering demanded an apology.

Engineers can get very touchy about code they write. It's kind of their baby. It sounds like the highest levels of management have written what is being run, and yet not want to seem to maintain it, or directly lead the engineering org. Then they also want a great engineering team to improve what they've been doing, which inevitably ends up being ways that the initial implementation could have been done better. Sounds like a double bind for the employees. If an employee finds a much better way of doing things, the founders should be happy, but they may be sending mixed signals.

Another example is that when you've written a bunch of code, you are the expert. Anyone else working on it will be going slower, because they don't have the background that the initial author did.

If there are two sides, and one says that the code is too complex, and the other side says it's messy and unsafe I'm likely to believe both of them. For different parts of the code, you may need incremental improvement, or you may need to rewrite it. This is where you need real engineering leadership.