
Ask HN: How do you fix engineering culture? - thrwwyngnr
I&#x27;m a manager in one of the biggest startups in our field. We&#x27;re currently big in consulting, but we&#x27;ve been trying to move into SaaS.<p>Problem is, we&#x27;re growing, but can&#x27;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.<p>We have a strong culture, but it is widely felt by the rest of the company that the engineering team doesn&#x27;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.<p>There&#x27;s zero consistency between the message they&#x27;re sending. Some engineers believe the team is moving too fast, while a different group believes they&#x27;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&#x27;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&#x27;s still an astounding number of bug reports for a simple app.<p>Has anyone dealt with such a situation and has some advice?<p>EDIT: I&#x27;m a manager but I&#x27;m not in the engineering team itself.
======
lsc
>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.)

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

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

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

------
IpV8
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?

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

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

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

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

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

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

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

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

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

~~~
Matthias247
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

~~~
qualsiasi
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 :)

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

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

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

~~~
scottdwitt
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?

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

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

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

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

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

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

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

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

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

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

------
EliRivers
_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?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

------
amirathi
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?).

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

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

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

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

Always.

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

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

~~~
thrwwyngnr
> * 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.

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

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

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

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

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

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

~~~
thrwwyngnr
That's a very good point.

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

~~~
thrwwyngnr
OP here.

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

------
gnulinux
> Hiring is extremely hard because of economy.

What does this mean? Could you please elaborate?

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

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

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

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

[https://study.com/academy/lesson/herzbergs-two-factor-
theory...](https://study.com/academy/lesson/herzbergs-two-factor-theory-
hygiene-factors-motivation.html)

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.

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

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

------
factorialboy
Make them owners / stakeholders in your business.

------
paradigm-shift
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

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

------
shanghaiaway
Bring in McKinsey

~~~
gaius
You forgot the /s

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

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

~~~
jpfr
What management thinks is irrelevant to morale.

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

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

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

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

