Ask HN: How do you fix engineering culture? | Hacker News Reader

Ask HN: How do you fix engineering culture?

91 pointsthrwwyngnr133 comments

I'm a manager in one of the biggest startups in our field. We're currently big in consulting, but we've been trying to move into SaaS.

Problem is, we're growing, but can't keep engineers. In the beginning of the year we had half the number of employees we have now, but twice as much engineers as today. An engineer left us three weeks ago and two more gave notice and are leaving in January. Hiring is extremely hard because of economy.

We have a strong culture, but it is widely felt by the rest of the company that the engineering team doesn't adhere to it. Complaints from other workers range from the decision they made to isolate themselves in their own building, how they actively engage in bickering and in-fighting between their own teams, how they have extremely limited communication to the rest of the company (users of their products), and reports of sexual harassment and racism.

There's zero consistency between the message they're sending. Some engineers believe the team is moving too fast, while a different group believes they're moving too slow. In the exit interviews we had complaints of micromanaging mixed with complaints of lack of management. The new flagship application we're building is extremely simple, but has way too many lines of code compared to all our other (more complex) applications. The development process is indeed slow and full of fail-safes, but there's still an astounding number of bug reports for a simple app.

Has anyone dealt with such a situation and has some advice?

EDIT: I'm a manager but I'm not in the engineering team itself.

View on HN

>Problem is, we're growing, but can't keep engineers. In the beginning of the year we had half the number of employees we have now, but twice as much engineers as today. An engineer left us three weeks ago and two more gave notice and are leaving in January. Hiring is extremely hard because of economy.

So I know nobody want's to say it, but I think that as a non-technical person, you should be focusing on pay here, and that everything else will follow. In my own career? if someone offers me a lot more money? that's a very strong signal that they are going to treat me better in other ways, too.

I mean, to translate this into manager-speak, pay is about respect. If you don't respect me to pay me more than the next company, you probably aren't going to respect me enough to treat me better in other ways.

(that, and money really does matter; I mean, I live in a world where starter houses are the better part of a million bucks. If I am getting paid $140K, and someone else comes along and offers me $180K? yeah, that's impactful; Even as a guy without kids who doesn't have particularly extravagant tastes, it makes a significant difference in the amount of time I have to work before I retire.)

Let me preface my message by saying that you're absolutely right. If we're having a problems hiring people, the solution is simply to raise salaries. I completely agree with that, period. That's probably the simplest and most obvious solution to our hiring difficulties.

---

Now, the paragraph you quoted from me is a bit weird indeed. I'll try to explain what I wrote:

We can't keep the engineers working with us because they're either getting fired for some reason, or leaving while complaining about different things. All but salary. They had two raises in 2018 and pretty much everyone left got a promotion in 2018.

Hiring is *harder because the economy is strong again, so we have a smaller pool to hire from. But this has never been a problem before. Problem is, people is leaving too fast.

>We can't keep the engineers working with us because they're either getting fired for some reason, or leaving while complaining about different things. All but salary. They had two raises in 2018 and pretty much everyone left got a promotion in 2018.

I think money is more than that, though? I mean, I... almost agree with what I said when I said "to translate this into manager speak" - Like, the differences between how Engineers were treated in the '90s and early aughts, and now... I think it's mostly that we get paid like two to four times what we did, and because of that[1], the non-technical people we work with now treat us with a whole lot more respect than they used to.

I mean, I personally see the same thing looking at friends who are moving up through the less well-paying portions of the tech sector. Its like it's hard-wired into people that they can treat people they pay poorly worse than they treat people who are paid well.[2]

I think there is also this very strong cultural norm that we shouldn't talk about money or especially we shouldn't complain about money. Like as a technical individual contributor, we need to pretend that we are doing this because we love it rather than because it pays really well. I even feel it in myself, sometimes, (though I think it's fundamentally better for us, as workers, to talk about compensation in an open sort of way) - I mean, don't get me wrong, I love doing what I do, but if someone offers me a bunch more money to do the same thing? Yeah, that's hard to turn down.

But I mean, my point here is that if someone else offers a bunch more money, a lot of people, when asked why they are leaving, are going to talk about non-monetary stuff, even if it really was mostly about the money.

But also, like I was saying above, I think that if you aren't paying as much as the competition, you almost certainly aren't treating your people as well in non-monetary ways. I really do think that if you want a business oriented person to treat someone else better, you pay that someone else more money, because that's what business people are hard-wired to respect. (If you want an Engineer to treat someone well, you point out something technically difficult/that requires a great deal of intelligence that person has done)

I mean, I suppose I'm not being that helpful, just 'cause if you felt like you could pay these people more, you probably would. The FAANG companies are paying a lot to regular individual contributor engineers, and that's just really hard to compete with.

https://www.paysa.com/salaries/google--software-engineer-3 ('3' here means that you went to college and passed the google SWE interview.) - point being that there is a whole lot of money sloshing around. Like, a whole lot more than I used to think there was.

[1]other than temporal correlation, I actually don't have actual evidence for causality here. I do strongly believe that there is causality here, though)

[2]this always seemed super weird to me, just 'cause if you pay me enough more than I can get otherwise, I'm willing to endure a lot... I've spent a lot of effort looking for jobs where they'd pay me extra for enduring bullshit or even actual physical danger.... but none of those jobs I've found pay as well as staying safe and comfortable in silicon valley.

> So I know nobody want's to say it, but I think that as a non-technical person, you should be focusing on pay here, and that everything else will follow.

Maybe not. Over my career, I've learned that good work conditions (reasonable management, working with people I like, work-life balance) trumps absolute pay as a motive to work (or continue to work) somewhere.

One of the arguments I was advancing was that there is a very strong correlation between pay and how well I am treated once I get there; to the point, I think, where evaluating pay might be the most effective way to evaluate how well I'll be treated in non-monetary ways; the most effective way to make up for the fact that it's really difficult to tell how well a place treats you before you show up for work.

That's fair. My comment was more on leaving - if I already know that management is sane where I currently am, and I like my co-workers, I would think very carefully before leaving for more money.

Some of the social issues are difficult to address without extensive insider knowledge of your particular company and culture. Some easy outsider advice though is the 'Joel test'. Written in 2000, its a bit out of date, but there are more modern versions of it floating around the internet (such as the one that follows). Basically it is a checklist for a good development environment. In my experience it is fine to miss one or two of these, and some are n/a based on what you are building. But if you find you are missing of half-assing a lot of these, seemingly unrelated employee satisfaction issues will start to pop up.

1. Are all builds handled automatically by a Continuous Integration server?

2. Do you make and use daily builds?

3. Do you use an issue tracker?

4. Do you fix bugs before writing new code?

5. Do you have an up-to-date schedule?

6. Do you have up to date information on your products performance and usage?

7. Do you use the best tools money can buy?

8. Do you have a comprehensive test plan?

9. Do you have dedicated UI and UX designers?

10. Does all code go through code review?

11. Do you have coding standards?

12. Are new employees given training?

13. Can you download the code base and run it in one step?

14. Do engineers have the strongest say in their time estimates?

15. Do engineers choose the tools and architecture for what they are building?

I’ll second the Joel test. But like a lot of “modernisations”, I think the version you give has lost some of the spirit of the original. Less room for individuality, more tooling, rules, and processes. And losing “quiet working conditions”, in particular, is a big change.

I still find the original holds up pretty well in many environments.

This list needs automated testing added to the top.

How's your hiring process? It sounds like you're trying to be all things to all engineers -- and not being any of them to almost anyone.

(We're tight-knit and cultured, but loose and independent! We're moving fast, and slow! We're making something simple, with a million LOC! Our process has "fail-safes", and yet somehow we have a ton of bugs!)

The one dichotomy I believe is that you're micro-managing and not managing. Your engineering management is probably running around offering spot-fixes. They're not providing direction. What kind of company is it? From the lack of consistency, I'm not picking up on any culture at all.

I can't tell what type of software you're making but if you're just hiring for "engineers", half of them will think you're moving too fast, and half will think you're moving too slow. NASA isn't going to hire a Facebook developer to write avionics, and FB isn't going to hire NASA engineers to write emoji-pickers.

You need to figure out what kind of company you are, and then hire (and maybe fire) based on that. No engineer is accusing NASA of being too fastidious, or Facebook for moving too fast, because everybody is on the same page from day one.

I don't think hiring is especially hard if you know who you are. Almost every software company (i.e., your competition) is terrible at hiring. Figure out your culture. Apple could hire even when their stock was in the toilet because they weren't afraid to show the world what they represented.

QUESTIONS:

1) Does your company have a solid Business Strategy?

2) Does everyone in the company understand and support this Strategy, and know how they contribute to it?

3) How do individuals know when their decisions and actions are aligned with the Strategy and contributing to the company's success?

> You need to figure out what kind of company you are, and then hire (and maybe fire) based on that. No engineer is accusing NASA of being too fastidious, or Facebook for moving too fast, because everybody is on the same page from day one.

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.

Not just hiring, but leadership of existing employees. Be careful not to try to brush it off as "We hired the wrong people (so we just need to fire everybody and start over, and all our problems will be solved)".

Many people are flexible enough that they could work for a range of styles. In the absence of leadership, they have to make up the answer themselves. Everybody makes up their own answer, and then everybody is frustrated that their coworkers aren't behaving correctly for their view of how the company should operate.

At every level, your engineering managers need to know what type of company it is, and provide clarity.

"We've got 'fail-safes' on our SAAS release process, and we're still shipping 100 new bugs a week. Clearly, something is horribly broken here. Based on our company values, we can all see that the solution is ___." Remove the fail-safes? Fix the fail-safes? Ship more often? Ship less often? Kill the product? Cut features? Spend a month just fixing bugs? There's no one correct answer, but you have to decide.

To me, what your describing is a management deficiency. My first guess would be you lack highly skilled engineers at all levels of management in your company. This is a common oversight in tech companies to not consider that people at all levels of the company should be skilled in engineering. If this guess is wrong then the rest of the post doesn't apply.

If you were starting a chain of restaurants you wouldn't hire a manager that only knew of this vague idea of a thing called food and that people were willing to pay for it, but they do have excellent leadership skills. It would be totally silly to do so as there's a giant disconnect between the leadership and those producing the work. Also consider that in our restaurant even the HR team could identify 90% of the tools used by the chefs and understand how to use most of them.

It's important to take this same attitude with a tech company. If you're doing software engineering, can every other person in the company write a program? They don't have to be a programmer by trade, but can they do it if required? If that's not an expectation, why isn't it? You'd expect the software engineers to be able to fill out reports, spreadsheets, provide data metrics, understand the work place harassment polices, health care benefits, present in team meetings, etc... Many times engineers can even be expected to interact with end users/customers from time to time to assist in support or sales. So, they are expected to maintain a basic skills set to do jobs that have dedicated teams. Why not apply this in reverse to those teams and the leadership to require they have a basic knowledge of doing the work of the software engineer?

In general, engineers aren't going to integrate in to a culture or want to work for people who have zero relatable skills to them.

Every employee is expected "to be able to fill out reports, spreadsheets, provide data metrics, understand the work place harassment polices, health care benefits, present in team meetings, etc.."

Engineers are not special.

I hear a lot more cases of "disfunctional company struggles to hire/retain good engineers," "non-technical founder seeks engineer to do all the work," etc. than the converse (firms with good engineering talent struggling to find good management).

So maybe engineers are special? They can certainly afford be more choosey about who they decide to work for.

It probably makes sense for a company to treat engineers as special if engineering is a critical part of the business. No good engineer is going to want to work for someone with an attitude like yours.

Sounds like you're in a filter bubble.

Can't have good engineering without good management.

> Can't have good engineering without good management.

This is not even remotely true.

One could have a “good” engineer but the engineering team/dept/section will be lackluster. A strong engine without a rudder is meaningless and vice versa.

There is a reason why leadership of teams/section/department etc has the responsibilities and accordingly higher pay.

I know over three engineers who left their companies because of the stringent bureaucracy expectations, filling out reports and the like. It was boring to them.

They all got new jobs within a week.

Unlike other positions, for engineers, it's the companies that are replaceable, not the employees.

Engineers are special whether we like it or not.

> Unlike other positions, for engineers, it's the companies that are replaceable, not the employees.

I read that a few times in this thread, but I'm not sure whether it's as true as pictured here. Maybe in some bubble environments (bay area and Seattle). But for most of us other engineers there isn't necessarily the next employer around the corner - even for those with exceptional skills.

So Italy is in the bubble :) Good to know

So many positions for sw. engineers and so little experienced professionals to fulfill all those job openings, at least in my zone.

I can’t tell about Italy. But eg in Germany the air would be quite thin if one looks for a software position above 80k€ or even 100k€ (yes, there might be enough options in the 50k€ range).

Wouldn’t have expected italy to be much different

With 5 years of experience in (northern) Italy there are plenty of job offers in the 35-40k range, which I think is roughly equivalent to 60+k in Germany, maybe 70ish.

Note that I don't live in Germany so my numbers may be wrong, in that case well... let me know :)

Engineers are special in that they ideally understand every aspect of your business if you want them to be most effective.

Nope, not special.

No where was I making the point that engineers are special. It's that other teams not not special, but they get to be special by being allowed to not understand one core group of employees. To foster a good environment, culture and cooperation between teams it's important that there is a strong crossover in skills and knowledge.

Your response is making my point that other teams do view themselves as special by blatantly ignoring the basic skills of the engineers. For everyone of those items there are dedicated teams who are the experts, but companies expect that all employees have a functional knowledge of them. So, why do they not expect that, in a tech company, those dedicated teams to have a functional knowledge of engineering. There is no communication without a common frame of reference.

You wouldn't expect a receptionist to be able to do the job of an engineer why would you expect an engineer to be able to do the job of a receptionist?

Expecting every employee to be good at every job is just dumb.

> reports of sexual harassment and racism

Your leadership needs to (internally to the company) publicly state areas where they have zero tolerance and live by it. Suppose your star coder is a racist? They better be 100.00% perfect at keeping that toxicity bottled up privately, because if even a whiff of it leaks out detectably, they get fired, even if they’re the most or last competent engineer in the place...

Same for sexual harassment. Publish guidelines for intra-company dating. Make clear that sexual harassment will not be tolerated anywhere in the company.

If engineers (or anyone) are allowed to harass people without swift and unambiguous leadership intervention, you’re fucked.

I echo the thoughts elsewhere here that, based on the couple paragraphs of your perspective that you shared, you seem to have a serious leadership problem in tech. Someone (inside or out) needs to come in, figure out what the business needs from engineering, put engineering on track to deliver that, and be the point person to take arrows on both sides. Engineering: stop acting like whiny, entitled brats and start delivering for the company; if you have concerns about anything, bring them to me or my LT. Everyone else: if you have concerns with engineering, bring them to me.

You may or may not also have a pay problem, but you almost surely have a leadership problem.

While not as applicable in situations where the engineering team isn't under much pressure to deliver, there's a pretty common negative feedback loop that can occur with engineer staffing. While under pressure, teams with an adequate or bountiful number of skilled members will generally perform pretty darned well and not have a problem. If anything causes the balance to start tipping too much in the ratio with unskilled team members then the skilled members will feel more internal career growth based pressure to find work elsewhere. As they start to slowly phase out to other locations the ratio gets even worse, the quality of the product gets worse, and the moral gets worse. All of this causes more incentive for the skilled engineers that are still left to leave as well.

Unfortunately as this happens a higher number of deliverables will be missed and more bugs will arise alerting management that they somehow have become a less productive shop. This is where you can readily identify bad engineering management. Instead of tackling the root of the problem many places double down by increasing pressure to deliver and by relaxing standards as to who they hire. Once this happens you've unfortunately started the process of being a sinking ship. This can be righted in time depending on how large the company's coffers or how tight of a hold they have on the market but growth generally will have peaked by this point.

What management should have done (or needs to do ASAP) was to start trimming poor performing engineers. Yes firing people is hard, yes it sucks getting rid of workers when you're already behind schedule. But any good engineers you manage to trick into joining this dysfunctional team will likely leave within the first few months anyways. Relaxing pressure to deliver WHILE fixing the poor performers issue can also help slow down the rate you're losing good performers at least for a short period.

I've seen this at many many places. Currently still in one of these situations because they keep throwing more money at me to stay but even with that I've started looking again because the situation is not helping my career growth as much as I wish.

edit: IpV8's checklist is also really important to look for and lack of that could cause the start of tipping the balance as mentioned above.

> What management should have done (or needs to do ASAP) was to start trimming poor performing engineers.

Oh, we did that in 2017. The engineers are hard workers and good coders.

Thing is, there aren't really individual performance problems. The problems are mostly cultural: Isolation from the rest of the company, in-fighting, competition, lack of camaraderie between teams and between engineering and the rest of the organization.

When it comes to team performance, half the team believes we're too slow, while the other half thinks we're moving too fast. Even that is a point of disagreement.

Your company has a LEADERSHIP Problem!

And the 'cultural' problems: isolation, in-fighting, counter-productive competition, are symptoms.

Your 'leaders' have hired misguided Engineering Managers who created an environment that made this behavior possible, and your leadership is allowing it to continue.

> First Question: Are your founders / leaders Engineers?

> Second Question: Why do team members think that you're moving too-slow / too-fast?

> Are your founders / leaders Engineers?

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.

> Why do team members think that you're moving too-slow / too-fast?

Good question. Both sides provide very good arguments, but they're super polarized.

Half the team is the MVP-lean-startup-crowd and is constantly complaining that the code is too complex, with too many abstractions and it is and hard to test and debug. They claim they want to push simpler code that works and optimize/refactor as needed, but that never flies on code reviews. They claim that the constant refactoring (I swear I hear that word ten times a day) are causing way too many bugs.

The other half comes from an enterprise background and complains that the code is currently too messy and unsafe, and claim they need to refactor weird parts before doing pretty much any feature. They believe in making bigger deliveries instead of incremental ones, and point to bugs caused by the other team as proof that they need more time to get it right.

For obvious reasons, management has ALWAYS sided with group number one, which caused a lot of problems and accusations of favoritism.

My hot take? Yeah, three years is way too long for a simple web app from a startup to be ready.

>> Are your founders / leaders Engineers?

> 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.

> 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.

Well, in their defense: they have to, you know... run the company.

Engineering was supposed to maintain the current software, but they (engineering) chose to deprecate it and make a new version from scratch. It is just taking way longer than expected, three years and just a fraction of the original functionality.

> If an employee finds a much better way of doing things, the founders should be happy, but they may be sending mixed signals.

Problem is: they're not doing anything better. Customers prefer the old software. Other employees prefer the old software. Even some people on the team prefer the old software.

This seems like a key issue. It's time to evaluate progress on the re-write and work out what to do next, with all options on the table (including re-focussing on the old software, or even starting afresh with a "version 3").

Are there any people in the engineering group who have been doing non-trivial bits of work on the old software? It may be worth cultivating these people and taking their opinions seriously, even if it ends up putting other (perhaps more senior) noses out of joint within the engineering group.

One of the guys who left engineering takes care of the old software, plus some other new stuff.

He's indeed friendlier than engineering.

Might be a good idea indeed to integrate him with his old team, or maybe build a new team around him.

Make sure you understand why this person left engineering. "Integrating him with his old team" could be good, but could also be throwing him right back into the middle of something he was actively trying to get away from.

Right, I get that they have to lead the company. But if other parts of the company are doing well, and engineering is struggling, and they have key insights into how the software was built, and why it was better, it would seem they would be in the perfect spot to lead the engineering team to a better place. They are the subject matter experts, and it seems like this app, whatever it is, is key to your business. And they previously made it successful. But you said they don't want to touch it with a 10-ft pole. This just doesn't add up.

They tried once, but that was a year ago.

You're have a good point. Maybe after one year things will be different.

Whoever is in control of this team, needs to pick one, and stick with it. Hiring enterprise developers if you really want your MVP out the door yesterday is asking for trouble.

It also leads me to believe your product currently has a dearth of tests. Most of the bugs that are generated from refactoring should be caught by automated tests. Until you have tests, you shouldn’t refactor (always write a test first).

If your product is too difficult to test, the enterprise crowd may have a point and the initial (and further) architectural decisions have been wrong, and this suggests a lack of senior engineers.

Last point, if your abstractions are making it more difficult to test, then the abstractions are almost certainly wrong.

> Hiring enterprise developers if you really want your MVP out the door yesterday is asking for trouble.

You're right, this is something I'll talk with HR about. I realize we're not hiring consistently and that might be causing problems.

You company has weak management VISION. There is no shared sense of purpose, so you've got infighting. Echoing some others, the steps to fix are:

1. Put in strong very senior leadership. Ultimately a lot of this rolls up to the very top, so your founders / C-level folks may need coaching or replacement (!)

2. Promote a strong vision: This is what our company does, this is where we're going, here's why it matters. We are all ONE TEAM.

3. Integrate engineering with the rest of the org, as suggested by others. This includes physical integration (seating) as well as exposure to work that the rest of the company does. Have some sales folks sit in on Eng meetings too to build cross-departmental understanding. There needs to be strong mutual respect which is really lacking.

4. Declare the One Way that work will be done (Iteration, Waterfall, or whatever you decide). There should be a single methodology for Engineering to execute tasks. Everyone in the org needs to sign on for this work, or leave.

5. Relentlessly recruit and promote leaders who share the vision for the company, and the vision for the work style. No one gets to just throw a fit and do their own thing.

On a personal note - I know the developers I poach for a 'next' gig. You lose those types people, there is a very good chance they will rebuild a team elsewhere taking the folks who can actually execute with them.

People love to say pay does not matter -- but of course it does. Go to glassdoor and see how competitive you actually are to the other companies. I can certainly put a dollar amount to BS/chaos I'm willing to deal with. Without fail, the companies that imply money does not matter 'look at all these other bits of compensation' tend to be cheap.

It can take years to build out engineering teams and get folks on the same page. Leadership is very important. Three years ago we did not have a single test or specification. Now we have a pretty solid automated CI/CD process. Technical debt is one of the core items we will be focusing on in 2019. Very easy to build out the MVP, and leave out all the things that make solid code. The other is more accurate forecasting. I don't want them to over or underestimate tasks... both are equally bad. The other bit is getting development to say "NO" (and making sure that no gets propagated).

HR is almost always there to protect the company, not the employees. If they are not processing the harassment issues out of the company... that would strike me as odd. Real harassment should be /dev/nulled quickly/harshly - and hope someone has a good eye for what was actual harassment vs something that may not be. Bickering, however, is a leadership issue and not HR. Not everyone is going to be 'happy' with a direction, nor should they. The engineering leads should be pushing their crew to be just outside of their comfort zone. My goal is to make sure I can retain the teams I'm investing in.

> We're currently big in consulting, but we've been trying to move into SaaS.

There might be a clue there. Consultant type people have a different way of thinking to developers. They want to solve clients problems and solve them quickly. They might be less focused on things that are about investing for the future, such as paying down technical debt. They might be more "just get it done".

The engineers might be more focused on building a solid platform going forward. The difference in tempo between engineering teams may be a result of their focus, e.g. "core architecture" vs. "urgent features/fixes" so maybe look at that.

I don't have answers, just more questions you can consider.

Paying more is the short term fix. If someone with a family would lose money by leaving they might consider staying longer unless the environment is so bad (bullying etc.) that they feel they have to leave.

I'd probably set up a 1-1 (with 99% listening, 1% talking) with as many people as you can, everyone in your team(s) plus quite a few people in other team, write it all down, sleep on it and see what you can figure out.

> We have a strong culture, but it is widely felt by the rest of the company that the engineering team doesn't adhere to it.

What do you mean "doesn't adhere to it"? Culture isn't a policy document that you can shove down people's throats and expect compliance. Culture is much more organic than that.

> Complaints from other workers range from the decision they made to isolate themselves in their own building

And there are good reasons for that. Engineering requires focus and discipline and therefore usually has a very different subculture from the rest of the company.

> how they actively engage in bickering and in-fighting between their own teams, how they have extremely limited communication to the rest of the company (users of their products), and reports of sexual harassment and racism.

And what did management do about these issues? Did management shut down the infighting? Is management accessible and responsive to users? Did management fire people who were found guilty of fireable offenses?

> There's zero consistency between the message they're sending. Some engineers believe the team is moving too fast, while a different group believes they're moving too slow. In the exit interviews we had complaints of micromanaging mixed with complaints of lack of management. The new flagship application we're building is extremely simple, but has way too many lines of code compared to all our other (more complex) applications. The development process is indeed slow and full of fail-safes, but there's still an astounding number of bug reports for a simple app.

Why did management hire every engineer who walked in for an interview?

Go find some competent engineering management.

> What do you mean "doesn't adhere to it"? Culture isn't a policy document that you can shove down people's throats and expect compliance. Culture is much more organic than that.

Maybe "fit" is a better word? Point is, engineers are different and aren't too comfortable around the other employees.

> And there are good reasons for that. Engineering requires focus and discipline and therefore usually has a very different subculture from the rest of the company.

I agree, you have a valid point here.

> And what did management do about these issues? Did management shut down the infighting? Is management accessible and responsive to users? Did management fire people who were found guilty of fireable offenses?

Issues stemming from individuals were treated accordingly. Problem is, the in-fighting and bickering is happening with pretty much the whole team.

> Why did management hire every engineer who walked in for an interview?

Other people have made similar points about our hiring process and lack of consistent between engineers.

> Maybe "fit" is a better word? Point is, engineers are different and aren't too comfortable around the other employees.

But that's the point. Why do you need the same "cultural fit" between engineering and non-engineering employees? Why does that matter when requests from users should always be funneled through management (so that it can be triaged) and never go straight to the engineers (where it disrupts focus)? If engineering were internally cohesive and harmonious in your company, even if abrasive vs. non-engineering, this wouldn't be considered to be much of an issue.

> Problem is, the in-fighting and bickering is happening with pretty much the whole team.

So, divide and conquer. Split people up and put them with people they don't know. Subject them to strong authority in their new place and watch them fall in line. If they continue to be abrasive, you probably have cause to fire them, but that won't be the case in most circumstances.

In my experience, you need to fix the major issues first, and that's the racism and sexism. Lay down policy to all employees, tell them you'll be backing it fully, and if anyone falls prey to it they'll be out of a job. Culture or ability be damned. Ability in a role should not mask sackable offences.

From there, I'd start by laying down some process. One of my old workplaces was rife with micro-management, and the only way around it was to define a process for how the development team work, interact, test, etc. We had numerous hiccups, despite all sides agreeing to this method of working, but the strongest team in the company at the time was the dev team, and that quality saw us through.

I like The Joel Test suggestion, because it sets some ground rules for how the dev team should work. I'd go further, and I'd work with your own dev team(s), and the managers of other departments to find out what they want from a unified process. From there, build an internal process document and an external document, and ask for time to implement this process. Treat it like a project and assign time/resource to it, especially if your developers have downtime. At my last place we did this, and naturally ended up filling many of the blanks in The Joel Test through trying to improve our processes. We switched to automated builds and deploys, we created a robust hiring process, and vastly improved how we test software.

Finally, despite your worries, I'd thank your dev team for doing the job they've been doing. Everyone knows when a project is going to shit, but positivity goes a long way towards salvaging it and turning it into valuable lessons. In my view, bugs are a good thing, because it provides another iteration of tests and fixes, and if you can buy time for your team to iterate over your product(s) while building a robust development process, you'll naturally see happiness increase.

We have a strong culture, but it is widely felt by the rest of the company that the engineering team doesn't adhere to it.

This evidence indicates that you don't have a strong culture.

Also, there's something not right in the way you say "adhere", but I can't quite put my finger on it. People don't "adhere" to culture; well, they do, but the word "adhere" is simultaneously too strong and too weak for a culture. It's like saying that fish adhere to swimming.

Tell me again that you have a strong culture, but this time don't use the word "culture". Tell me what these behaviours are that everyone does, except engineering. Then pick one and tell me why engineering doesn't do that (and assure me that everyone else does). Do they know about it? Do they think it's a bad idea? Does it not apply to them? Is it too expensive?

Actually, most employees have the perception that the company has a strong culture and identity but engineering doesn't really fit in it. It was research made by HR. I could ask employees themselves, or HR.

What's being done to infect engineering with the right culture? Culture is automatic. A year or so ago, at my place of employment, software engineering and customer support were newly seated together, almost mixed in together (it's not too noisy, which was my only concern when the idea was suggested - customer support probably fields a half-dozen phone calls a day; they do most of their work through logging in to customer sites and over various text chat formats).

The software engineers see (and sometimes hear) support helping customers and talking about the problems and how best to fix things; they see the results of their good work directly, and they see the results of their bad work directly. They have a cup of coffee with their friends in support who deal directly with the customer's requests and complaints. Now, they're one team; it can be seen in how they interact and how they work together. I get eMails from people in support telling me how helpful various software engineers are and what great work they're doing fixing bugs and adding features, and software engineers take pride in doing a good job to help out the person who sits opposite them. They are SO much more plugged in to the needs of the company. Everything works better. They are steeped in the company culture every day.

It was automatic. We didn't have to tell people to pay attention to the other people. We didn't have to tell software engineers that it was bad when they heard support trying to talk a customer through a UI that they just wrote last week. Writing software that met the needs of the customer was no longer an abstract thing; they could see the effects of good and bad software right there every day, cringing when their good friend was having to apologise repeatedly to a customer for something not working properly and taking pride when a support engineer passed on good words from a happy customer who had received a bugfix. You can't turn culture into process to be followed; so how are you ensuring that your culture is infecting the engineers?

Culture is learned from the people around you. Is your engineering team isolated? Are they simply repeating bad behaviours to each other? Can they see the consequences of doing a bad job? Can they see the consequences of doing a good job? Do your engineers actually have the chance to learn culture, or instead do they just have processes?

What is this strong culture? In what ways do other parts of the company feel engineering doesn't reflect this culture? If you asked the engineers, what would they say the company culture is? How do they feel about the rest of the company and the culture outside of engineering? It sounds like you actually have at least two different cultures in the company. That isn't necessarily a bad thing but if it is causing problems then the failure is in leadership.

The first thing I'd recommend is a round table discussion or other feedback mechanism from the engineers themselves. Based on that feedback someone in leadership will need to make some decisions and see that they're enforced. Lots of other people have discussed the type of decisions that may need to be made so I'm not going to repeat it here.

Do you ever fire engineers for being bad at their job? Or for being divisive and spreading a bad attitude?

I'm wondering if that doesn't happen at your org. And if not, that'd be a big negative impact on morale.

We do. We promote and fire based on both performance and cultural evaluations.

Engineering had some firings in 2017, and we were supposedly left with the best ones.

Problem is, things took a 180 curve somewhere, and it became rough in 2018. Maybe management is to blame, but we changed that too and it kept getting worse.

Consulting and “product engineering” are very different in the culture they require to be successful. From your description it sounds your culture is consulting heavy.

Read the books by Rands to understand the difference. And his blog posts about engineer personalities and group dynamics.

http://randsinrepose.com

Thanks for the suggestion, I'll order it!

So.. when you implemented stack ranking and a cutthroat Survivor-island-style “how can you make sure the other guy gets the axe and not me” culture, morale took a nosedive and people started bailing on you? Interesting.

I upvoted you because you have a completely valid point, but I don't think this is the case here.

The people that were fired had some really bad performance, and the team itself agreed on the metrics beforehand. Also, it took about a year after they were fired for the problems (other than their slowness) to start.

Did some major management change happen in your company, recently?

I've seen this happen, and many people just didn't like where things were going, and how (the "how" was particularly influential, needless to say).

We had two changes recently. Managers were fired because the team wasn't performing well at all and failed key deliveries.

Oh, we're also in our fourth product manager in three years. The previous three left because they were (of course) unable to deliver.

Why would you fire a product manager for being unable to deliver if the team is not delivering?

I’d probably only be concerned if they were delivering the wrong things (e.g. if business requirement <-> feature translation goes wrong).

> Why would you fire a product manager for being unable to deliver if the team is not delivering?

Yeah, that's something I also don't understand.

Honestly, I'm a bit inclined to think there is a problem with engineering, since they were able to test lots of different strategies and group dynamics in the last three years, and none of them has worked so far.

I'm struck by the way you threw out two totally different types of complaints.

Some people will always complain about too much micro-management and macro-management - that's fairly normal. Some people will always not like the guys on the other team, etc. Bugs will happen. Good managers can alleviate these problems and hiring experienced professionals (with the associated price tag) and making a concentrated effort will usually do the trick.

On the other hand, complaints about not having a minimum level of respect in the workplace (complaints about sexual harassment and racism) are a huge problem. If you have multiple people leaving because of sexual harassment or racism, you need to find out who the hell is acting inappropriately and fire them. Make sure your HR is up to snuff; remind employees of the appropriate ways to report these problems; and act appropriately when you receive reports.

Employees will deal with not liking everybody. Money and calm managers will do the trick. Employees leave immediately when they feel they aren't getting the basic level of respect required by law in the workplace (and sometimes file expensive lawsuits).

> Employees will deal with not liking everybody. Money and calm managers will do the trick.

Woah. That's the money quote for me.

Now that you mention it, we haven't had calm managers in engineering in a while. The recent managers were always extremely angry or anxious, and always afraid not to make progress or making mistakes. I believe those fears trickled-down to the rest of the team, changing the whole group personality.

Money is not really a problem (we just had another seed round), but we lack calm managers, indeed.

> On the other hand, complaints about not having a minimum level of respect in the workplace (complaints about sexual harassment and racism) are a huge problem.

> Employees leave immediately when they feel they aren't getting the basic level of respect required by law in the workplace (and sometimes file expensive lawsuits).

Sorry for not being clear. The complaints of sexual harassment and racism were dealt with appropriately. HR dealt with the offender by firing him and nobody was surprised.

However, I wonder if you're also talking about rage outbursts, screaming during work hours and inappropriate e-mails. Because this is the kind of thing HR (and the rest of the company) is having trouble dealing with.

> rage outbursts, screaming during work hours

I've been working as a software engineer at a big corp for four years, I've never even heard anybody shout, or anything that could be considered a rage outburst. Sometimes the volume goes up a little in meetings. I've heard of one or two people yelling through the grapevine, but I didn't personally observe it. In general, I don't think shouting has any place in a workplace. However, I also wouldn't fire somebody immediately for shouting once - a conversation with their manager and recommendation to take a few days off to unwind is a reasonable reaction to a single incident.

> Inappropriate emails

Can you be a bit more specific? My workplace sees a fair number of testy emails "X is totally fucking wrong" / "X totally shouldn't have been done without consulting me" but from experience, peoples perception of what an inappropriate email is varies widely.

I completely agree with your first point. We don't really have reports of people shouting with each other outside of engineering, and that's why people don't really know what to about that.

> Can you be a bit more specific?

Testy is a good adjective for them. One of the worst contained profanities, but was sent using personal e-mail accounts (but it was sent from work and was about work).

There were some company-wide e-mails with thinly veiled criticism and passive-aggressive remarks regarding the (bad) work of other engineerings teams. People pointing fingers and trying to assign blame.

> personal e-mail accounts

That's a bit surprising. A lot of the things you're saying (shouting, using personal email for work, rage emails) should only happen once per person maximum. When it happens, a calm conversation with a manager should explain that this behavior is detrimental to the success of the company. If it keeps happening, people need to go. Set the standard to separate the bad apples from the batch and then remove the bad apples.

> thinly veiled criticism and passive-aggressive remarks

Unfortunately, this is the life sometimes. It should be discouraged. But, these are probably symptoms of work related problems (lack of expertise, lack of clear responsibilities, managers who escalate rather than de-escalate situations) rather than pure conduct problems. Solving them requires patience and working the problem.

> A lot of the things you're saying (shouting, using personal email for work, rage emails) should only happen once per person maximum.

Indeed. Problem is, HR is desperate because everyone is engaging in such behavior. Which makes the rest of the company to think that it is a systemic rather than an individual problem.

> But, these are probably symptoms of work related problems (lack of expertise, lack of clear responsibilities, managers who escalate rather than de-escalate situations) rather than pure conduct problems.

Thanks for that. Indeed, those things might be the root causes of the problems the teams are facing.

> rage outbursts, screaming during work hours and inappropriate e-mails... is the kind of thing HR (and the rest of the company) is having trouble dealing with.

This is a major red flag. It's either a symptom of the underlying issue, or the root cause itself.

1) It could be a symptom of the underlying issue, which is typically stress-related. "Shit rolls downhill" approach to management, unrealistic deadlines, fear of mass layoffs, etc.

2) Much more rarely, but it does happen, it could just be someone with an abusive personality. Those sorts of people are capital-T Toxic to your organization and will definitely result in your best people leaving. You want them gone, yesterday.

Start by assuming positive intent and looking at option 1 rather than option 2.

I provide consulting for organizations about engineering teams and culture and it seems like you might benefit from that. I'd be happy to have a free call with you if you'd like to talk further. My contact info is in my profile.

> 1) It could be a symptom of the underlying issue, which is typically stress-related. "Shit rolls downhill" approach to management, unrealistic deadlines, fear of mass layoffs, etc.

Yep, there were some talks among engineers about the possibility of them being laid off and replaced by another team. But that's far from the case, as they've been repeatedly told that's not going to happen, have all gotten raises, stuff like that.

I could go with the unrealistic deadlines, which is something half of the team complains about, but the other half complains of the opposite. It's hard.

The whole team agrees that they're under-performing, though, which might be the reason for the fear of being laid off.

The "shit rolls downhill" thing is exactly the kind of thing all the previous managers did. I'd like to think that they stopped doing that, but that has left some scars on the team.

---

> 2) Much more rarely, but it does happen, it could just be someone with an abusive personality. Those sorts of people are capital-T Toxic to your organization and will definitely result in your best people leaving. You want them gone, yesterday.

The worst ones were already removed, but they seem to have caused lasting damage. We should see how it goes.

---

> I provide consulting for organizations about engineering teams and culture and it seems like you might benefit from that. I'd be happy to have a free call with you if you'd like to talk further. My contact info is in my profile.

Thanks, I'll definitely talk about it with our CEO and CTO.

In a dysfunctional situation (which, sad to say, it sounds like you could have), the first thing to go is trust. And when that happens, management statements are no longer believed. Ironically, the more you say about not planning layoffs, the more that can be taken as proof that layoffs could happen.

Similar with the scars from previous management and toxic employees. That history isn't quickly forgotten, even if the perpetrators are gone. That sort of abuse can be self-propagating: it becomes a learned behavior that turns victims into new abusers.

The good news is that you can recover, but it takes time and effort.

> That sort of abuse can be self-propagating: it becomes a learned behavior that turns victims into new abusers.

That makes a lot of sense. Come to think of it, we started having those problems after a string of very aggressive or very anxious managers.

One approach to try is to physically integrate engineering with the rest of the company. If there's engineers that work on sales tools, have them work next to the sales group. Secondly get engineers more involved in other parts of the company. If marketing is having a team offsite, send an engineer that works on that tech with the team. Get engineers involved in business-related meetings where they can learn both the culture and customers. If engineering is acting like a disorganized, isolated group in the company, it's often (in my experience) because management has created structures that keep them feeling isolated and without a sense of ownership/belonging. The later is important for feeling organized... if some engineers feel like things are too slow or too fast, it's probably because expectations are not well defined or understood. Signals are getting crossed somewhere before they get digested by engineers. Perhaps you need more experienced engineering managers who know how to best organize teams and can act to encourage the company's culture.

> If engineering is acting like a disorganized, isolated group in the company, it's often (in my experience) because management has created structures that keep them feeling isolated and without a sense of ownership/belonging.

OP here.

This is an extremely interesting insight.

Now that I think about it, engineers were indeed isolated for a long time, because PO and UX people were the ones doing all the talking with stakeholders and users "because this is the way it is supposed to be done".

This is probably both the reason they're actively isolating themselves and the reason the morale is low.

Thank you.

I've been brought in several times to situations like this. Worst-case was the team that not only moved to their own building, but they set up a gated security system where the other folks couldn't get in.

The technical checklist above is awesome, but no amount of technical chops is going to fix that.

Your company should be an engineering team, some of which can't code very well, that also kicks ass in whatever field you're in. That's probably a big mental leap! But it's where you have to go.

Tear down the barriers and integrate engineering as tightly as possible with the "real" work. Hint: whatever you do, you can do more. Put coders on the customer support phones. Rotate people through the teams as SMEs. Physically put them in places where they rub elbows with other groups. Got a bug in a CSR app? Bring in the folks affected and have them personally explain the impact to the team.

I could go on, but I'm just winging it. Whatever you do will depend on what your company does and what the people are like -- how willing they are to change.

Finally, and the people that do the work I do are going to hate this, be ready to fire people. Bad cultures grow employees with horrible attitudes that many times cannot be fixed. Not every bad culture situation can be fixed with magic sauce. Experience shows it only takes one person with a bad attitude in a group as large as 50 to destroy positive momentum.

In general, if you want to rock, the people that code should live inside the heads of the people who find and grow value for the org.

Once you get the social walls down, work on the technical stuff. Otherwise you'll just make more arrogant tech teams.

Funny, the previous manager actually wanted a gate with a keycode to avoid anyone from ever coming.

> Your company should be an engineering team, some of which can't code very well, that also kicks ass in whatever field you're in. That's probably a big mental leap! But it's where you have to go.

> Tear down the barriers and integrate engineering as tightly as possible with the "real" work. Hint: whatever you do, you can do more. Put coders on the customer support phones. Rotate people through the teams as SMEs. Physically put them in places where they rub elbows with other groups. Got a bug in a CSR app? Bring in the folks affected and have them personally explain the impact to the team.

This is kind of amazing to read, and a great idea to reorganize the team. Would surely solve our cultural problems, and would actually free time from the programmers. Makes a lot of sense.

> Once you get the social walls down, work on the technical stuff. Otherwise you'll just make more arrogant tech teams.

That's interesting to read and makes a lot of sense. Thank you.

This sounds like people coming from an enterprise instead of startup background to me.

I like all the ideas here but putting me next to sales is a surefire way to leave me disgruntled. I can barely tolerate these open office layouts in general, much less with people making phone calls all day next to me.

As an engineer, things that would help me:

Flexible work from home policy. If you get your work done, you go home, and no one looks at you weird for leaving at 5:30 after staying late the evening prior. Noise cancelling headphones.

Like the parent here said, more integration with the company. I want to celebrate successes, have input on projects, and know my coworkers. I don't want to be a task hamster running on a wheel of endless tickets.

Strong engineering culture. Design reviews. Code reviews. CI/CD in place. Intelligent people around me who are excited about engineering.

Everything not always being a rush or on fire. On call duties limited. Deadlines not always impending and looming.

Healthy work life balance.

Benefits for things like education and gyms.

Am I spoiled? Sure. But that's the world we live in.

> Like the parent here said, more integration with the company. I want to celebrate successes, have input on projects, and know my coworkers. I don't want to be a task hamster running on a wheel of endless tickets.

This is an interesting idea and might work really well!

Currently the hamster wheel ticket thing is a demand from engineering, but maybe suggestions for changes would be welcomed by the team.

The other things, we sorta have it all, I think? I asked a friend about the Spolsky Checklist and we pass it.

This post is a bit vague to give any real advice. Best place to start would probably be the exit interviews. Fix the problems that made them leave. I'd also start taking look at the engineering leadership. Ideally, someone should be having frequent one on one meetings with the engineers to prevent problems getting to the point where someone quits.

If you focus on increasing engineering quality, retention will follow.

> there's still an astounding number of bug reports for a simple app.

Why don't you reverse engineer some of these bugs and see how & when they were introduced. What step in your development workflow should have caught those?

> The development process is indeed slow and full of fail-safes

I have seen engineers who focus on less meaty stuff in code reviews (language semantics, coding conventions, naming etc) and miss out on system design, regression, logical mistakes etc. Former takes less mental effort & is limited in it's usability while latter takes time/energy but is worth the price. See if this is happening in your organisation.

> how they actively engage in bickering and in-fighting between their own teams

My guess is some of your engineers are less focused on product/features/customers and more on the stack/technology/tools they are using. I don't know how to change this (lead by example maybe?).

Sounds like a communication / planning problem. What is your process of planing and carrying out a project and are those processing being properly carried out?

It sounds like the engineering team don't have a clear vision of what they are supposed to build. This leads to them building the wrong thing. The people who wrote the initial brief don't see a problem with it but do see the engineering team struggle with the project, not knowing how to explain their vision they resort to micro-management.

Having a non engineering person trying to manage an engineering problem at a micro level will result in all the problems you describe. The developers are missing the big picture and will have to guess, redevelop, then test it on the non-engineering person, repeat until they say yes. This introduces bugs and tones of useless code.

My advice would be to set expectations and have a clear roadmap. I agree with comments who identified the lack of leadership.

The point of setting the expectations might solve a bit of "we are moving too slow/too fast". The arguments from both teams that you mentioned are valid because it sounds to me there were no expectations or clear vision of the final product.

An example of setting expectations would be:

- We have feature A.

- Its based on feedback from clients (X,Y and Z).

- This will save the user 30% of the time.

- We need an MVP or proof of concept in 12 weeks.

Now what the above will communicate to engineers:

- Its fine to make short-cuts and workarounds.

- Its time bounded.

- We will get more feedback when it is done then we will iterate and refactor, or even write from scratch.

- We will learn from it and get insights to make better decisions in the future.

Also, hire a VP of engineering which will have a fresh look at the team, spot the bad apples and build engineering culture.

Sounds like a great plan to solve the "too fast/slow" problem.

It is true that some teams in engineering work with an MVP mindset, while others work in a waterfall/enterprise pace.

Maybe it's up to upper-management and C-levels to iron this out.

> Maybe it's up to upper-management and C-levels to iron this out.

Always.

Obviously the first question to address is whether you are offering truely competitve pay, that should be addressable with some research and leg work.

The second, harder thing to look at is whether you are encouraging a culture where people can give honest feedback without fearing repercussions. While there may be a myriad of reasons you are receiving from employees on the way out, it is useless to try to respond to that feedback: you've already lost those people.

People leave jobs for tons of different reasons. Some are in your control, some are personal. There are some reasons you should address, and some you should just let go. What matters is that you address the ones you can before it's too late.

Well, I’d say the first thing to fix is to talk to them and ask them why they find value in being in a separate building and why they don’t want to talk to their customers. Without strong management, it’s possible it’s because their customers aren’t correctly handled. As for the application, it’s the same thing.

Your engineering team has poor management (though I’d be surprised if it were just them). If you have a Product team, they need to all go.

Assuming that the problem is as stated and I can’t talk to anyone to get a gauge of the situation, here’s what I’d do:

* get rid of Product

* optionally reorganize around conceptual product lines, optionally with separate core services teams if required whose customers are the product developers

* ask engineering to move to some rapid iteration cycle process with demos at every sprint or unit of development cycle

* ask customer teams to send representatives to review demos

* hire the minimal number of PMs to mediate those interactions and to sell engineers on the problems the customers have, providing insight into what their ‘market’ wants, and show how well they’re doing it. They have to believe in the fact that the product is providing someone somewhere value

* make an engineer the ruler of every engineering team’s backlog. prioritization is done with the assistance of the PM’s expertise.

* only production showstoppers go to the OC queue for hotfix, the rest go into the backlog and are prioritized or left to remain in the software

* hire engineers with experience at high salaries and use them as role models

* if you can collocate engineers with non-engineers that would be great. Everyone has to be respectful of each other’s environment, though, so if you have a problem with self-awareness this is not great. (E.g. chatty teams aren’t good next to quiet teams, phone calls are not great near engineers, etc.)

You have a product ownership problem and an interaction problem. Your management is likely crap.

Weak diagnosis but imperfect information so just consider that a low probability Bayesian estimate.

> * get rid of Product

> You have a product ownership problem and an interaction problem.

This is very surprising to hear, but it aligns with other replies here. Your rationale is also sound. I indeed believe that most of our problems around complexity stem from our product team.

---

> * ask engineering to move to some rapid iteration cycle process with demos at every sprint or unit of development cycle

This is what half of engineering is trying to do. The other half is a bit more cautious, though.

Others posters have made a point that we can't have both.

---

> * if you can collocate engineers with non-engineers that would be great. Everyone has to be respectful of each other’s environment, though, so if you have a problem with self-awareness this is not great. (E.g. chatty teams aren’t good next to quiet teams, phone calls are not great near engineers, etc.)

Sounds like a nice strategy to change everyone else's perception of engineering.

As a non-engineering manager, the only way you probably have of affecting the engineering group is to voice your concerns to your own management chain (including the CEO, if you're close enough to them), emphasizing how these problems limit the company's revenue and growth potential.

Oh, they're well aware of all that. Also, the CEO knows I'm looking for solutions.

From your posts, it’s clear that the founders and c level are either checked out, or out of their depth. Seems to be more the first one. Maybe the founders already had a nice payday, or were rich beforehand. No solution unless they’re fired or step down.

> had complaints of micromanaging mixed with complaints of lack of management.

These aren't mutually exclusive.

> how they actively engage in bickering and in-fighting between their own teams

Take one of the offenders and publicly shit can him.

> Take one of the offenders and publicly shit can him.

I don't think this will happen because engineers are scarce, and everyone is to blame, kind of.

One of the worst offenders (who sent extremely aggressive e-mails to another team member, all trough personal accounts) left a few weeks ago of his own accord, so HR decided not to pursue him. Now that you mention it, that might have sent the wrong message.

While I don’t think you should fire someone just to set an example, the scarcity of developers is precisely why you should fire those who are negatively impacting the teams and are unwilling to change.

That's a very good point.

You need technical leadership. Pay a lot for someone with a proven track record and let them handle it.

OP here.

Yep, I agree with you. That's good advice.

> Hiring is extremely hard because of economy.

What does this mean? Could you please elaborate?

Translation: We don’t offer much in the way of salary/benefits.

Actually we're pretty OK, BUT yeah, you're right: we'd be hiring faster if we offered more.

I'm a little surprised nobody is calling this out in this thread (assuming you're right). OP claims to be in "one of the biggest startups in our field" but they do not offer competent salaries/benefits? This is the problem and basically every answer in this thread is peripheral. Of course, money isn't everything, but if you're not paying your engineers a competent compensation, you should not expect your competent engineers to stay in your business for years. Free market economies work both ways.

EDIT: I wrote this comment before seeing @thrwwyngnr 's comment. I do not claim they're not offering competent salaries, but if they're not, this is the #1 factor and everything is #n, n>1.

Thing is, the salaries are supposedly competitive and engineers don't really complain about it. We had two raises and a round of promotions in less than a year, and people keep leaving.

If this was true, people wouldn't be leaving.

https://study.com/academy/lesson/herzbergs-two-factor-theory...

Please look here. It is funny you talk about being a MANAGER, I see a problem in hygiene(not the physical one) on your company. Give it a read on hygiene factors, know it well. Check if you are providing them. That is always the reason people leave in hordes. It is that simple.

To be honest, if a company was really paying good salaries, as you claim, respected people(working time/conditions), I would only leave if the management were clowns.

Are you one? I mean. I'm doing more management now and I know how people in management are afraid to seek into their own mistakes and defects and stick to saying like "Everything we do is great! I have no idea why we aren't successful", as doing that takes much less effort and courage than stepping up, finding out problems and really thinking through.

People here in HN have commented a lot of things, but you really negate basic things, such as salary. "salary is competitive", that doesn't mean anything... Most of the companies are competitive, if they are willing to give me a similar salary to avoid all the problems your company currently has, which you even affirmed, why would I still work for your company(and fix its problems) if you wouldn't pay me _above_ the market?

If you gave 2 raises in a year and can't say "we're paying like FAANG or above the market", barely "compatitive", it means your company 1 year ago was underpaying people and that, like a virus, has spread discontent in people. Those things are cancerous, even after they are gone, there is still the trauma. People don't like being underpaid, they feel like losers. That's why they move to other companies, even if you fix the problem.

Sorry, I completely mangled that sentence. I explain it here: https://news.ycombinator.com/item?id=18798786

Thanks for the extra info! I'm really sorry to say this, and this may be naive. Please downvote if you think this is not helpful. But imho:

> [...] or leaving while complaining about different things. All but salary. They had two raises in 2018 and pretty much everyone left got a promotion in 2018.

I'll be honest and guess most people said this probably thought about their compensation. It's not about whether you gave them a promotion, or a raise. If they found a job paying better, with better benefits, they're gonna switch. Now humans aren't robots so you can assume some people will stay in the company for various reasons. But if you see that people systematically leave your company, I think this might mean that you're paying less compared to other tech companies down the street. My 2c. Happy new year!

Not naive. Except maybe I'm the one being naive here. You do have a point.

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.

'Ask HN: How do you fix engineering culture?'

Based on your question, I would start with a mirror.

'but can't keep engineers'

So why are they leaving? Although it could be pay, it is doubtful the prime issue.

'An engineer left us three weeks ago and two more gave notice and are leaving in January.'

Happy people do not look for jobs in December, well not in the states. My guess is, these people must have been very unhappy, and the joy of the season cemented their dislike for your company. Have you looked on glassdoor to see what the employees are saying? I have considered working at two companies that were considered wonderful places to work at but the techie section was considered a hell hole. One of them I really wanted to go to because it just seemed like the perfect company. The other glassdoor told me all I needed to know. Needless to say I did not bother. I suspect it was the engineering management that made life suck there.

'We have a strong culture, but it is widely felt by the rest of the company that the engineering team doesn't adhere to it.'

I read this as, we have a 300 page employee manual and the techies ignore it.

'decision they made to isolate themselves in their own building'

Sounds like a trust issue. Or is it a noise issue? Personally I would never take a job in a noisy environment, and most good techies I know of will not either. Of course they ALL love their own noise... thus the headphones, no speakers rule.

'actively engage in bickering and in-fighting between their own teams'

bickering can be helpful, but the infighting implies a lack of trust in the reward system you have provided.

'extremely limited communication to the rest of the company (users of their products)'

Clearly management failure. But not necessarily Engineering management failure.

'reports of sexual harassment and racism'

in the current environment this can cut either way. You need to look at your turnover. People being harassed for sex, race, other are very motivated to leave. People falsely accused are as likely to leave also. Which ever the case is, you must root this one out to avoid more problems and possible lawsuit.

'There's zero consistency between the message they're sending'

I think your company is not exploring the complaints well enough.

'Some engineers believe the team is moving too fast, while a different group believes they're moving too slow' Yes, I can guarantee that is true. If your management sees this as a problem, then you do not have good management. Or maybe they are not technically competent.

'complaints of micromanaging mixed with complaints of lack of management'

Typically I will complain about this when my management is not technically competent but thinks it is. Generally this is the management is micromanaging me, but not managing those other idiots.

'new flagship application we're building is extremely simple'

You said you are not a manager of the engineering team. But are you an engineer? How do you know how simple it is. Since you know how EXTREMELY SIMPLE it is, why don't you wipe it up this weekend in your spare time? This is a pet peeve of mine. I have had more than a few coworkers who felt everybody else had easy tasks. Amazing when offer to trade work with them they shut up.

'development process is indeed slow and full of fail-safes, but there's still an astounding number of bug reports for a simple app'

Depending on the application it could be reasonable. On the one hand you can have testing generating a lot of bug reports, because the OPINION is different. I have worked at places where we would get bug reports where 30% of them were 'above keyboard errors'.

In the end I see 3 possible fixes:

1) new management - both in engineering and in other departments. In engineering you will need a more technically competent leader. Many engineers will stay to keep learning from a good leader. Other departments need to be lead by people who understand working with engineers.

2) re-examine your reward system. I suspect most feel it reward the 'suck ups' and not the real workers. Because it sounds like your real workers left.

3) try the golden hand cuffs. Many people have stayed for that. But they do not have a passion for the work.

You need to either integrate them into the company or you need a liaison who can serve as a diplomat to mediate their relationship to the rest of the company.

I'm considering quitting my very part-time job at a local non profit. I got involved because I got along well with a long standing member of the board who happened to run their websites. This board member happens to be female, as am I. We met multiple times for about three hours at a time, once a month. I did some pro bono work for the organization and ended up doing some paid work on their websites.

For personal reasons, she's handing off a lot of her responsibilities and no one else wants to talk to me for long periods like she did. I'm doing their websites and it's a tiny town where no one seems to know anything about the web. There are all kinds of misunderstandings and I'm the new kid in town, so I end up getting treated like it's my fault and I'm a dimwit and it's incredibly frustrating. (I don't think they are intentionally mistreating me, but that's how the situation feels to me and I'm not really finding solutions.)

It's extremely part-time, only 4 hours a month, and I'm not charging that much and I'm increasingly just spitting nails and going "You people don't pay me enough for this!"

The female board member was someone willing to take the time to explain things to me about the organization that I didn't know and to listen to me and give me a chance to explain what I wanted to do and why. Then she had strong long standing relationships to others and she could bridge the gap between me and them, so to speak. Without her, I'm beating my head against a wall and wondering why I bother. I could do other things for the small sum of money involved.

The engineers have specialized knowledge. No one else in the company "speaks their language." When you give them tasks imposed from outside, they think you are stupid and crazy and when they can't do what's ask of them because it just doesn't work that way, you think they are stupid and crazy.

You need a "translator" or liaison who can find a way to bridge the gap between the rest of the company and engineering. Someone who can go to them and say "The company needs X" and get told "That can't be done" and hash it out with them to find something that satisfies both departments. Someone with the power to say "Well, okay, what we are trying to do is thus and such" and listen when the engineers run down what your options realistically are, a person who can broker that deal in a way that genuinely respects the requirements of both departments.

That's the actual solution. But it's not easy to implement.

Make them owners / stakeholders in your business.

I applaud your effort to improve your engineering culture as it indicates that you actually care.

This is an important topic to me as I've left several companies as an engineer over the years, some of which are rather well known.

Here are some suggestions simply as food for thought. Hopefully something applies in your case.

- Engineers should ideally be part of the process of building the product. If not already, invite engineers to the UI/Product design meetings and make sure they have active input - or at least one representative. The fact that engineers are in another building doesn't bother me so much when I think about the remote companies I've worked for. That being said, with major communication challenges it might require some initial face to face dialogue.

- Deadlines need to be realistic

Sometimes "simple" things are actually more complicated than one would think. I've seen scrum approaches that just don't make a lot of sense with unreasonable "story points" with strict adherence. Some flexibility needs to be in place to deal with unexpected blockers/issues. In one well known company a friend of mine indicated that they are super strict about story points and he hardly codes at all now since every engineer allocates only a low number of story points so that they can ensure they complete them before the end of the sprint.

- Better understand complexity of the product

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. Try to isolate where the complexity is coming from.

- Promote a test driven culture

Regarding the "astounding" number of software defects, it doesn't seem like the engineering culture promotes unit testing. Consider adding TDD/BDD. Or if that already exists, track down what might be happening here. Maybe the software issues are mostly at the integration level?

- Promote a refactoring driven culture

I once worked at a company where management allocated time only once a year for a few weeks to deal with refactoring due to tech debt over the year. Needless to say there was way too much tech debt to pay off and those weeks were never enough! If the engineering leads say they need to address tech debt, let them have a strong voice in that at least. If time to market is more important so be it but be aware that tech debt can also mean the team is slower in the long run. Changeability of the code will slow everyone down over time significantly if it isn't addressed. For a large codebase we had, changing code was a nightmare because of this.

- Promote more than technical skills

Like most engineers I like to work with highly motivated, open-minded, approachable and friendly people. I've seen incredibly smart engineers stifle and essentially belittle other intermediate/junior engineers over their work or ideas. It just takes 1-3 of these smart engineers to cause bickering/analysis/paralysis in a project. I've joined projects in the past as a senior engineer where I've seen other intermediate/junior engineers quickly gravitate to me for example and feel comfortable asking questions of all sorts - I generally give a vibe of being easy going. My most memorable times at work revolve around tech questions/discussions with other engineers and I don't believe any of that was wasted time for me or the companies I've worked for. If I were to promote/hire a tech lead/architect I would try to ensure soft skill were in place rather than simply technical ability.

Usually management was not very aware the above conditions and and things can become 'normalized' enough such that nothing is ever done about improving things even if you spoke up. I've heard management say things like "we don't all have to be friends" and to just put up with the status quo but I think there is room for both.

- Give engineers a sense of ownership

I used to work at a place where the software architects essentially 'farmed' out JIRA tickets to engineers in such detail that there was no creativity whatsoever that the intermediate/junior engineers needed to have. Giving engineers the room to develop design skills and make mistakes is important.

- Allow and appreciate mistakes

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.

- Create a culture of learning

More often than not, companies don't offer a great balance of "doing the work" and learning. In the past I've had to introduce the idea of tech talks, hackathons myself. Even purchasing books/videos at some companies was seen as an added cost that they didn't want to take on. Regarding tech talks, some companies allow engineers to create presentations during work hours and present them while in other companies I've had to put a lot of hours outside of work to prepare for presentations. Engineers will definitely appreciate the former if possible.

- Walk a mile in another person's shoes

In one company, engineers could sit and listen together with a support specialist once every few months to get a sense of what types of questions customers had about the product. Great eye opener.

Another idea is to allow shadowing of another person throughout the day or even do their job for a day if possible. An engineering manager could do a mini bug fix for example to get a sense of what is involved. I once had my manager's manager's manager put in a code fix in C++ - our team was super impressed not just for the tech skills but more for the fact that he didn't mind getting his hands dirty.

- Management should put their foot down when required

I recently worked at a company where there was a lot of swearing, sexual/racial jokes, etc during work hours as well as company events. The CEO was complacent in such things by saying "Oh, that's Joe, he's always putting his foot in his mouth".

I knew right there and then I would eventually leave. Sometimes management needs to take a stand somewhere.

Especially in the example you gave where there was some racism/sexual harassment if I were the CEO and learned about that I would drop everything I had and iron it out. I'm glad HR ironed that out in your company as you mentioned but I hope also the CEO came down with a message for everyone as well

Lots of good insights here!

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.

Bring in McKinsey

You forgot the /s

One way to make it work is to fire everyone and start from scratch. If the application is extremely simple then I trust it could be built by an external team (i.e. outsourced), while you rebuild the team by hiring/vetting one engineer at a time?

On one hand you can not try to fix people. On the other hand, this applies to managers too.

> One way to make it work is to fire everyone and start from scratch.

OP here.

Now that you mention it, one of the engineers said to me a while ago that the whole team was afraid of that happening during the whole year.

In fact, that might have a lot to do with the lack of morale (despite that never being in the plans of upper-management - quite the opposite, there were a load of promotions).

But it is a solution, indeed.

What management thinks is irrelevant to morale.

What the engineers believe management thinks is relevant. Your last sentence seems to prove a point here.

> What the engineers believe management thinks is relevant. Your last sentence seems to prove a point here.

Yep, you have a point.

And you're absolutely right: I shouldn't have even considered that suggestion, even though I'm not their manager, or even though I'm anonymous.

No need to censor your private thoughts. But beware that many engineers have seen broken promises by management at some time in their career.

So they are difficult to convince that this time it’s different.

You're absolutely right.

And I forgot to thank you for the insight you gave me with your previous post:

> What management thinks is irrelevant to morale. > What the engineers believe management thinks is relevant.

Maybe we should focus on listening more to the engineers, instead of focusing on sending the right messages.

Might seem obvious to anyone outside, but sometimes we need to be reminded of those things. Thanks.

> One way to make it work is to fire everyone and start from scratch.

That will not make it work _at all_

Reply on news.ycombinator.com