Ask HN: How do you fix engineering culture?
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.
142 comments
[ 3.0 ms ] story [ 215 ms ] threadIf 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.
Engineers are not special.
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.
Can't have good engineering without good management.
This is not even remotely true.
There is a reason why leadership of teams/section/department etc has the responsibilities and accordingly higher pay.
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.
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 many positions for sw. engineers and so little experienced professionals to fulfill all those job openings, at least in my zone.
Wouldn’t have expected italy to be much different
Note that I don't live in Germany so my numbers may be wrong, in that case well... let me know :)
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.
Expecting every employee to be good at every job is just dumb.
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.
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.
> 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.
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.
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.
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 still find the original holds up pretty well in many environments.
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.
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.
Just find the biggest offender who has pissed off everyone.
Make an example out of him. Completely redicule him in front of others and even throw their belongings on the floor. Use most profane language, Steve Jobs style. Make sure you explain loudly why he is being treated like this and leaving the company.
To make it clear, yell at him, "so you want to be a rebellious tech bro?"
Be careful why doing this:
1. Make sure your example person is a man because people sympathise more with women
2. Make sure he looks unfriendly because people sympathise with friendly people.
You want people to comply, be an authority who they fear.
When this happened to one guy on friday, next week on Monday everyone took ownership of their work and started organising better and collaboration shot up.
And to the OP of this thread. No one here will tell you anything that works because that would be politically incorrect and receive backslash from the receivers od this treatment.
On this forum, majority are engineers who don't know anything about management. So any pro management shit will be downvoted to oblivion by labour class engineers.
You are at a wrong place asking for advice op!
This forum only helps with job hoping/getting company to pay you more/ negotiating less work hours.
yeah, they were all sending resumes out over the weekend
This is the kind of management behaviour that erodes trust. Destroys teams. Stops people thinking about what's best for the company and has them thinking only about how to protect themselves. Team members turn on each other. Every bug becomes a blame game. The good people look for new jobs to move on to. People write anonymous blog posts about the company and how this manager had a screaming fit and trashed some guys desk while firing him; every potential customer googling the company reads it and watches the footage on youtube if someone was fast with their phone.
If someone is slowly eroding the motivation of your other engineers, then you should get rid of them for both your sakes (they probably hate working there anyway).
Then what is the behaviour you are talking about here? I must be missing something.
Picking someone almost at random to fire.
Humiliating and ridiculing him publicly.
Yelling and screaming and throwing a tantrum.
Throwing his private property over the floor.
Swearing at him throughout.
That behaviour. That is shockingly incompetent behaviour that causes huge amounts of damage. Everything that "insiderknowled" said. His post is dead; maybe you can't see it? Here's what I see: https://ibb.co/TByZw8J
> 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.
Oh well. Yeah, I completely agree with your post given the original. Hard to think that it wasn’t a joke.
If someone did this in front of me, I would immediately start privately advocating for their removal from the company.
Yeah, that's not gonna fly here at all.
Because I think the person above you is just talking about letting people go.
Publicly shitcanning. It's illegal here.
On one hand you can not try to fix people. On the other hand, this applies to managers too.
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 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.
So they are difficult to convince that this time it’s different.
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.
That will not make it work _at all_
I'm wondering if that doesn't happen at your org. And if not, that'd be a big negative impact on morale.
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.
Read the books by Rands to understand the difference. And his blog posts about engineer personalities and group dynamics.
http://randsinrepose.com
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.
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).
Oh, we're also in our fourth product manager in three years. The previous three left because they were (of course) unable to deliver.
I’d probably only be concerned if they were delivering the wrong things (e.g. if business requirement <-> feature translation goes wrong).
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.
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).
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.
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.
> 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.
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.
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.
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.
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.
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 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.
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.
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.
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?
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.
> 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.
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.
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.
You're have a good point. Maybe after one year things will be different.
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.
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.
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?
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?
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.
Yep, I agree with you. That's good advice.
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.
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 fr...
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.
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 w...
(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.
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?
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.
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.
What does this mean? Could you please elaborate?
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.
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.
> [...] 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!
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.
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.)
---
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.
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.
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.
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.
> 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.
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.
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.
Always.
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.
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.
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.
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.