37 ms·

Ask HN: How do you fix engineering culture?

• elmerfud 8y ago
  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 8y ago
    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.
    • ohazi 8y ago
      I hear a lot more cases of "disfunctional company struggles to hire/retain good engineers," "non-technical founder seeks engineer to do all the work," etc. than the converse (firms with good engineering talent struggling to find good management). So maybe engineers are special? They can certainly afford be more choosey about who they decide to work for. It probably makes sense for a company to treat engineers as special if engineering is a critical part of the business. No good engineer is going to want to work for someone with an attitude like yours.
      • shanghaiaway 8y ago
        Sounds like you're in a filter bubble. Can't have good engineering without good management.
        • deleted 8y ago
          [deleted]
        • ohazi 8y ago
          > Can't have good engineering without good management. This is not even remotely true.
          • whb07 8y ago
            One could have a “good” engineer but the engineering team/dept/section will be lackluster. A strong engine without a rudder is meaningless and vice versa. There is a reason why leadership of teams/section/department etc has the responsibilities and accordingly higher pay.
• jadbox 8y ago
  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 8y ago
    > 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 8y ago
      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.
• IpV8 8y ago
  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 8y ago
    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.
  • Mc_Big_G 8y ago
    This list needs automated testing added to the top.
• greenyoda 8y ago
  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 8y ago
    Oh, they're well aware of all that. Also, the CEO knows I'm looking for solutions.
• Gibbon1 8y ago
  > 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 8y ago
    > 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.
    • insiderknowled 8y ago
      It doesn't really matter that it's everyone's to blame. 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.
      • throwaway123322 8y ago
        This happened at our company too and really engineers do respond to this. 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.
• evadne 8y ago
  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.
  • purple_ducks 8y ago
    > One way to make it work is to fire everyone and start from scratch. That will not make it work _at all_
  • thrwwyngnr 8y ago
    > 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 8y ago
      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 8y ago
        > 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 8y ago
          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.
• dogweather 8y ago
  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 8y ago
    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 8y ago
      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 8y ago
        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.
    • jpfr 8y ago
      Consulting and “product engineering” are very different in the culture they require to be successful. From your description it sounds your culture is consulting heavy. Read the books by Rands to understand the difference. And his blog posts about engineer personalities and group dynamics. http://randsinrepose.com http://randsinrepose.com
      • thrwwyngnr 8y ago
• TagAsDelusion 8y ago
  sounds like quite a blamestorm
• will4274 8y ago
  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 8y ago
    > 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.
    • 8y ago
• AlexanderNull 8y ago
  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 8y ago
    > 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.
• EliRivers 8y ago
  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 8y ago
    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.
    • EliRivers 8y ago
      What's being done to infect engineering with the right culture? Culture is automatic. A year or so ago, at my place of employment, software engineering and customer support were newly seated together, almost mixed in together (it's not too noisy, which was my only concern when the idea was suggested - customer support probably fields a half-dozen phone calls a day; they do most of their work through logging in to customer sites and over various text chat formats). The software engineers see (and sometimes hear) support helping customers and talking about the problems and how best to fix things; they see the results of their good work directly, and they see the results of their bad work directly. They have a cup of coffee with their friends in support who deal directly with the customer's requests and complaints. Now, they're one team; it can be seen in how they interact and how they work together. I get eMails from people in support telling me how helpful various software engineers are and what great work they're doing fixing bugs and adding features, and software engineers take pride in doing a good job to help out the person who sits opposite them. They are SO much more plugged in to the needs of the company. Everything works better. They are steeped in the company culture every day. It was automatic. We didn't have to tell people to pay attention to the other people. We didn't have to tell software engineers that it was bad when they heard support trying to talk a customer through a UI that they just wrote last week. Writing software that met the needs of the customer was no longer an abstract thing; they could see the effects of good and bad software right there every day, cringing when their good friend was having to apologise repeatedly to a customer for something not working properly and taking pride when a support engineer passed on good words from a happy customer who had received a bugfix. You can't turn culture into process to be followed; so how are you ensuring that your culture is infecting the engineers? Culture is learned from the people around you. Is your engineering team isolated? Are they simply repeating bad behaviours to each other? Can they see the consequences of doing a bad job? Can they see the consequences of doing a good job? Do your engineers actually have the chance to learn culture, or instead do they just have processes?
• paradigm-shift 8y ago
  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
• alexashka 8y ago
  You need technical leadership. Pay a lot for someone with a proven track record and let them handle it.
  • thrwwyngnr 8y ago
    OP here. Yep, I agree with you. That's good advice.
• DoreenMichele 8y ago
  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.
• sloaken 8y ago
  '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.
• ken 8y ago
  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.
  • scottdwitt 8y ago
    QUESTIONS: 1) Does your company have a solid Business Strategy? 2) Does everyone in the company understand and support this Strategy, and know how they contribute to it? 3) How do individuals know when their decisions and actions are aligned with the Strategy and contributing to the company's success?
  • thrwwyngnr 8y ago
    > 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.
• gnulinux 8y ago
  > Hiring is extremely hard because of economy. What does this mean? Could you please elaborate?
  • paulcole 8y ago
    Translation: We don’t offer much in the way of salary/benefits.
    • thrwwyngnr 8y ago
      Actually we're pretty OK, BUT yeah, you're right: we'd be hiring faster if we offered more.
    • gnulinux 8y ago
      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 8y ago
        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 8y ago
          If this was true, people wouldn't be leaving. https://study.com/academy/lesson/herzbergs-two-factor-theory-hygiene-factors-motivation.html 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.
• lsc 8y ago
  >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.)
  • thrwwyngnr 8y ago
    Let me preface my message by saying that you're absolutely right. If we're having a problems hiring people, the solution is simply to raise salaries. I completely agree with that, period. That's probably the simplest and most obvious solution to our hiring difficulties. --- Now, the paragraph you quoted from me is a bit weird indeed. I'll try to explain what I wrote: We can't keep the engineers working with us because they're either getting fired for some reason, or leaving while complaining about different things. All but salary. They had two raises in 2018 and pretty much everyone left got a promotion in 2018. Hiring is *harder because the economy is strong again, so we have a smaller pool to hire from. But this has never been a problem before. Problem is, people is leaving too fast.
    • lsc 8y ago
      >We can't keep the engineers working with us because they're either getting fired for some reason, or leaving while complaining about different things. All but salary. They had two raises in 2018 and pretty much everyone left got a promotion in 2018. I think money is more than that, though? I mean, I... almost agree with what I said when I said "to translate this into manager speak" - Like, the differences between how Engineers were treated in the '90s and early aughts, and now... I think it's mostly that we get paid like two to four times what we did, and because of that[1], the non-technical people we work with now treat us with a whole lot more respect than they used to. I mean, I personally see the same thing looking at friends who are moving up through the less well-paying portions of the tech sector. Its like it's hard-wired into people that they can treat people they pay poorly worse than they treat people who are paid well.[2] I think there is also this very strong cultural norm that we shouldn't talk about money or especially we shouldn't complain about money. Like as a technical individual contributor, we need to pretend that we are doing this because we love it rather than because it pays really well. I even feel it in myself, sometimes, (though I think it's fundamentally better for us, as workers, to talk about compensation in an open sort of way) - I mean, don't get me wrong, I love doing what I do, but if someone offers me a bunch more money to do the same thing? Yeah, that's hard to turn down. But I mean, my point here is that if someone else offers a bunch more money, a lot of people, when asked why they are leaving, are going to talk about non-monetary stuff, even if it really was mostly about the money. But also, like I was saying above, I think that if you aren't paying as much as the competition, you almost certainly aren't treating your people as well in non-monetary ways. I really do think that if you want a business oriented person to treat someone else better, you pay that someone else more money, because that's what business people are hard-wired to respect. (If you want an Engineer to treat someone well, you point out something technically difficult/that requires a great deal of intelligence that person has done) I mean, I suppose I'm not being that helpful, just 'cause if you felt like you could pay these people more, you probably would. The FAANG companies are paying a lot to regular individual contributor engineers, and that's just really hard to compete with. https://www.paysa.com/salaries/google--software-engineer-3 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.
• shanghaiaway 8y ago
  Bring in McKinsey
  • gaius 8y ago
    You forgot the /s
• volkisch 8y ago
  Add more males.
• factorialboy 8y ago
  Make them owners / stakeholders in your business.
  • deleted 8y ago
    [deleted]
• scarejunba 8y ago
  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 8y ago
    > * 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.
• Oras 8y ago
  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 8y ago
    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 8y ago
      > Maybe it's up to upper-management and C-levels to iron this out. Always.
• solatic 8y ago
  > 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 8y ago
    > 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.
• sokoloff 8y ago
  > 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.
• heelix 8y ago
  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.
• _ah 8y ago
  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.
• rajacombinator 8y ago
  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.
• amirathi 8y ago
  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 8y ago
  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.
• dyeje 8y ago
  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.
• wj219 8y ago
  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.
• quickthrower2 8y ago
  > 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.
• EnderMB 8y ago
  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.