19 ms·

How to drive away your best engineers

• sharmin123 4y ago
• deleted 4y ago
  [deleted]
• pikaynu 4y ago
  I totally agree with this. I am in a situation right now where the skip level manager is asking to schedule meetings every other day to talk on a problem that requires research. They want to talk about a solution and not letting us find one. Another one is defining aggressive timelines when I don't even know what to solve. Obviously the timelines were shot to hell in the worst way possible.
  • hotz 4y ago
    In the same boat. It's painful, whenever a bug appears or there's something they don't understand; boom! A meeting gets scheduled. It kills the soul nevermind productivity. The other one is having to answer the same questions over and over. When you're about to go to production, tests have been written and everyone's done their part, you'll get asked, "so you're sure nothing will break production?" It blows my mind.
  • theshrike79 4y ago
    It's a mentality and culture difference. Manager-type people solve issues by having meetings, lots of meetings. Their work is accomplished in the meetings. The can have 7 meetings on the same day, each about a completely different subject and still manage to get something done. Programming on the other hand requires uninterrupted blocks of time. Working on 7 projects on the same day just means you have 7 projects that didn't progress. Having to sit in a meeting every other hour means you're not getting anything done between meetings because context switching takes time.
  • wildrhythms 4y ago
    > defining aggressive timelines when I don't even know what to solve I love this one. Someone is desperate to build a Kanban board to show their manager; who cares if the underlying projects are imaginary!
  • summertime42 4y ago
    In the nicest way possible, get those meetings canceled. Show initiative by simply saying "I will provide an update by the end of the week; let me do my research first." If the skip-level is refusing to stay out of your lane and not let you do your job, it might be time to dust off the resume. Thankfully, the market is crazy hot for anyone not a junior. Still, that sounds bloody awful; I am sorry you are going through that. :/ And in the best way I can say this, but deadlines don't matter if they are not set by your engineers AND accounting for the time to add unit tests/integration tests/bug fixing/clean code. I've inherited plenty of salvage projects with terrible codebases that eventually get scrapped wholesale and redone from scratch - so if someone tells me to cut corners for bullshit deadlines, I'll push back with those stories and keep the course. Call me cushy/inflexible/unrealistic, but I refuse to write a salvage project of my own.
• lloydatkinson 4y ago
  Specifically about managers that don’t have technical abilities - installing “agile coaches” as the scrum master and other Big Agile TM nonsense. Maximum micromanagement and a team getting ever more exhausted and demoralised.
  • hotz 4y ago
    I've lost hope of anyone at the top figuring it out.
  • woutr_be 4y ago
    The previous big bank I worked at did this all, they had an agile coach and multiple scrum masters. The agile coach would essentially sell agile to management, and then blame development teams for not delivering what he sold. Building a product almost became irrelevant. We seriously had a full day of sprint planning. Even had meetings where we had to deliver a feature in two weeks, and the agile coach put us all into a room to figure out how we could use agile to deliver this. He also constantly pushed his technical implementations, despite being a non-technical person. I believe of the 12 devs across two different teams, only one of them remains at the company today. My first instinct was try and fight it, try to explain why this wouldn’t work. But you quickly realise the agile coach wasn’t there to help development teams, he was there to sell agile, so he could remain employed.
    • abacadaba 4y ago
      Just 1 day? pfft
• LaurensBER 4y ago
  Not included in this list but definitely worth mentioning; - Lowering your hiring bar. When you hire people the burden to get them up to speed and productive is on the existing team. If these people are smart and motivated, great! But no-one benefits from having 200k+ engineers now have to spent their days explaining how GIT (yes, really...) works to a small army of juniors. - Not involving your current team in decisions that affect them. Re-shuffle the teams around, re-architect the product, change the existing workflow, etc. If you hire professionals with 10-20+ years of experience just to ignore their advice, they're going to be looking for an employer that does appreciate their input very quickly. Nothing is more frustrating than telling a manager not to put his hand in a pan of boiling water, just to see him do it and then blame the cooks for having a pot of boiling water around :) My current manager decided to add 50 outsourced engineers to a team of 5 to deliver the product in a year (instead of the 1.5 - 2 originally guesstimated). In addition to this he decided to give the responsibility for the architecture of the application to outsourced "solution architects" with no domain knowledge and reorganized the teams to split them by job title (e.g testers, developers, operations, "management", etc). Current productivity is lower with 55 than it was with 5, 3 out of 5 have already handed in their resignation. We're burning through an additional 3 million this year with 2 crappy React pages to show for it. Next year the damage will probably be worse given the rapid outflow of talent.
  • ironmagma 4y ago
    As someone who interfaces deeply with Git on a daily basis, please don't imply that it's trivial or simple. There are a million edge cases you can get into, and people with 7 YOE on my team are regularly surprised by the facts we uncover.
    • silon42 4y ago
      Git command UI sucks (compared to some alternatives to SVN, HG, ...).... I'm not teaching that to other people except bare minimum. I will gladly explain advanced stuff, but they need to grok the basic themselves...
    • whydid 4y ago
      Yes, git can be complex. It's also a requirement for modern software development. It is well documented, and not esoteric. If someone hasn't taken the time to learn the tools their team uses, they will be a burden to the rest of the team. They don't need to become an expert, just experienced enough so they don't cause problems for others on the team.
• indy 4y ago
  Too much time is spent generating metrics for non-technical managers to evaluate the productivity of engineers.
  • bdw5204 4y ago
    The best way to evaluate the productivity of engineers would be to determine if their peers see them as a top performer, a net positive or a net negative. If somebody is a net negative, get rid of them. If somebody is a top performer, make sure they're compensated accordingly and kept happy so they don't leave. If somebody is a net positive then you should be satisfied that you aren't stuck with a net negative. Any attempt to evaluate software engineers beyond this is going to be inherently arbitrary. If you invent arbitrary metrics, your engineers will often have to choose between doing work or gaming the metrics.
    • eggsmediumrare 4y ago
      There's a guy on my team who everyone thinks is a bad programmer and general looks down on, but he is always willing to help, does a thorough job and writes generally decent code. I have no idea where his reputation came from, but it would be a shame if he were let go based on his peer evaluation.
      • anotherrandom 4y ago
        If he does a good job and is always willing to help, that sounds like a net positive to me. It just might be that there are a lot of toxic team members
• mwcampbell 4y ago
  > In my opinion, Have a minimum team size of six. So I guess this post is only for big companies and VC-funded startups. I'm the technical cofounder of a tiny bootstrapped company, and for now, I'm the only engineer. Being the sole engineer is stressful, but it's currently necessary, and I think it's worthwhile to maintain the control and integrity that we'd probably have to give up if we pursued the funding to hire a bigger team. Even when we do have the revenue to hire, we will certainly not go straight to a team of 6 or more engineers. Big teams have their own problems, like communication overhead.
  • ozim 4y ago
    Not having team of six can be alleviated by setting realistic expectations. If you hire 1 or 2 devs and one gets sick don't expect other one not to take vacations he planned 2 months ago. It will hit your bottom line but that is the risk you will have to eat as an owner and not your employees. Manager at big.co usually does not have option to "eat a risk" so he should put preventative measure for such a scenario.
    • mwcampbell 4y ago
      If you hire 1 or 2 devs and one gets sick don't expect other one not to take vacations he planned 2 months ago. Right, in that case, I'd probably give up my vacation instead.
      • quickthrower2 4y ago
        Or keep deploying daily anyway so when everyone is out the production env. is pretty up to date and undeployed feature inventory low.
      • chrisseaton 4y ago
        Why does anyone have to give up a vacation? Unless you're building intelligence or defence software or something like that.
        • 4y ago
• hericium 4y ago
  Agree with most points but one which is making a manager do coding/shipping. Most of IT managers I met possessed no real IT skills. They wrapped their heads around only as much theory as needed to _manage_. Most of them did not came from engineering world but from business one. Ideally, manager should be able to do the work their team is doing, but reality is quite different. I stopped expecting managers to understand what I do outside of expected effects. Regarding estimates, it really is frustrating when a non-technical manager cannot understand the inability to state any reasonable time estimation. - so how long will it take you to finish this task? - no idea, haven't done anything like that in the past - ok, so how long?
  • threatripper 4y ago
    Nobody can work with engineers who are unwilling to commit to a schedule. Often it is very hard to make them commit and even if they do initially they often start missing deadline after deadline. A total nightmare for project management.
    • jen20 4y ago
      > A total nightmare for project management. If there is not enough information to make informed schedules, the only reasonable option is to DO MORE RESEARCH, not guess. Better still is to not try to create some master plan that requires things like this to be known at all.
    • bratbag 4y ago
      I don't agree. Its perfectly reasonable not to have any idea about an estimate until after an investigation or prototype has been produced. Demanding an estimate up front for something totally new just makes you look inexperianced or bad at managing engineers.
      • threatripper 4y ago
        We don't want to manage engineers we want to manage projects and projects have budgets and deadlines. If you can't deliver then maybe you're not a good enough for the job. If you can't even promise then why are you still working at our company? One of the best ways to drive away engineers is to make them commit and then watch them fall into misery when they desperately try to somehow make the deadline. Many weak characters break that way. The trick is to make them choose their own deadline and fail. That way you take away the scapegoat "they set unrealistic deadlines" because the engineer digged their own grave.
• tomohawk 4y ago
  Agree on some points (first 3 for sure), disagree on others. A major missing one is the demoralizing effect of having to work with incompetent team members, with management unwilling or unable to do anything about it. An incompetent person is likely not a bad person - more likely a good person who is the wrong position, or who just isn't capable. I recall working on a team where I was called over by one of the members to help out. I was new on the team, and wondered what the sidelong looks from other team members were about. She wanted to know why her program did not run. I asked to see the compiler output. She asked what a compiler was. How a person could attain a masters degree without actually knowing that is beyond me, but her skillset clearly had nothing to do with software. This was in a government agency, so she was promoted to management where she became one of those other problems on the list.
  • LaurensBER 4y ago
    I'm glad you said that this was at a government agency otherwise I would have been sure that we worked together in the same team, with the same person. I worked together for a year with A. who is a "senior" engineer, some of the stuff that A. pulled was; - Not being able to use GIT. At some point we decided that I would have to do all merges because he just wasn't capable of doing them. - Editing the project using nano on a server because he couldn't figure out how to install GIT on his laptop. This included YAML files where he would manually count the indentation... - Reviewing the old code in a pull-request, multiple times... - Copying the requirements from project A to unrelated project B because they're both Python projects so it should work? - Claiming to be able to program in multiple languages, giving examples such as INI, YAML and JSON... - Claiming expert knowledge in C++ and Java, I haven't seen him read or write a single line in all the time that we worked together. - Sending endless questions over Slack about the most basic things that he could figure out himself (e.g did you look at that PR? When I had already approved and merged it or how do I change something using SQL?) - In general just not getting anything done, there was one sprint in which he finished two tasks, one of which was changing a password in a text file After a while he was made temporary lead and the following happend; - Killed my CI/CD pipeline because "automation is dangerous", manual releases now routinely take over 12 hours... - Introduced a rule that PRs now had to include screenshots of manual tests instead of us writing automated tests - Lying to stakeholders about issues, literally: "we can just claim it was a bug in vendor X code, it will look better!" - Proposing to re-review old PRs every two weeks, because PRs are like fine wine? - Giving tasks to the team that made no sense. E.g a task to clean-up old versions of software X that was upgraded using YUM on a Linux server. I tried to raise the point that the package already included a clean-up script. He got angry and didn't want to hear it, I chilled for a day and closed the ticket. - Insisting that production password would be encrypted on disk (granted, not the worst idea!) just to proceed with then storing the plain-text password on Confluence (where it was accessible to the whole company) and in GIT :) - Killing our database replica's because: "they were misconfigured, someone linked them to the production database. That's very dangerous!" I documented and raised these issues with my manager who didn't want to address them because: "it would be bad for A. motivation". I said screw this, I can't work like this and stopped working with him on that specific project. Productivity dropped 80%. He's currently scheduled for a promotion to "tech-lead" at the end of the year. I've left that place, some places are just not worth saving.
• hmmmcurious1 4y ago
  Scrum cargo culting whatever amazon is doing seem to work very well towards this end
• nonrandomstring 4y ago
  I'm sure we can all add plenty of fresh examples of bad organisational dynamics. Other than texts like Gall's "Systemantics" is there an equivalent to Acemoglu and Robinson's "Why Nations Fail" but for companies and projects? Here's some of mine: Put "security" before all else. Pointlessly surveil and monitor your staff for feelgood security theatre. Mandate MFA for every trivial login so that simply checking your email becomes a tedious schlep. Spam your employees. Send out daily self-congratulatory ego-trips as "newsletters" celebrating how well the company is doing. Sap morale by reminding every lowly engineer just how insignificant they are, what huge profits the company is making and how much senior salaries are. For bonus points use a "no-reply" internal address and make it impossible to block them. "Team build" by putting on mandatory "social" events, and various awareness and training. Shame employees to do not "participate" because that have actual work to do. Keep zombie projects alive. Even though clients have cancelled and everyone knows it will never be delivered, keep projects running for the sake of appearances and to keep managers close to retirement in a job for another year. Actually, stop me! This could go on all day. Someone really should write a book "How to kill a company".
  • wildrhythms 4y ago
    Don't forget management having engineers stop what they're doing to build elaborate dashboards to track OKRs, satisfaction metrics, whatever else, only to never look at it and only parade it around to other managers as a show of how in-tune with the product they're supposed to be.
  • blowski 4y ago
    Your list is more likely to contain your personal pet peeves - reasons you personally wouldn’t want to work in a company. There are plenty of people who’d say the absence of those things would be bad. That highlights the real problem. Growing a company is very hard.
  • FrankyHollywood 4y ago
    The book would be an anthropological study. Having worked as a freelancer for more than 15 years, seen many companies from startups to large finance I see these patterns over and over again, it's like human nature. Totally unrelated companies have these exact same flaws. Clueless middle management driven by money and ego making these destructive decisions. At the same time, a group of engineers at a startup without much management can go rogue and burn millions on fancy tech and frameworks without making anything useful. The only successful projects I have seen is with a capable senior engineer in the team, who can listen and understand what a tradeoff is. If this senior is trusted by both the team and the manger the team can be effective.
• alfiedotwtf 4y ago
  I can also think of "hire to fire" because of management fire-quotas... team moral must suck when HR-enforced curve fitting is policy
• 23B1 4y ago
  Like many engineers, the author of this article assumes all engineers are ethical, and perfectly suited to the assigned task. The author also assumes unlimited budgets, perfect control over a company's hiring and resource management, and a perfect understanding of the software's requirements. These are the same complaints I hear from inexperienced engineers over and over and over again – and not just engineers, but anyone primarily responsible for 'labor' vs. 'management'. The 'best engineers' empathize with the perspective of 'management,' that running a company is probabilistic, and that managers, co-workers, and other departments – like finance, recruiting, product, and marketing – are also duty bound by challenging constraints often beyond their control.
  • astura 4y ago
    This article could be a parody with how shockingly naive it is. The purpose of work is to solve business problems, not personal amusement and self-actualization. Business problems exist in the real world and have significant constraints. Many people will be much happier if they understood this.
    • legulere 4y ago
      Especially managers should know that this is not true. Business is a lot about politics and egos, and especially managers are the ones engaging in it.
    • WJW 4y ago
      That is just an opinion and not a statement of fact. There are many different types of people and not all people have the same motivation. A lot of people care quite a lot about amusement and self-actualization at work. What a business owner might want does not change that. (and let's face it, there are many many business owners who care way less about business problems being solved than they care about "being the boss")
      • krapp 4y ago
        > What a business owner might want does not change that A business owner decides what the purpose of the business is, and what constitutes useful "work" within that context. If I'm hired to do x,y and z and I decide my motivation is rather to surf the web all day or spend all my time on personal projects, that doesn't change the purpose of work, it just means I'm not working.
• Linda703 4y ago
  [dead]
• astura 4y ago
  I suspect that the author has never actually worked in a flat organizations, it's been my experience that flat organizations have way, way more problems than "too many managers."
  • marginalia_nu 4y ago
    In practice, they still have all the same hierarchy, except it's not as obvious.
    • astura 4y ago
      Yep, plus nobody ends up having any accountability to boot.
      • JJMcJ 4y ago
        Typically flat means anyone in Sales or Marketing can give orders to any developer and must be obeyed instantly.
• katzgrau 4y ago
  "What makes engineers sad? Their boss(engineering managers, Directors, VP’s) do not know what they face on a day to day basis and does not know how to build something, whether it is a feature or architecting something from scratch." If that's true, then it's probably mutual. Engineers typically do not realize that their manager's role is to manage people and process (which is a bit of a specialization in itself), and knowing how to build software is not necessary but definitely useful - mainly for questioning your engineers when they tell you something that sounds crazy. If any engineers are under the impression that their job is harder or more important than management, sales, etc, they're being arrogant. Coming from a former strong engineer who started a company and now manages people more than code.
  • watwut 4y ago
    > Engineers typically do not realize that their manager's role is to manage people and process In my experience, where ever engineers are not realizing that, it is when management is not managing process and people. Both management of process and of people are visible - when manager is doing it, engineers and know. But, fairly often management is preoccupied much more by activities directly visible to their bosses and and much less with those that can improve internal functioning of the team. > and knowing how to build software is not necessary but definitely useful - mainly for questioning your engineers when they tell you something that sounds crazy. If you are supposed to manage process, you need to know what engineers, testers, analysts, customer support do on daily basis. You dont need to be star, but you need to know where they spend time and what their issues are. Otherwise your process wont solve issues that are occurring in your team. You will be solving imaginary issues some other teams have you read about on the internet. And the above is greatly frustrating for everyone under you.
  • wildrhythms 4y ago
    Do you think someone is qualified to manage a process they don't understand?
    • onethought 4y ago
      The inverse question, is it even possible to have a manager who understands every nuance of the process they manage?
• noduerme 4y ago
  Granted, speaking as someone running a very small shop, mostly freelance, I really think a lot of the ennui and sense of being overwhelmed or unsatisfied can be solved by just deploying constantly. Rather than get stuck in a review cycle I try to get every incremental change online as soon as it's done and minimally tested. That can be up to six live redeployments per day, especially when a new feature is in beta. It's however many redeployments are needed when something launches. I prefer a local test server and straight to production. When you get the third build of the day uploaded by 5pm, and hold your breath til 6pm without anything catastrophic happening, you can keep your phone on and go get some beer and fajitas. If you make it to 8pm and the company is still running, a deep sense of fulfillment sets in about a job well done. That feeling of the day's work being done just doesn't exist unless you break it up into tiny incremental updates.
  • Gigachad 4y ago
    It astounds me how some companies will let months of work sit in an unmerged PR and then sometimes decide they don't even want it. Not only is it a massive waste of resources, its shit for the person who built it, and also sucks if you actually do have to merge it and resolve months of merge conflicts.
    • greenbit 4y ago
      This. Oh definitely, this.
    • wildrhythms 4y ago
      And when performance reviews come around the person who built the thing never gets appropriate credit because it never launched (not their fault). :/
    • gonzo41 4y ago
      There's the burnout from being overworked and then there's the burnout from nothing being done. This is why I'm always ringing the trunk based development bell. Get crap into the mainline now so we can understand it today and start fixing it.
    • 4y ago
• dalbasal 4y ago
  Most of these, I think, relate to a single kinda-meta-problem. Managing software orgs is hard, and most orgs can't do it well. Using additional management methods, more managers, and more engineers can make the software org less efficient. Software production is weird. Efficiency of software orgs is extremely plastic. An effective 15 person team can outperform a 150 person team and this is normal. Very extreme compared to most fields employing such numbers. Software can be really important & high value. Value can be utterly disconnected from the cost of producing it. I say "less efficient" purposely rather than "worse." It might actually make sense to go from an efficient 25 person team to an inefficient 500 person team. The additional cost of might be dwarfed by the benefits of marginally more higher output. That might be better economically (even socially), but less efficient. If you're in one of these orgs, you will not be more happy though. Efficiency feels good. Inefficiency feels bad.
  • pid-1 4y ago
    > If you're in one of these orgs, you will not be more happy though. Efficiency feels good. Inefficiency feels bad. I think there's a sweet spot that's particular to each project and collective skill set. Being in a small team and feeling anxious due being responsible for way too much stuff isn't fun as well.
    • dalbasal 4y ago
      IDK. If you're in one of these too-small-high-pressure teams, and then all these extra "resources" get poured in... It can go quite badly too. IMO, engineers themselves are sometimes responsible by leaning on "we need more resources."
      • mr90210 4y ago
        Same thing happening at the small team I am part of, we have just hired a fifth engineer, while the business often struggles to define what’s a priority.
      • nevinera 4y ago
        I think engineers often say "we need more resources" but mean "we need to have hired more resources two years ago".
• a-walker 4y ago
  > Stop estimating. I have analysed every team I have been on that use estimation. Those teams have been 99% incorrect. In my experience, it does not work. If you need dates, I would recommend a more modern approach like forecasting. What's the difference between estimating and forecasting? Seems very binary as written, but at some point don't you have to look forward and make some assumptions on complexity/effort required to solve a problem and the general time it takes to solve them in order to do a forecast?
  • kqr 4y ago
    This sounds like it's written by someone who's only been in teams that do point estimations. Those are, almost by definition, 100 % incorrect because even small variations mean you're not done exactly when you said you'd be done. If you estimate in properly calibrated 90 % intervals, you'll be correct 90 % of the time, and this is something you can verify continually.
    • code_runner 4y ago
      I’m interested but not totally sure what you mean here. Do you have a source or name for this intervals/calibration stuff? I’ve always had issues when people are using hours instead of points. The one time we properly used points on a team it went really well.
      • kqr 4y ago
        A good reference is Douglas Hubbard's How to Measure Anything. The idea is that most people can calibrate their sense of probability to be fairly accurate, by intentionally adjusting for some common biases. (In particular, if you prevent anchoring and availability bias, and actively engage system 2 and your loss aversion, you get a long way. There are specific techniques to do that in the book.) This is really easy to practise and test too, since all you need are a bunch of questions where the answer is known, but you are uncertain of it. Then you can guess a range in which you are 90 % certain the true answer lies, and after 10 such questions, you should be correct roughly 9 times. Points are a way to do this, but I prefer engineers who are calibrated. It's very powerful to ask someone for a calendar day when something will be done (or really just about any other question about anything), and be able to be reasonably confident in the span they respond with.
• netfortius 4y ago
  Just reading the beginning of the article, and I couldn't help re-re-emphasizing how critical it is - as a manager at any level - to conduct "exit interviews" with your report-tos and other dependents, right when taking over a group. This was one of the best methods I leveraged, in my over 25 yrs career, in all sorts of low or senior management positions, i.e. serious "exit interview" with any team I got anew, which helped me gage some of the insides. Simple questions like "why would you leave today, should X, Y and Z be no different somewhere else" and "why would you stay, should X, Y and Z be better somewhere else", etc., of course with very well refined variations on the X, Y and Z and topics derived from the initial questions, depending on the environment. And I always warned the folks about the "exit interview", and given some hints on what questions I may be asking, to let them prepare for the actual conversations to be had on this topic.
  • kayodelycaon 4y ago
    I think some nuance is being missed here. I’ve had a manager come in and ask questions like this and immediately turn around and use the feedback to fire people and rearrange the department.
    • twobitshifter 4y ago
      That sounds like a good thing or was it too fast? Most companies do nothing to address the problems following exit interviews and them end up with terrible retention
      • kayodelycaon 4y ago
        People were fired for systemic issues they criticized. Non of the issues were corrected and the new person started handing down questionably legal changes to our platform.
• BaseballPhysics 4y ago
  > Stop estimating. I have analysed every team I have been on that use estimation. Those teams have been 99% incorrect. In my experience, it does not work. If you need dates, I would recommend a more modern approach like forecasting. What does this even mean? I've never heard of a forecast that didn't use a combination of past data and an assessment of complexity of future work to assemble the forecast. And assessment of complexity is the heart of estimation. Can anyone help me because my imagination is failing me here.
  • Ensorceled 4y ago
    The problem is that article is confusing the management failure of assuming estimates should be accurate and then punishing/rewarding based on accuracy of estimates with the proper practice of using estimates for scoping projects so they can properly prioritized and loosely road-mapped. It's a throw the baby out with the bathwater problem.
  • drdec 4y ago
    I think the difference is that a forecast is developed by a team (or formula/ML) separate from the engineers doing the work.
    • BaseballPhysics 4y ago
      Once again: no team or model or formula can produce a forecast without an assessment of complexity for the work effort being forecast. So if what you're saying is true, this would involve someone other than the devs assessing complexity, then coming up with a date, and then holding the devs accountable. And that sounds like a complete nightmare that's far worse.
      • drdec 4y ago
        > without an assessment of complexity The point of ML is that that can happen without human intervention. And yes, I agree that if devs are held accountable to such timelines that would be terrible. But if they are used for business planning with the understanding that they will not be accurate in the specific, but hopefully in the aggregate, then that's fine. (This is how engineer's estimates should be used as well for that matter.)
• mkl95 4y ago
  These are the endemic issues I have experienced after working for several SaaS vendors: 1) Rampant tech debt. Engineers are not empowered to fix it or their focus is on something else. 2) High barrier of entry. Most SaaS companies are bad at onboarding engineers or they simply don't care, usually because C-level staff and investors work towards sales metrics. 3) Mismanagement. Passive engineering managers who spend most of their time attending obscure meetings and expect individual contributors to chase them, maverick employees who do more harm than good, antisocial behaviour due to having no conduct expectations, etc. My personal opinion is that nowadays SaaS engineering is akin to being a miner during some mineral rush. You can make significantly more money than the average Joe in exchange for a shorter life expectancy.
• thenerdhead 4y ago
  I’ve always found self-determination theory to be a good way to frame it. Remove anyone’s competence, relatedness, or autonomy and you will drive them away.
• spookierookie 4y ago
  plus: * Put them oncall on Xmas when they are new to the team (because teams are like army where the newcomers must suffer) * be pedantic and hysteric in code reviews * have meaningless processes that drag for hours. E.g. iteration planning that goes on for 2 days * enforce nebulous "principles" (e.g. anything by RC Martin) because manager that hasn't touched code in a decade went to a show of him and was "impressed" * have clueless architects design systems and processes. Specially anything microservices-related. * have lesser engineers run the teams and processes. The kind that is good in Public Relations but have little or no real skills * have id-politics matter more than anything else. E.g. most important problem this week being why women employees got a pink promotional cup and how is that discrimination * do not allow access to web mail and a gazillion other sites because "security" * do not allow local code (if you see this - run) and instead promote "dev" in remote controlled envs * foster a blame culture (who did that?) * foster a toxic culture where politics run the place * fire good engineers and keep the above mentioned Public Relations ones * have and promote managers that are good in gaslighting and not much more * work for managers and with colleagues that you'd advise your kid to stay away from because they cannot be trusted * hire titles with no real experience and many ego issues and push them hard through the ladder. Classic example PhDs straight from uni.
• pluc 4y ago
  > Design your organisation to minimise collaboration between teams, but have high collaboration within the team. this is a joke right?
  • perlgeek 4y ago
    Charitable read: OP probably didn't mean "minimize collaboration" but "minimize the need for collaboration." Or phrased differently: design your teams so that the most common tasks can be done by a single team. If support needs to talk to the developers for every single support request, there isn't much need for a separate support team. If, on the other hand, the support team gets all the tools and training to address the 99% most common support cases, support gets faster and developers get fewer interruptions.
• revskill 4y ago
  This is due to the unforseen features to be built in future. How to know hidden cost of a task ? No way! Is software engineering a lucky game ? I say YES!.
• woevdbz 4y ago
  The underlying principle I've been using to understand this is, no engineer worth their salt will be spending a material amount of time working at an organization that they don't believe utilizes their talents well. The opportunity cost of talented software engineers is much too high in general. This applies regardless of actual talent and does not guarantee results. I've seen mediocre SWEs with inflated egos jump around because they felt their "world class" talents weren't being put to good use, some unsuccessfully, but some rather successfully fooling their way through the ranks of management. But I've also (more frequently) seen disillusioned, extremely talented engineers leave an org that was paying them obscenely well already, but was making them feel like they were wasting their time, for a shot at a startup dice roll which does not pay off as well (on average).
  • ClumsyPilot 4y ago
    > no engineer worth their salt will be spending a material amount of time working at an organization that they don't believe utilizes their talents well So is everyone developing advertising at google is a second rate engineer?
    • kidgorgeous 4y ago
      Yes. First rate engineers are designing rockets at Space-X
    • allgreed 4y ago
      I think believes is the key here. There are definitely people who believe that if they can work on complex graph colouring problem in a real-time processing scenario and the interruptions are minimal - then indeed their talent is utilised well. And I can imagine such a scenario happening at Google in advertising department/division/tribe .
      • jb3689 4y ago
        There are plenty of critical, unglamorous jobs which need to be done. It’s not unreasonable for an engineer to value high six figure/seven figure salaries over a feeling of work fulfillment and skill utilization
• jmyeet 4y ago
  On the issue of estimation, you want to drill down to: 1. Why are you asking? and 2. What happens if I'm wrong? I subscribe to the view that you can either launch based on features or launch based on time. You cannot do both. If your product is a compiler and you want to support, say, ARM and that requires a bunch of work, you have to choose to release a version at a particular time or to launch with that feature complete. Many people just don't get this. You can try and hit a time goal by resourcing but this is often done in a counterproductive way eg by throwing bodies at the problem when it's far too late and as we know that can just slow down the process as the people who know what they're doing have to ramp up the people who don't. Often you're being asked for an estimate because management wants to ignore this and is fine with forcing their team into "crunch time" to meet some arbitrary goal. As for what happens if I'm wrong with an estimate, basically am I going to get "punished" for underestimating? Be that through getting a bad performance review, a lower bonus, a lower stock grant or whatever. If so, you've just created an incentive structure for me to completely overestimate because there's typically zero benefit in overdelivering (other than a perfunctory "ata boy"). So if I think something will take a day, I'll end up estimating 1 week, maybe even 2. You should build some buffer into any estimate but if you are punished for taking longer and not rewarded for being faster, what do you think is going to happen? Now you might have a bug to fix a typo on a website and if you say that'll take a month obviously that won't fly but a team will generally settle on estimates that are really large without being large enough to draw scrutiny. Even then, many managers will take an estimate of 6 days and negotiate down to 3 days without knowing what went into that estimate. That too will lead to buffers being padded. If someone takes longer through no fault of your own (eg it just turns out to be really complicated in a way you couldn't anticipate) then I've seen it more than once where a manager will throw that engineer under the bus to save their butt from their own management. In short, estimates are an almost sure-fire way to create an adversarial environment between engineers and their direct management.
• DoubleGlazing 4y ago
  > Stop estimating. This! It's more or less impossible to correctly estimate how long it will take to develop anything but the most basic pieces of software, and even then you can't be sure. I've had so managers who just don't get that there are so many unknown variables in the software development process. No matter what estimate you give, you cannot win. Estimate short, but it takes longer? Then you are accused of not knowing what you're doing. Estimate long, but come in short? Then you are expected to shorten all future estimates. Estimate right? Nah, that never happens. Every price of software developed is different and will take a different amount of time to be developed. It is really quite stressful for a dev who is working their ass off to hit difficult targets in an organisation that refuses to be flexible about that sort of stuff.
  • drdec 4y ago
    Give three estimates. One if everything goes well, the most optimistically you can imagine. One representing the most likely path. And one representing the worst-case scenario. Let your manager digest from there. If you have a bad manager (e.g. they would just use the best-case scenario estimate and ignore the others), average the estimates, 1 part best case, 1 part worst case and 4 parts normal case. Then try to make sure you are giving a set of estimates, not just one, and usually it will average out. Step two of having a bad manager is finding a different situation, whether via internal transfer or a new job.
    • DoubleGlazing 4y ago
      For me I had one manager where every time he said "how long will is take?", I got that feeling of fear and dread in my stomach. I suppose the problem was that he wasn't asking for an estimate, he was asking for a specific date when the project was fully deployed. He wanted pinpoint accuracy, even though that was impossible. Missing or undershooting a target would have him bringing you into a room where he would start interrogating you about what he perceived as a personal and professional failing on your part. So anyways myself and others started pushing back and refusing to give estimates and instead just saying "it will be ready when its ready" and when pushed giving super vague time frames like "a few months". He did not like that. So I took step two and moved to a new job.
• ChrisMarshallNY 4y ago
  > Hire managers that cannot build software > Make the process of defining software painful. > Make engineers estimate their work. IMNSHO, these all have the same "fix": Technically-proficient managers (that are also good managers). The combination of those two is rare. Management is often considered an "ego position," so unqualified* people fight to be managers. It's not always about the money. It may be about the office, the car, the administrative assistant, the invitations to trade shows, etc. Also, upper management types frequently consider "workers" to be "lower class people," and only want people they can relate to, personally, and that don't make them uncomfortable, in management roles, so they end up mining the Yes Man and Politician veins for managerial talent. In my case, my company actively discouraged me from being technically proficient. They would routinely deny me training (so I went to training seminars on my own dime, and took vacation time), and would ignore my technical work (which was often extremely relevant and useful). I ended up doing a ton of open-source work, just to keep my tech chops up. Because it was my own work, I did stuff that had very little connection with my "day job," and also brought my own equipment. I hated being a manager. It was always a burden, but I feel (and everyone else seemed to agree), that I was pretty good at it. Since leaving my last job, I ran screaming for my tech work. *"Unqualified" is not just "technically unqualified," but also "emotionally unqualified." I think managers need to remember that they are managing people, not just "human capital," and that, if things are done right, their employees may be more technically qualified than they are. That was certainly the case for me, and I was proud that my team knew more about the work than I did.
• perrygeo 4y ago
  Reading this article and the comments here is like group therapy. This feels like a nearly-universal experience; the shared trauma of pouring everything into a project only to see success destroyed by incompetent management. I've been writing code for a living for 20 years and I swear it wasn't always this bad. There were fulfilling software jobs at one point. What changed?
• anonymoushn 4y ago
  Nobody asked for walls in an exit interview? All of the engineers you spoke to enjoyed debugging while listening to sales calls?
• cebert 4y ago
  Hiring cheap contractors can be frustrating too. I am on a project that is behind schedule. Management’s solution is to temporarily staff the project with several temporary, cheap offshore developers. I think a smaller team with competent folks can be much more product. There’s a lot of truth to the book, “The Mythical Man Month”. Now, we have far more meetings and communication chains. We also have to spend multiple cycles reviewing the contractor code and helping them learn software development.
  • summertime42 4y ago
    If it's as bad as you say it is, collect evidence and prove Mythical Man-Month to them. Explain it's wasting more time AND money, and the deadline is missed regardless. Hopefully they'll listen.
    • anotherrandom 4y ago
      Depends on the company. At BigCorp Inc., that sounds like a great way to get on management's bad side
      • summertime42 4y ago
        It might be, but in my experience the hardest conversations are the best ones to have. If it all goes to hell, time to vote with your feet and dust off the resume, then.
• nyc_pizzadev 4y ago
  As someone who has been in industry for over 20 years, I have been spending a lot of time thinking about and living thru this. For me, my manager and my relationship with him/her is probably the most important aspect of a job. A few things that I have learned: * Manager maturity. Young managers tend to be very hands on, they will naturally micro manage. More times than not they were previously an engineer, possibly in the role your currently in, so they continue that role, but with manager power and authority. Young managers work best with younger employees. Young engineers need hands on managers to explain things and mentor them, and that plays well into a young managers need to manage things. Older, experienced, and more mature managers tend to learn what their value is and where they are important. Usually that means listening, coaching, and communicating. Technology has literally changed under their feet, so they tend to be hands off. They also rely on their team more to make decisions and drive towards success. They depend on you. These managers tend to work well with senior engineers (a senior engineer is someone with decade(s) of experience). * Conflict. A few years ago I did a handful of manager interviews with some top tier tech companies. I was a bit dismayed that these companies were not looking for nice guy managers who values things like compassion and supporting their employees, and possibly even be friends with them. Rather, they want managers who are hard, can wield power, and comfortable with conflict. Conflict here means that management and employees are in constant dispute over literally everything. This means that managers are constantly squeezing work out of you and will have no problem introducing politics and other authority techniques into their day to day managing. * Communication. Open communication is extremely important. What I find is that when you have many layers of management, decisions are made using information which needs to be withheld from lower levels (or decisions are made based on no information!). When it reaches the lower level, it seemingly makes no sense and can be confusing. Good management communicates everything and does so transparently. This way everyone understands the what and the why. If you don't agree, given you know the why, then you are at least better prepared to pitch an alternative or make the needed changes. If the why is something contentious like you or the team is underperforming, then again, its best that is communicated so everyone has the power to make corrective action, if they choose. I think a lot of this comes down to culture. A good culture values engineers and adapts to making them happy, as that is how you get the most productive engineers.
• flappyeagle 4y ago
  I get paid to give advice to tech executives and directors. Something I often have to say to them is: hire talented managers. Talent dominates technique. They need to stop reading blog posts like this and just think about talent. We’re obsessed with technical talent but we hire managers at random after asking a couple of behavioral questions they’ve heard a thousand times.
  • skeeter2020 4y ago
    This is definitely not universal. I'm at my 3rd organization in an engineering management capacity, and only the 1st one where I grew into the role didn't both put me through the technical gauntlet and explicitly interview for people leadership skills and experience. I think the challenge is that management is a more subtle skill with longer lead times to positive outcomes. There is no testable analogy for the coding challenge or take home project. >> Talent dominates technique. I really don't like this as it implies some sort of naturally leader vs. skill development over time. We'd do much better to optimize for affinity, desire and coachability in potential leaders.
  • mancerayder 4y ago
    What's your opinion of the new hiring standard that has arisen the last several years across Big Tech and has trickled down: We're looking for an experienced Software or SRE or DevOps or X Manager in this exciting and fast growing company! Must be able to code in a job interview, have five years experience or more directly managing a staff count of at least ten engineers, and answer algorithm questions! We also expect you to know not just application architecture and CI/CD workflow inside and out, but experience with X and Y vendor applications, Z framework, and running Agile teams! My qualm is that a manager can't remain a hands-on coder very long if they're spending their days in 1:1's, product meetings, negotiating with other teams to protect their engineers, and generally being good managers. I'm baffled by how someone can be an experienced and talented manager, and also have their technical chops stay strong - forever. Technology changes such that what you became and expert at when you weren't a manager, is different from when you're manager today. All that remains are patterns, intuition and wisdom that can't easily be captured. When you've experienced first-hand managing various personality types like 'shy engineer who needs to be encouraged' and 'arrogant talented engineer who everyone relies on but does what they feel like' and 'new junior engineer' and 'repurposed engineer who was doing a completely different role' as well as 'the other remote team that's just joined'... you realize these things are hard. There's no way a heads-down coder can be good at these things. Unless they're elite geniuses or people who work 6-7 days a week. So I don't understand the job specs for tech management today.
• skeeter2020 4y ago
  I get why these "Managers are so clueless!" posts feel good and are often well received. One thing that would help is if technical talent didn't naturally position leadership as comprised of people who are totally different from them, who intentionally strive to create an unpleasant counter-productive environment that makes it hard to create and deliver software. I get the pain expressed here, it's real, and the problems are REALLY HARD to solve. Any one of these is multifaceted and cannot be solved by "management" alone. Asking VPs to code a feature every quarter is both unrealistic and silly. Complaining about too many managers, meetings and processes is common and fair, but not to say "if you have painful process fix it with this different, equally strict and brittle process" is naive to the point of funny. Saying "estimation is hard so don't do it" an incomplete answer, and railing against smaller teams or realigning people broadcasts "I don't really think about budgets, emerging needs or things above writing code". So much of this can be addressed within the team; you can promote streamlined process that does enough to align without prescribing, you can add some consistency in who does what work to build more durable teams and form a consistent mission, you can estimate in effort not time. The author seems to think the ideal is achieving stasis and maintaining it; to me this is impossible and actually sounds like hell.
  • honkdaddy 4y ago
    Well said. Managing engineers is an incredibly difficult and multi-variable challenge - companies have been trying different approaches for nearly a century now. We like to imagine as software developers our management problems are unique and can be solved with a silver bullet blog post, but I think they’re largely the same meta-issues that Ford faced in the 30s or Boeing in the 90s.
    • fuzzfactor 4y ago
      Definitely not just software and not just engineers either. Like he says in the final line of his epilogue: >If you cannot change your company, change your company.
  • drc500free 4y ago
    The day that engineers accept the reality of reporting to investors who only care about cashflow and time is the day all those MBAs and managers go away. Until then, someone always needs to impedance match between the world of ROIC and the world of hackers.
• hownottowrite 4y ago
  I don’t see “failing to fire bad engineers” on this list, which is a huge problem but easily fixable. A good engineer can put up with a lot of BS, but working with B and C level talent is a fast path to burnout.
  • proxyon 4y ago
    I work for a company that doesn't fire no matter what. You can join and do nothing for 40 hours a week while never delivering on a single ticket in the issue tracker. True story there is someone here who has never had a single PR in nearly two years. He isn't a manager he's a dev. The other engineers can see this and it is immensely demoralizing and betrays such a serious dysfunction that no one takes this company seriously. To spice this up a bit this is a high end tech company which everyone reading this has probably heard of. The employee in question is not the only employee who does nothing. I would estimate roughly 10% of the company does absolutely nothing all day and another 20% work 20 hours or less a week.
• rossdavidh 4y ago
  So, many of these I agree with, but not this one: "Hire managers that cannot build software". Managers that cannot build software are, in my experience, just as likely to be good (or bad) managers as managers that were good programmers. Managers who used to be programmers are sometimes clueless, and aggressively so, about people skills. While it is possible to manage programmers well without programming skills, if you work at it, I don't believe it is possible to manage programmers (or anybody else) well without people skills. Software managers who were never programmers _know_ they don't know about programming, and understand that this gives them some blind spots, so they are often willing to take constructive, professional, tactfully given hints on that. Software managers that were programmers, in some cases, not only don't have people skills, they don't think people skills are important or useful, and they don't try to get better. Not saying former programmers _cannot_ be good managers, I've seen some that are. But I don't think non-programmers are, on balance, less likely to be good at managing software development, because they know what they don't know, and managers who were formerly programmers often don't.
• Jugurtha 4y ago
  From: https://www.merriam-webster.com/dictionary/scuttle https://www.merriam-webster.com/dictionary/scuttle >scuttle verb(1) 1: to cut a hole through the bottom, deck, or side of (a ship) specifically : to sink or attempt to sink by making holes through the bottom The actions of these people make you to give up on Occam's razor in disbelief. Sometimes they're the owner of the company who are doing everything someone who'd want to sink a ship would do. The worst is when the ship was amazing (generating revenue like crazy, great reputation, top notch record, satisfied clients). Also, promise people equity then change the goal post by introducing new variables, haggling over everything, and attempting to screw them in every sentence (for instance, change the vesting period in one sentence, add a condition in the next sentence, claim they've had no impact on the company in the next, threaten to fire everyone in the next, add yet another condition in the next, tell people you can't give them the equity you promised because you promised someone else and do that for the other person too). That's, in essence, how to fuck up your own company lightning fast.
• a_square_peg 4y ago
  I see posts like this and wonder if software developers are in such high demand that they're able to call the shots these days but many of these points are come off as very arrogant. > Make your engineering managers, Directors or VP’s take about one week in a quarter and get them to build and deliver a feature. While we're at it, why don't we also get them to design a part of a car, design an icon for UX, do some accounting and have them do a legal brief? > Stop estimating. How does this person think an organization schedule, budget and allocate resources? > In my opinion, Have a minimum team size of six. To build what? Some production software can be built by one person. Some need hundreds. This is like saying an organization needs a minimum of $1.5m annual budget for software development because it's software development.
  • grayclhn 4y ago
    >> Stop estimating. > How does this person think an organization schedule, budget and allocate resources? Collect data and use a trivial prediction model (i.e. median calendar time it took to complete the last 5 stories). Monitor and improve the prediction model over time if necessary. If you’re not collecting data reliably enough to generate a prediction automatically, you’re not taking any of these issues seriously anyway.
    • kimixa 4y ago
      That's just a way of estimating that is likely quite accurate in a completely steady state. But what if you know you're changing things significantly, and that's the whole point you need to think about resources and schedules? Like starting a new project?
      • grayclhn 4y ago
        Use data on how long it takes to complete “projects.” Or break the project down into your best projection of the component tasks and multiply “number of equivalently sized tasks” by “average time to complete that sort of task over the past X months.” Regardless, “collect and use data from the past,” does not require a “completely steady state,” and is pretty easy to modify. I’d feel a lot better having a conversation around, “this is totally new, do we think it will take about 2x or 5x longer than our normal projects?” Vs “this is totally new, so everyone guess how many months it will take without looking at any relevant data on either past project duration OR the accuracy of your past guesses.” When people talk about “estimating task size” they almost invariably mean some planning-poker version of the second. Especially in TFA where they bring up forecasting as a better alternative.
• AtNightWeCode 4y ago
  Some very good points on this list. Some more points. 1. Hand out responsibilities and make engineers accountable without giving the engineers any influence on decisions. 2. Make team decisions without asking the team. 3. Make promises to individual employees that is not inline with the team or company strategy. 4. Make tech decisions among management people. 5. Outsource new development and let the staff work with legacy. 6. Constantly increase the scoop of what the engineers are working with.
• mannyv 4y ago
  This is way too simplistic. In reality, everyone has a role, and if you don't understand that role then problems occur. The fact is, in every organization there's the technical side and there's the political side. The bigger the organization the more need there is for a political, not a technical, manager. The former manages the people, stakeholders, etc. The latter manages the product itself. In many organizations both roles are done by the same person, who tends to do one side better than the other. In engineering organizations the manager is probably more on the technical side because engineers. The problem is that large organizations (insert your definition of large, it could be >20) or organizations with multiple customers managing upstream expectations and prioritization are really important. These people are paying the bills, after all. At that point you need to start fending off salespeople, account managers, and other executives. Unfortunately, telling customers to fuck off you're busy isn't the greatest path to customer satisfaction, retention, etc. You need a political manager to do that for you. I know of a few large orgs that have formalized this tech/political manager structure, because it's effective. But you need to understand what's happening and why. If something rolls downhill to engineering it's because the political side believed it was required; you need to accept that. Likewise if the political manager gets pushback they need to understand that the issue is real. So taking a step back, the article is complaining that you should have managers that understand what engineers do. I'd flip that - we need engineers that understand what managers do. Engineers are not special. Neither are managers. It takes people working together to get stuff to happen, period.
• deleted 4y ago
  [deleted]
• edem 4y ago
  Once I worked for a company which I prefer not to name here. They wanted to solve a huge problem which I have solved during my previous tenure elsewhere. Once I learned that they are trying to do this I offered my help. I realized that they picked someone with zero experience with this who was about to make the same mistake(s) I made before. I managed to talk with the VP about this problem and after about half an hour I realized that the person who was responsible for this decision not only didn't know anything about software development, but he also didn't know what the problem was and why we wanted to solve it. A day after this talk I've heard that a very high level IC resigned so I had a talk with him. As it turns out he also worked on this problem before and spent 3 months trying to make his point about this and after he utterly failed he just couldn't take it anymore. I also resigned a few months later. Having managers that have no idea about how programs are written and how the whole process works is a surefire way to sink the ship. Needless to say this organization had layers after layers of managers who all tried to protect their turf from all the potential damage others can make.
• dadoge 4y ago
  What is wrong with making engineers make estimates for their work? I’d much rather me give an estimate than some EM or PM since I’m building the damn thing. And totally confused by the author’s suggestion to “forecast”, which is what if not an estimate?
• IlPeach 4y ago
  Nice, thanks for sharing. A few points stroke a chord. Specifically... The definition of engineering manager who doesn't know how to do stuff and it's solution is very wishy-washy. Based on experience, this works in some contexts but not all. I think the author's hearth is in the right place, but the way it's explained is very short sighted. In other words this makes me think the author has never worked with an eng manager. Layering: good problem to solve, solution? In theory, but in reality this is also very difficult to balance (e.g. from experience, especially when moving above 150-200 ppl working in the same area). Too many meetings: very good problem. Solution? Partially meaningful. If you want to generalise, my take would be to make things async as much as possible. Collaboration between teams might be needed, and perhaps healthy. When you don't have collaboration you end up not knowing what's going on (i.e. isolating teams) and risking pulling meetings over and over. Software definition; mostly agree, but again, the solution is much more complex than what the author leads to believe. Also assumes you have testers and product will be happy to sit through each ticket revision. This problem is solved by anticipating these requirements way way earlier than that. Software delivery: are we talking about technical debt or what? If that's the case, the solutions (20%) make no sense. That's where you start diving into each single problem, breaking them down by priority, involving product and making sure things are tackled at the right time. The rest seems to be good.
• acconrad 4y ago
  When the author says “use modern techniques like forecasting” in the section on estimation, what do they mean, specifically?
• Trailing2Dots 4y ago
  Some actual anti patterns I've experienced: * When a project is declared "finished" break the team apart and spread them about the company. Because the original dev never see the code again, why should they care. * When a project is late, and it always is, pull out the original schedule rammed down our throats when the project was first started. Then it's easy to see who to blame. * Have legal (YES!) decide rules for agile. True: they decided on 1 week deliverables, demanded complete documentation per week, insisted on a waterfall approach to design and dev. "When you've done it, you don't have to revisit the past!" * Documentation was in charge of dev: "They read the docs and know what needs to be done:. I never figured out who "they" were. * Create a lengthy, complex paper trail for deliverables. True story of one company - now extinct. They had about a 50% turnover rate.
• Ava433 4y ago
• Ava433 4y ago