[HN Gopher] How to drive away your best engineers
___________________________________________________________________
How to drive away your best engineers
Author : signa11
Score : 294 points
Date : 2022-07-24 08:43 UTC (14 hours ago)
(HTM) web link (blog.hulacorn.com)
(TXT) w3m dump (blog.hulacorn.com)
| LaurensBER wrote:
| 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.
| romanovcode wrote:
| > 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).
|
| What one developer can do in a week - two developers can do in
| two weeks!
| marginalia_nu wrote:
| If we move to a microservices architecture, we can use 100
| developers to solve same the same problem in with ten times
| the hardware!
|
| With growth like that, we'll be unstoppable!
| devoutsalsa wrote:
| How else will we justify the military grade, globally
| distributed, multi-planetary federated, immediately
| consistent Kafka cluster that the CIO just purchased? I'm
| still not sure how to get all the servers to synchronize
| when Mars is on the opposite side of the sun.
| torginus wrote:
| That has more downtime during upgrades than my college
| dorm Counter-Strike server built from leftover PC
| components ever had.
| speedgoose wrote:
| Make sure to deploy your micro services in Microsoft Azure
| AKS to improve the reliability on the long term, thanks to
| the included and frequent network issues.
| threatripper wrote:
| It sounds like you're not having enough coordination
| meetings. You can make communication more efficient if you
| add more levels of hierarchy. MBAs are good at managing.
| Engineers are often wandering off-topic, so put MBAs in
| between the engineers to manage the communication and avoid
| unsupervised engineer-engineer-contact between different
| groups.
| [deleted]
| noduerme wrote:
| I was waiting for a /s at the end of this comment, but now
| I can't tell if you're kidding.
| raisin_churn wrote:
| If MBAs weren't economically efficient, the market
| wouldn't make so many of them and companies wouldn't pay
| them so much.
| noduerme wrote:
| That's like looking at America and saying obesity and
| opioid addiction must be drivers of economic success.
| marcosdumay wrote:
| And you surely got enough answers showing why the "\s" is
| important...
| ramphastidae wrote:
| This is pure fantasy. Markets have never been efficient
| and actors have never been rational.
| edgyquant wrote:
| Markets are _more_ efficient and by rational it means
| they act in their perceived best interest to optimize
| their own utility.
|
| You just don't know economics, that doesn't make it
| fantasy
| ratww wrote:
| I think that was sarcasm. Or at least I hope so.
| elcritch wrote:
| I refer you to the discussion a few days back on people
| not being accurately modeled as rational agents:
| https://news.ycombinator.com/item?id=32181987
|
| Companies and entire markets follow similar patterns of
| only having bounded rationality, IMHO. Markets can also
| have decades of slack or delay from stimulus to outcomes.
| Take the slow decline of Boeing after acquiring McDonnell
| Douglas and their MBA heavy structure.
| https://qz.com/1776080/how-the-mcdonnell-douglas-boeing-
| merg...
| ChrisMarshallNY wrote:
| They need more morons.
|
| Source: https://www.mit.edu/people/dmredish/wwwMLRF/links/H
| umor/Admi...
| jnwatson wrote:
| An interesting sociological question arises about how knowledge
| is passed down through generations.
|
| One could count the number of software engineering management
| tenets on one hand. One of them was detailed in a popular book
| almost a half century ago.
|
| If managers haven't heard of the Mythical Man Month, how can
| one have any confidence at all about any of their decisions. Is
| management a knowledge-free profession?
| sascha_sl wrote:
| There hasn't been a single job where I didn't have to explain
| Git to someone. Or that Git is not GitHub.
|
| Wherever I was somehow in charge of some authentication /
| account management (never been my primary responsibility, but
| "people who know cloud" teams often get that honor anyway) I
| have always had someone who didn't understand MFA. Either they
| assumed because MS Authenticator sends them a push, AWS should
| send them a push or they would have a clock desynced so hard
| that the most generous TOTP grace windows couldn't save them.
|
| My partner is in a place right now that had to be introduced to
| python dependency management. Really. No containers or anything
| like that either. Just alternate runing the script and
| installing the latest of a package until the import errors
| disappear.
|
| I really don't mind tutoring, but many of these people also
| would rather wait 20 minutes for you to respond than 5 minutes
| on Google. Or even your internal documentation. That's linked
| in the Slack channel they're asking. It drives me nuts people
| value their peers time so little.
| sokoloff wrote:
| It's hilarious to me to think "let's put all the managers on
| one team..."
| dreamcompiler wrote:
| Reminds me of the B Ark.
|
| https://hitchhikers.fandom.com/wiki/Golgafrinchan_Ark_Fleet_.
| ..
| BeetleB wrote:
| > have to spent their days explaining how GIT (yes, really...)
| works to a small army of juniors.
|
| I sympathize with the other comments explaining that Git is
| highly nontrivial, but I think the point is being missed. Why
| should I have to teach a junior how to use an essential tool of
| the job, when I can just point them to good books/guides on the
| Internet?
|
| My list would definitely include:
|
| Hire people who can and are willing to read. Be it for learning
| or for understanding specs.
|
| I'm not one of those people who gets upset at people coming to
| my cube to ask questions - I actually enjoy it (far more than
| them IM'ing me). But if it's something easy to find on the
| Internet, or clearly documented in a local wiki/manual, they
| should have at least tried to read it.
|
| Similarly, I'll take the time to document very well how a tool
| I built works. Almost always someone will then come to me and
| ask "Hey, can you tell me what the tool does and show me how to
| use the tool?" Over 90% of the times it's not because my
| documentation is bad (which I admit it very well _could_ be),
| but because they didn 't even try to read it.
| m3047 wrote:
| > I sympathize with the other comments explaining that Git is
| highly nontrivial, but I think the point is being missed.
|
| Git is nontrivial and has many ways to do things, and it is
| only one of many ways to do most of these things.
|
| If commit messages and merge squashing take the discernment
| and nose of a winemaker, you can't tell them to crush some
| grapes and leave it at that.
| no-s wrote:
| > Hire people who can and are willing to read.
|
| Also make sure they are able to read more than the first few
| words of the first sentence...(from bitter experience)
| ironmagma wrote:
| 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.
| lazide wrote:
| If someone has no idea what 'git add' is, the criticism is
| still on point.
| silon42 wrote:
| 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 wrote:
| 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.
| bosie wrote:
| > If someone hasn't taken the time to learn the tools their
| team uses,
|
| How does your company handle this? How do you give the
| people the time/resources to learn those tools?
| ratww wrote:
| My company handles this by allowing them to study on the
| dime. I just ask how much time they want and ask them to
| do it, and if they need some material or help devising a
| study plan.
|
| Curiously the two that needed it didn't really want to
| study at all, and we eventually let them go (they were
| interns).
| ironmagma wrote:
| I've never seen documentation on Git that was good and
| accurate. Pretty much every explainer out there commits
| major errors, claiming things like: commits are changesets,
| branches are sets of commits, claiming that any Git
| operation can be undone, implying merge is a symmetrical
| operation, or saying to never force push.
|
| Being a beginner in Git is probably hell.
| dghf wrote:
| But 90+% of the time, it'll be a basic use of add, checkout,
| commit, merge, pull or push, especially if you're a junior.
| kevinventullo wrote:
| Don't forget the most important operation: rm -rf the whole
| directory and re-clone the main repo.
| cyberge99 wrote:
| git reset HEAD --hard
| JonChesterfield wrote:
| Manager (or possibly his boss) needs a leaving present of the
| mythical man month
| intelVISA wrote:
| They'd probably fail to see the correlation in having their
| senior ICs occupied re-explaining Git to a constantly
| rotating offshore roster -- they're getting 10 engineers for
| the price of 1 after all.
| steveBK123 wrote:
| Yes, I was in an "agile" org that over-hired senior engineers
| and then expected them to just do regular "spade" work
| tickets.. but more quickly / more per sprint. No ownership of
| long running projects/tasks, no design/planning, just a
| constant stream of whatever ticket is at the top of the queue -
| GO.
|
| Over the last 12 months, 55% of seniors have left. Most that
| remain have been at the firm 0-1 year.. The median senior now
| has 1 year on the team versus previous median of 3 years.
|
| There's basically no institutional knowledge on the team
| anymore. Managers have now convinced themselves that all these
| green engineers are going to build v2.0.. however they are
| basically recommitting all the mistakes and suffering all the
| pitfalls that v1.0 did because.. no one is left to ask..
| pmontra wrote:
| Some managers do that kind of things to prepare the next step
| of their career or because they worked for the company they are
| hiring (which is a variation of the first point.)
| indy wrote:
| Too much time is spent generating metrics for non-technical
| managers to evaluate the productivity of engineers.
| bdw5204 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| WJW wrote:
| This is only a feasible plan for people without any
| children or committed relationships though. Telling your
| spouse that you'll skip the vacation because work is more
| important than them will not go over well, for obvious
| reasons.
| quickthrower2 wrote:
| Or keep deploying daily anyway so when everyone is out the
| production env. is pretty up to date and undeployed feature
| inventory low.
| chrisseaton wrote:
| Why does anyone have to give up a vacation?
|
| Unless you're building intelligence or defence software or
| something like that.
| throwaway98797 wrote:
| cause someone else might catch you
| SpicyLemonZest wrote:
| When you're have a small company you're hoping to turn
| into a larger one, many deadlines are every bit as
| existential as a DoD proposal deadline for a defense
| contractor. Especially when you don't have a big slosh
| pool of VC funding (but this is largely true even if you
| do), the difference between "stable and growing at a
| healthy pace" and "if something doesn't change we'll have
| to shut down" is often one or two customers.
| theshrike79 wrote:
| Growing your team too fast will always result in integration
| problems. Both quality and culture wise.
|
| Quality can be enforced by tooling somewhat (automatic
| formatting, enforced linter rules in CI etc.), but culture
| takes time.
| tgv wrote:
| I work in a small company, and we have a team of 3, if you
| count liberally. One colleague does front-end stuff, there is a
| tester who is intimately familiar with the way the software is
| used, I do the rest. That's really enough for the moment.
| tmikaeld wrote:
| There's a huge difference between a team of 6 full-stack
| developers and a modularized team where everyone has their own
| projects.
| donw wrote:
| Six is where you start figuring out how you're going to split
| the team. Eight is where you actually make it happen (either
| into 4+4 or 6+2).
| elric wrote:
| Agreed. Teams that are any bigger than that inevitably run
| into communication problems. Small teams are good for close
| cooperation. Big teams are good for wasting time.
| crowdyriver wrote:
| Currently at my company I'm the only one dev. Advantages and
| disadvantages, but having all code at one head really
| simplifies communication overhead.
|
| I hope I keep complexity sufficiently down so we won't need
| more than 2 or 3 more engineers.
| WJW wrote:
| What's the plan for if you get hit by a car and can't work
| anymore?
| IlPeach wrote:
| 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.
| nyc_pizzadev wrote:
| 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.
| jmyeet wrote:
| 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.
| a_square_peg wrote:
| 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 wrote:
| >> 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 wrote:
| 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 wrote:
| 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.
| hericium wrote:
| 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 wrote:
| 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.
| hibernator149 wrote:
| If engineers are unwilling to commit to a schedule, then here
| are some things that might help:
|
| - Make sure that the requirements are solid (you can't commit
| if you don't know to what you are committing)
|
| - Make sure that the environment is consistent (I can't
| commit to a timeline if the people on my team are constantly
| rotated around)
|
| - Ask the enigneers why they can't or don't want to commit
| and fix that
| bratbag wrote:
| 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.
| blowski wrote:
| The Cynefin framework can be really useful for having this
| conversation. https://lizkeogh.com/cynefin-for-developers/
|
| How well do the people executing the project know the
| codebase, data, and tech stack they're working with? How
| understood and confirmed are the requirements? The less
| those things are true, the less certain you can be with
| estimates. At the extreme, all you can do is poke the
| system and commit to providing feedback on what you've
| learned.
|
| At the same time, you should be trying to make the system
| more lucid, both for yourself and new joiners on the team,
| such that estimates can become more accurate. The more
| senior you are as an engineer, the quicker you should be
| able to do that.
| magicalhippo wrote:
| When I'm asked by my boss to estimate, I break it down for
| him. This part here I'm confident is 1-2 days of work, this
| part here can potentially be tricky so could be 1 day could
| be a week, and this part here I can't tell without digging
| into the details.
|
| If this is based on a customer request I'll try to find
| some restrictions he could take back to the customer to
| narrow the scope and provide a better estimate assuming
| those restrictions.
|
| Most of the time this is all he needs.
| threatripper wrote:
| What if he asks you for a number instead of a range?
| After all you have to use the company template to present
| your project and that does not have ranges on it.
| magicalhippo wrote:
| If for example, I say 3-7 days and he wants a single
| number because customer wants a date, he'll ask me "ok,
| so if I say to the customer they'll get the change in 10
| days, we should be able to deliver?"
|
| Then I say yes, under the assumption of X, Y and Z that
| sounds realistic to me.
|
| Of course, sometimes the numbers are to high. That's
| where narrowing the scope or even finding a different
| solution comes in.
| threatripper wrote:
| 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.
| someguydave wrote:
| Why would you want to drive away engineers?
| hericium wrote:
| > If you can't deliver then maybe you're not a good
| enough for the job.
|
| I've seen more than once projects with ill-equipped team
| members. I've been one myself, too.
|
| Even in established tech corporations, the process of
| team creation can be screwed up due to multiple reasons.
| I've seen DevOps engineers tasked with writing apps
| because PM did not checked what their role was. And that
| was a high-importance project in a huge, publicly traded,
| tech corporation.
|
| Expecting engineers to estimate work they haven't done
| before ends up in guesstimation which is almost never
| correct.
|
| PMs asking for estimations in pioneer projects create
| problems for themself, which they sometimes later blame
| on team members.
| threatripper wrote:
| They are asking because they have been asked themselves.
| To me it seems like a chain of incompetence from top to
| bottom, from bottom to top. Everyone is stretched beyond
| their abilities. The whole company is a house of cards.
| But yet it keeps on working and often it delivers results
| that keep everything else up and running. I don't
| understand why it works this way but it does.
| ozim wrote:
| You write that you don't want to manage engineers?
|
| But from what you write you cannot manage budgets and
| deadlines.
|
| Managing budget and deadlines is not about setting some
| "ideal world" and then whipping these lazy engineers to
| deliver exactly that.
|
| Managing budget and deadlines is about - well we
| delivered X/Y at that date it already was $yyy in terms
| of money. If it went well maybe you can increase work
| load, maybe look at things again and stop gold-plating to
| move further. If it went wrong cut the scope - check what
| went wrong, lower the risk of not delivering by
| simplifying tasks. Check if maybe you miss some
| specialistic knowledge to hire someone to help and
| account that risk against budget or tell customer that
| you need something specific that they have to deliver.
| mancerayder wrote:
| > Many weak characters break that way. The trick is to
| make them choose their own deadline and fail.
|
| I think I missed the title, main topic or perhaps even
| what you were replying to when you wrote this. Maybe
| there is a context. In its absence, this reads like a
| HowTo for getting someone you already don't like, to
| quit.
|
| Clear communication is a very important managerial skill,
| by the way.
| FrankyHollywood wrote:
| The question is often 'how long does it take to
| implement'. Engineers know if it is more or less clear
| what the functional requirements.
|
| In practice, workdays are constantly interrupted by
| meetings. An 8 hr workday is effectively 2-4hrs product
| building. Than there are unforseen deployment problems,
| some requirements change, solve merge conflicts, perform
| code reviews, frameworks need vulnerability updates, etc.
|
| An experienced PM knows this and should not use
| implementation time as project duration.
| jen20 wrote:
| Funnily enough, engineers want to do actual work and not
| manage up for hapless Machiavellian middle managers.
| Dudeman112 wrote:
| I'm glad you're not my manager and that I can choose not
| to work for managers like you
| wildrhythms wrote:
| >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.
|
| Manipulative, psychopathic behavior, and you are a bad
| manager.
| SideburnsOfDoom wrote:
| Yep. "I'm asking you to estimate this unknowable thing,
| pressure you to give me a small answer, and if you get it
| wrong, you're 'weak'".
|
| This is tinpot-tyrant stuff. I saw that in a movie: "no,
| the German people have failed _me_, they were weak, and
| deserve to suffer for it".
| SideburnsOfDoom wrote:
| > 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.
|
| IDK, but this seems just psychopathic?
| threatripper wrote:
| Yes, very much so. Although I wonder if those involved
| are aware of this.
| jen20 wrote:
| > 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.
| SideburnsOfDoom wrote:
| > 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.
|
| So you're saying that 1) engineers have to be forced to
| "commit to a schedule" and b) that schedule then turns out to
| be fantasy.
|
| I want you to think harder about what you said and where the
| problem actually lies. Maybe the engineers know something,
| about what's knowable upfront, that you don't.
| threatripper wrote:
| True, the problem lies somewhere else. Maybe the project
| should not exist at all if it's not manageable.
|
| The question "can you do it?" implies more than "can you
| maybe do it if you have infinite time and luck?" it implies
| "can you deliver on time?" and if you cannot then you
| should not take the project. The problem is that it's hard
| to hire engineers that are capable enough. Therefore we
| must make it work with the engineers we have and that means
| to push them harder than they are used to. If they succeed,
| then great.
| SideburnsOfDoom wrote:
| > The question "can you do it?" implies more than "can
| you maybe do it if you have infinite time and luck?" it
| implies "can you deliver on time?
|
| Incorrect, it implies "can you do it in a reasonable
| time, that is as yet unknown and unknowable" - which
| might even be quite small, but no-one really knows, so
| committing to a fixed deadline is at best fooling
| yourself, and is more likely a trap.
|
| > is that it's hard to hire engineers that are capable
| enough. Therefore we must make it work with the engineers
| we have and that means to push them harder than they are
| used to. If they succeed, then great.
|
| I think that problem is that this is an intentionally
| deceptive, demented burnout-factory, and no decent
| engineer would want to work for you.
| threatripper wrote:
| How could you make project management plans that imply
| deadlines if you don't have deadlines?
|
| Yeah, maybe it's not such a smart idea to start with
| commitments that imply dates. But that's how it is. If
| you want to work in your own way then start your own
| company, I guess. Maybe it's time to do that.
| marcosdumay wrote:
| > How could you make project management plans that imply
| deadlines if you don't have deadlines?
|
| Looks like your project management plans have a problem.
| hericium wrote:
| > Nobody can work with engineers who are unwilling to commit
| to a schedule
|
| Inability to state a time estimate is not the same as
| unwillingness to commit to a schedule. You sometimes do
| pioneering work which you really have no clue how long can
| take.
|
| Estimating just writing code or doing something repetitive is
| easier than estimating research + prototyping/engineering.
| Closi wrote:
| > Regarding estimates, it really is frustrating when a non-
| engineering manager cannot understand the inability to state
| any reasonable time estimation.
|
| On the flipside, it can be frustrating for managers that
| engineers sometimes can't understand that they have to manage
| deadlines.
|
| If the engineer doesn't make an educated guess at the time it
| will take then the manager is put in the position of making a
| non-educated guess (because you can't effectively run a company
| without having any idea of either time or cost to deliver).
|
| The idea that it's possible to have a project with no budget or
| time constraints just isn't often the reality of the situation.
|
| Imagine going to a customer and having to say "Ok, we've talked
| to the engineering team and in order to deliver that feature
| you asked for they might be able to deliver it in a day for
| PS2,000 or in a year for PS500,000"
|
| This doesn't mean that you can't give sensical ranges, or state
| your assumptions when doing the estimate.
| [deleted]
| skydhash wrote:
| > On the flipside, it can be frustrating for managers that
| engineers sometimes can't understand that they have to manage
| deadlines.
|
| Deadlines are not solved by estimations. Deadlines are a
| business problem that can be resolved by a discussion with
| your engineer to work out a plan based on that time
| constraint. If you have a deadline in mind for a feature, it
| would be better to state it directly. Then the engineer can
| say it can or can't be done the way you wanted. Or we need to
| modify the requirements to fit it in this timeframe.
|
| But the most horrendous thing I've seen is when you give an
| estimation, the manager treat it as an actual deadline. It
| should only be used to verify if everything is progressing
| correctly and should be revisited periodically. But not to
| make promises.
| foldr wrote:
| >The idea that it's possible to have a project with no budget
| or time constraints just isn't often the reality of the
| situation.
|
| It must be possible because most budget and time estimates
| end up being way off anyway. Virtually no real projects are
| managed on the basis of accurate estimates of how long
| they'll take or how much they'll cost.
|
| Time is almost always more flexible than the people imposing
| the deadlines think that it is.
|
| As for budget, you just have to choose to keep spending more,
| or to stop (or wait till you run out of money). Making up an
| estimate beforehand doesn't alter that process.
|
| If management were really in the business of setting budget
| and time constraints, projects would constantly be getting
| canceled because they went $100 over budget or a week over
| time. In reality we all know what usually happens: the
| project simply continues; the estimates, deadlines, etc. are
| shifted.
| Closi wrote:
| > It must be possible because most budget and time
| estimates end up being way off anyway. Virtually no real
| projects are managed on the basis of accurate estimates of
| how long they'll take or how much they'll cost.
|
| Making decisions on the basis of an estimate which could be
| plus or minus 50% is fine.
|
| It's better than making a decision on the basis of nothing
| at all, and then managing the project with no clue about
| how long it should be taking or costing.
|
| > If management were really in the business of setting
| budget and time constraints, projects would constantly be
| getting canceled because they went $100 over budget or a
| week over time.
|
| This isn't the idea of estimates - the main idea is so you
| can effectively allocate resource and understand
| cost/benefit. All companies have limited resources and must
| decide if they want to focus on feature A or feature B, and
| part of that decision will be the likely cost, risk, and
| timeline to deliver.
|
| You aren't going to cancel a project when it goes (a bit)
| over budget because the development costs to date are
| already sunk (ie you only now need to consider remaining
| development effort in the cost/benefits calc) and the
| benefits are probably still the same.
| bryanrasmussen wrote:
| Most engineers can guestimate, but I do know one that would say
| the following:
|
| no idea, I will have to do two days of research on the matter
| and come back to you with an estimate in standup the day after
| tomorrow. (really, he said exactly that one time, it was a
| wonderful expression of his character I thought)
|
| The person who just says no idea, and doesn't have a way to get
| to an idea, seems to have a very problematic limitation.
| anarazel wrote:
| It's not uncommon IME that doing the work to come up with a
| reasonable estimate is 80% of the final work.
|
| E.g., addressing a scalability issue might require a bunch of
| profiling work, then a bunch of experimentation / thinking
| about developing a lock free algorithm. Or it might turn out
| that reducing false sharing a bit will give large enough
| benefit on its own. Without having done most of that I won't
| know whether it's a few days or many weeks.
| marcosdumay wrote:
| > It's not uncommon IME that doing the work to come up with
| a reasonable estimate is 80% of the final work.
|
| That estimate you do after finishing 80% of the work is
| probably orders of magnitude smaller than the real thing.
|
| More realistically, if you don't have the experience for an
| estimate beforehand, you also don't have the experience to
| know when you covered enough of the high-risk subproblems,
| so you have no basis at all to decide how complete your
| research is. You will only have a reasonably safe estimate
| by the time you finish the task.
| bryanrasmussen wrote:
| >E.g., addressing a scalability issue might require a bunch
| of profiling work, then a bunch of experimentation /
| thinking about developing a lock free algorithm. Or it
| might turn out that reducing false sharing a bit will give
| large enough benefit on its own.
|
| so this sounds like my example of my friend that I gave
| above who would say I will have to do a bunch of profiling
| work first and then a few days of investigation before I
| tell you how much it is actually going to take.
|
| I don't say you can't run into uncertainties and be unable
| to estimate until you have clarified those uncertainties, I
| also don't say that you can't run into uncertainties in the
| actual implementation and have your estimate be woefully
| off, not every estimate needs to be correct.
| wildrhythms wrote:
| I don't agree with this. If an engineer can't estimate how
| long something will take, usually that's an indication that
| your requirements are unclear, or there's a history of
| changing up requirements on people. What you've labeled as a
| limitation is probably an engineer being honest with you.
| bryanrasmussen wrote:
| ok so in this case I would probably expect them to say:
|
| the requirements are unclear - that right there is them
| having an idea how they are going to be able to give you an
| estimate, by forcing you to be clear in your requirements.
| That would actually be an engineer being honest.
|
| or
|
| there is a history of changing up requirements on issues
| like this, I can give you the estimate of what it will be
| with the current requirements but if the requirements
| change, as in my experience they are likely to, then that
| estimate will have to change as well. - this would also be
| an engineer being honest.
|
| Both of those honest examples aside if the engineer replies
| no I can't make an estimate and I never will be able to it
| is probably the engineer being a bit pissy. And I know
| definitely one or two guys who would exactly behave in this
| manner.
|
| unless you are dealing with the first time implementation
| of something that there is only mathematical theory backing
| it and no previous implementations in the world, I have a
| hard time seeing how you can construct a situation in which
| an engineer cannot come with an estimate AND cannot find a
| way to figure out what they need to come with an estimate
| (more specific requirements, research on the matter). If
| they can't figure out at least one of those things I'm
| going to think it is probably a limitation on the part of
| that engineer.
|
| Finally, I am an engineer. Although I tend to be one of
| those arrogant guestimaters, which is a failing in my
| personality.
| sokoloff wrote:
| I think the mismatch is partly that your early experiences
| (family, teachers, and team leads) are with leaders who
| literally know more than you about most topics and could do any
| task they're asking you to do. That imprinting is strong.
|
| Then, when you get to interact with Directors and VPs who have
| teams across 5-20 disciplines and the senior leader could be an
| expert in a maximum of one of them, you start to question why
| this person can't do your job and therefore think, they must be
| an idiot.
|
| They might be, but it's more likely they're past the point
| where they are more subject matter expert in the field than the
| people they lead.
| theshrike79 wrote:
| In those cases the correct answer is "Dunno, but I'll have an
| estimate by tomorrow after I do some prototyping".
|
| Then you do the janky prototype and try to extrapolate how long
| will it take to finish it properly. Then double that and be the
| miracle worker who delivers in half the time :)
| greenbit wrote:
| But do _not_ under any circumstances be tempted to
| demonstrate said janky prototype, unless you want to get re-
| tasked while said janky prototype gets merged into the build
| because 'schedule' .. and then be haunted by the damned
| thing for at least the next three years
| theshrike79 wrote:
| Yep, janky needs to look janky and be slow and break.
| Otherwise they'll think it already works :D
|
| That's also why you always keep the UI on par with the
| backend as far as completion goes. If the UI looks complete
| -> people think the backend is complete too.
|
| Only Coder GUIs until the backend is done :)
| threatripper wrote:
| I know exactly what you're talking about. The first rule of
| the meeting is "shut up" and the second rule is "keep
| silent" and "watch your mouth". I don't know why it is so
| hard to stick to those simple rules when the solution to
| the engineering problem seems so obvious.
| hibernator149 wrote:
| - Manager: How long would it take to migrate from A to let's
| say B?
|
| - Me: How would I know that?
|
| - Manager: Just make an educated guess.
|
| - Me: Maybe X months? I really don't know.
|
| - Manager writes down X.
|
| - Me makes a mental note to not trust Manager again...
|
| Maybe it's better to have any plan than to have no plan, but
| having a plan based on known bad data can't be the solution.
|
| Dear Managers, if your plan requires data that just isn't
| available, please take the time to ask yoursevles if you are
| micromanaging. Going with a less concrete plan is definitely
| better than going with a plan based on wrong assumptions! Maybe
| you are in a position where deadlines just make no sense and
| you need to be more agile?
| Ensorceled wrote:
| - Manager: How long would it take to migrate from A to let's
| say B?
|
| - Me: What do we want to accomplish from the migration? I'm
| assuming cost reduction?
|
| - Manager: Yeah, the guys at B are much cheaper.
|
| - Me: Ok, give me until EOD Friday to do some investigation.
|
| - Manager: EOD Thursday would be better, don't need a full
| roadmap, just enough for an ROI. I'll flip over the CEO's
| spreadsheet that she's using for the calculation.
|
| - Me: This means Feature X is dropping from this sprint.
|
| - Manager: Yep.
|
| Dear Mes: Grow up and participate in the process rather than
| starting off with snark.
| switch007 wrote:
| Hah if only managers were that grown up too. I've tried
| those conversations.
|
| Firstly, that Friday deadline likely would have been fine,
| it was just a power play.
|
| Secondly, when the manager said "yep" to dropping the
| feature, you'll still be expected to make progress. (Of
| course most of the time they try to make you do double the
| work. A quick "yep" wouldn't happen IRL)
| Ensorceled wrote:
| Get a new manager. Seriously.
| switch007 wrote:
| It hasn't been just one manager. I guessed you'd make
| that assumption though ;)
| marcosdumay wrote:
| How many times did you take a task you have no idea of the
| timeframe, do some short research without completing it and
| was able to make a correct estimate?
|
| If that happened even once, I would be interested to hear
| about it.
| ratww wrote:
| That's actually perfectly fine, as long as they don't treat
| the estimate as a deadline.
| tomohawk wrote:
| 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 wrote:
| 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.
| alephxyz wrote:
| > 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.
|
| I've worked with a few PhD's whose software engineering
| experience was limited to Matlab scripting. One even refused
| technical training because that's "not what they're interested
| in". Another co-worker with a masters still had no idea what
| they were doing after 4 years working there, often asking the
| same basic questions at a few weeks interval. Stuff like which
| branches to merge in a PR or questions that are answered
| verbatim in a readme file. Having to babysit educated people
| who refuse or are unable to learn is a great way to get
| demotivated. When those people start getting promoted to
| management positions and training junior employees is when
| things really start to derail.
| rossdavidh wrote:
| 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.
| hmmmcurious1 wrote:
| Scrum cargo culting whatever amazon is doing seem to work very
| well towards this end
| DoubleGlazing wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| BaseballPhysics wrote:
| > 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 wrote:
| 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 wrote:
| I think the difference is that a forecast is developed by a
| team (or formula/ML) separate from the engineers doing the
| work.
| ChrisMarshallNY wrote:
| _> 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._
| netfortius wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| mkl95 wrote:
| 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 wrote:
| 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.
| dalbasal wrote:
| 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.
| kqr wrote:
| This is a great point. I've never thought about it in these
| terms before, but whenever I've transitioned from organisations
| that feel like they're "run by engineers" into organisations
| that feel like they're "run by administrators" I've taken a hit
| in happiness.
| pid-1 wrote:
| > 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 wrote:
| 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."
| computronus wrote:
| This sounds like a variation of Brooks's Law - adding
| people to a late software project makes it later. In this
| case, now you need to take time to help the new resources
| ramp up, and the new resources themselves can't make
| meaningful contributions right away. So the pressure isn't
| alleviated for a while, and in fact goes up.
| mr90210 wrote:
| 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 wrote:
| I think engineers often say "we need more resources" but
| mean "we need to have hired more resources two years ago".
| dalbasal wrote:
| One liner of the day. That's the best possible way to
| make this point.
| ratww wrote:
| True. In some cases it can also mean that the team needs
| to limit the scope and focus on what really matters.
|
| Sure, there's lots of startups burning the midnight oil
| to finish that MVP. But especially on more mature teams,
| it's incredibly easy to lose focus when doing software
| and spend several days on shitty features that don't
| really matter at all to customers, but are being
| prioritised due to inertia or capricious management.
| therealdrag0 wrote:
| Yap, I'm leading a project that could use more engineers
| (just two of us) cuz it's going to be tight to hit an
| upcoming scaling deadline. But the thought of spending my
| time ramping up other engineers at this point doesn't
| sound good.
| quantum_state wrote:
| Very much true but not really recognized by management in
| general.
| iancmceachern wrote:
| I would argue it applies to most engineering disciplines, not
| just software.
| Buttons840 wrote:
| > An effective 15 person team can outperform a 150 person team
|
| Which is subtly different than saying a 15 person team can do
| the same job as a 150 person team. The full story is the first
| 15 people (be they developer or project managers) will
| determine whether you need 150 people in the future.
|
| Naturally, all of my jobs have been at 150 companies (since
| that's where most of the jobs are), places where the earlier
| developers and PMs have balloon the amount of work to be done
| is a very unhealthy and inefficient way. Then I'm hired and
| continue to do the same.
|
| I learned about R0 ("r not") in the pandemic, the number of
| other people someone infects on average, and I've imagined a
| "W0" at my jobs. How much work does a developer, on average,
| add or remove from the future of the company? Unfortunately, I
| believe I am a >1 W0 developer in my current job, my current
| work will only create more work in the future, and the company
| will have to hire more and more developers forever. I don't
| consider this my fault, but the fault of project management.
| It's also why I'm not worry about future job security.
| Jensson wrote:
| People who want to be managers tend to create solutions where
| you need to assign more reports to them. I don't think this
| is incompetence, it is a reasonable way to advance your
| career at the expense of the company, similar to how
| engineers tend to choose frameworks that helps their careers
| etc.
| Jare wrote:
| > If you're in one of these orgs, you will not be more happy
| though. Efficiency feels good. Inefficiency feels bad.
|
| Depending on your outlook, character and experiences, the
| magnitude of the results can make it worth your while; there's
| certain objectives that you can't hit without massive
| throughput (and waste). And reducing or keeping under control
| the amount of waste in a large scale project can also be
| incredibly satisfying.
| cebert wrote:
| 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 wrote:
| 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 wrote:
| Depends on the company. At BigCorp Inc., that sounds like a
| great way to get on management's bad side
| nonrandomstring wrote:
| 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".
| FrankyHollywood wrote:
| 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.
| nonrandomstring wrote:
| Yes, I think it would. Anthropology.
|
| Way too late in life I discovered what anthropologists
| actually do after stumbling upon Alan McFarlane's lectures
| about "The origins of Modernity" [1]. Nobody ever made
| history seem so interesting and clear why What's Past Is
| Prologue. A big shout-out to all anthropologists!
|
| https://fortnightlyreview.co.uk/2013/07/anthropology-
| empire-...
| kqr wrote:
| Gerald Weinberg has a bit of an anthropological take (due
| to his wife being an anthropologist, IIRC) in his Quality
| Software Management series.
| lifeisstillgood wrote:
| I argue it's democracy. (That can save Nations and presumably
| companies)
|
| Imagine voting for the CEO. Imagine voting to allocate budgets.
| Yes there will be a lot of pork barrel- but it might just work.
|
| I mean the idea that companies are like single cells / autonoma
| so they don't have to be democratic leads us to silly ideas
| like trying to put in place rules for not abusing the
| electorate.
|
| I mean if a boss is sexually harassing all the female staff and
| then asks for their vote at the next manager election, you
| won't need HR intervention to get rid of him.
|
| I have no idea truly how this might work, but I do think that
| if the employees of a company voted how to run it you might
| find some unusual outcomes.
| grayclhn wrote:
| You vote by changing jobs. I think "real governments" make it
| clear that this isn't sufficient to thwart harassment though.
| edgyquant wrote:
| Maybe but that can also stifle innovation. If Netflix had
| been a democracy they likely wouldn't have voted to switch to
| the unproven online streaming business, etc.
| lifeisstillgood wrote:
| Really?
|
| I mean that was what 2000? 2002? Peak dotcom time.
|
| I don't agree with the decisions all these humans sometimes
| make (cough Brexit cough), but that's not the point - as
| long as we don't vote away democracy, as long as we trust
| the other side has everyone's best interests at heart, then
| we can manage
| JonChesterfield wrote:
| Security above output is a big deal. Put email behind the
| unreliable VPN on the magic corporate laptop of extra slow
| booting when we used to read it through an arbitrary web
| browser and revel in the increase in tail latency on replies.
| From minutes to days.
| wildrhythms wrote:
| 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 wrote:
| 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.
| elric wrote:
| Is there a story behind all this bitterness?
|
| MFA for every login is a very good idea. If you're having to
| log in to the same service over and over again within a short
| amount of time, someone is doing something very wrong.
|
| Sending out company newsletters seems like a nice way to let
| everyone know what the company is up to. Not sure how you go
| from that to reminding lowly engineers of their
| "insignificance".
|
| Social events are a great way to get to know your coworkers and
| to improve cooperation. Awareness training (I'm imagining you
| mean things like Security Awareness and such) also seem like an
| overwhelmingly good thing.
|
| Everyone has actual work to do. All the stuff you perceive as
| meta comes with the territory of working anywhere with a non-
| trivial number of people.
| ThePadawan wrote:
| > Sending out company newsletters seems like a nice way to
| let everyone know what the company is up to. Not sure how you
| go from that to reminding lowly engineers of their
| "insignificance".
|
| I agree with both you and parent.
|
| I've enjoyed getting a monthly newsletter by email in past
| jobs, letting me know "hey so we just signed a contract with
| a client that is twice as big as the biggest one we've had so
| far". Makes sense - I'm not the one to be greatly inspired by
| something like that, but it's good for perspective.
|
| I've also worked at a company where every single salesperson
| was allowed and encouraged to email all@company.com whenever
| they closed a sale. This was around 3 times a week.
|
| Not terrible - however, everyone _in the company_ was also
| _officially encouraged_ to "congratulate" any such
| "successful sales" emails with "encouraging words" such as
| simply adding "Congrats!" and hitting "Reply All".
|
| The head count at this company was around 400.
|
| I wish I was kidding.
|
| I think I lasted 3 days before I created a filter rule in my
| email client.
| Yahivin wrote:
| I hope the filter rule auto-replied "Congrats!" and
| archived the thread :)
| ThePadawan wrote:
| Thankfully, I was not part of sales.
|
| But looking back (I have left this company since then), I
| believe your strategy would have genuinely had a positive
| effect on any employee's career path.
| nonrandomstring wrote:
| > Is there a story behind all this bitterness?
|
| Does it even need saying? Of course there is. Many stories.
| Over many decades. It's sad watching great people quit and
| wonderful projects die because of a poor working environment
| and the selfishness of others who inflict their narrow values
| in others. If you're one of the people who see these as good
| things then naturally you'd frame criticism as "bitterness".
| But as another commenter said, these are personal stories.
| Your own subjective peeves might strike me as strange. Do
| please open your mind to a world that contains different
| people with different values.
| _djo_ wrote:
| > Sending out company newsletters seems like a nice way to
| let everyone know what the company is up to. Not sure how you
| go from that to reminding lowly engineers of their
| "insignificance".
|
| Speaking as someone working in a small company that was
| acquired by a much larger corporation that shows all the
| signs being discussed here, it's not just newsletters. Those
| are useful. It's being sent dozens of spammy emails a week
| about initiatives that are clearly some VP's ego project and
| have no relevance you other than clogging your inbox and
| taking away some of your time and attention.
|
| One recent example I got was three days of emails telling me
| to 'get ready' for an internal initiative but mentioning
| nothing else except a name. No links to click, no calls to
| action, no useful information at all. Only for the final
| email to reveal it was about a non-strategic initiative that
| applied to some other site only, despite all the emails being
| sent to the global company. All attempts at getting that sort
| of thing off the all-hands mailing list have been rejected.
|
| A place that thinks that's okay does not respect the time or
| attention of its employees, and it does tend to make you feel
| reminded of your insignificance.
| bobthepanda wrote:
| MFA is ideally combined with SSO so you auth at most once a
| workday.
| alfiedotwtf wrote:
| I can also think of "hire to fire" because of management fire-
| quotas... team moral must suck when HR-enforced curve fitting is
| policy
| spookierookie wrote:
| 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.
| flappyeagle wrote:
| 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 wrote:
| 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 wrote:
| 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.
| therealdrag0 wrote:
| I'm not a manager but I've observed managers stay technically
| strong by being involved in technical activities. Participate
| in design reviews, project planning, on-call issues etc.
| being able to smell good vs bad system design does not change
| that fast. Also they'll occasionally bust out a ticket that
| only takes a few hours, aka still able to commit code. I
| don't think this is unreasonable for edge level managers. I
| even get good insight from managers at the director/vp level
| at where I work.
| AtNightWeCode wrote:
| 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.
| perrygeo wrote:
| 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?
| skeeter2020 wrote:
| 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 wrote:
| 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.
| drc500free wrote:
| 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.
| [deleted]
| Jugurtha wrote:
| From: 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.
| mannyv wrote:
| 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.
| sharmin123 wrote:
| 23B1 wrote:
| 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.
| dasil003 wrote:
| Maybe it's because I've always straddled the line between IC,
| EM and leadership roles, but in my mind engineers _are_
| managers. They are managers of software systems. The software
| systems are producing some economic output just as human or
| animal labor does in other domains or historical contexts. When
| you write code and deploy it to a production system, you are
| responsible for the behavior, cost and other implications of
| doing so.
|
| Although I believe managing people is generally the harder of
| the two overall, managing software systems is uniquely
| demanding of being able to zoom into deep technical details and
| then back out to understand the big-picture implications and
| where different layers of abstraction may have failed. To call
| oneself a senior software engineer I believe you need both the
| technical understanding as well as the big picture view of what
| business value your code produces.
|
| Many software engineers don't want to think that way; they look
| to the Product Manager to tell them what to build, the QA
| Analyst to sign off on releases, the Ops Engineer to tell them
| what broke, and the Engineering Manager to prioritize their
| time. And of course those asks do align with the job
| descriptions and are not wrong per se. The problem is that the
| SWE is in a much better position to foresee the majority of
| problems, and can save the company as well as their team a
| tremendous amount of pain by trying on different hats and
| thinking at a higher level. Not all company cultures make this
| possible, but IMHO it is the key to the highest performing
| teams.
| grayclhn wrote:
| This is usually why people make the distinction between
| "leadership" and "management" -- if you use "management" the
| way your comment does, you no longer have a word for someone
| with multiple direct reports.
|
| But yes -- totally agree that "technical leadership" is 100%
| part of being a senior+ engineer and that almost always
| requires understanding the business and customers.
| astura wrote:
| 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.
| proxyon wrote:
| Are you a people manager? If so, what is the turnover like on
| your team? I ask because the author is dead on and I've been
| in this industry for 10 years.
| astura wrote:
| If you wanna make this a competition I've been in the
| industry for 16 years.
|
| I'm a technical lead which does have a little bit of people
| management responsibilities. Turnover on my team is
| probably well below average, we had two developers leave
| for other jobs in the last year out of 15 developers and
| one fired for poor performance. I can't remember anyone
| leaving the year before.
|
| To be clear, I don't think this article is wrong per se,
| just obnoxiously naive and doesn't have any empathy for the
| real world constraints that people have to work with. It's
| just... uhhh... rubs me the wrong way.
| proxyon wrote:
| Tech leads don't have people management responsibilities.
| An engineering manager with your perspective would
| quickly find themselves without any talented developers.
| I did not write the OP but you're coming in with the hot
| take that it doesn't matter how people feel about their
| jobs and that is by the far least controversial part of
| the article and one that you're out of sync with 90% of
| the community on.
| WJW wrote:
| 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 wrote:
| > 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.
| [deleted]
| LadyCailin wrote:
| Yeah, but if a business owner decides "x" is the purpose
| of work, and literally no one wants to do that because of
| the conditions that the business owner has created
| (especially if the conditions are tangential to x), then
| that is the business owner's problem, not the employees
| problem.
| legulere wrote:
| 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.
| the_gipsy wrote:
| There are so many actors and groups and dynamics and forces
| in effect in the relations that we commonly call "work", that
| trying to reduce it to a single purpose is laughably naive.
| mruniverse wrote:
| I think people would be much happier if they find amusement
| and self-actualization in the work they do.
| EnKopVand wrote:
| I think the point here may be that when you're dealing with
| an occupation in which the best engineers can pick and chose.
| Then you're likely to lose your best engineers unless you're
| exceptionally good at managing them. Especially if you
| introduce boundaries and restraints.
|
| I'm not sure it's naive to view the world like the author
| does. I've worked both sides of the fence, and while I'm now
| back in software development I do see the appreciation for my
| experience with creating the most business value out of your
| resources that managers come with. The thing is, though, if I
| don't have to work in a place with too much bureaucracy or
| too many constraints then I'm not going to do so. I obviously
| try not to be an asshole about it. I don't follow the company
| dress code in the basement troll factory where they placed
| IT, but I do have a suit at work that I can change into
| whenever I leave the "cave". Those sort of things, so
| naturally I'll play a long way in regards to what management
| want, but I'm never going to do estimates by the hour until
| the job market actively forces me to do so. Which likely
| won't be in our lifetime. So when/if management go down the
| route of treating Software Development like they treat any
| other department (which like you state also are under
| significant constraint) then the company is just very likely
| to lose their most talented developers very quickly. I
| suspect that it would be (and probably is) exactly like that
| in any department, it's just easier to get away with in
| engineering because we're privileged enough to be able to
| leave our jobs today and have another good job by tomorrow.
| 23B1 wrote:
| > the best engineers can pick and chose
|
| Sorta. I would take a less-qualified but more personable
| engineer over their more capable peer any day of the week,
| for the aforementioned reasons: engineering isn't the only
| skill required - those who don't insist on managerial
| perfection don't actually need a lot of managing as a
| result. It's a positive feedback loop.
|
| Also if engineers think we don't check references and
| backgrounds anymore - including reputation - those days are
| long past. It's too much of a liability to have the
| 'talented asshole' as part of a team anymore.
|
| > Especially if you introduce boundaries and restraints.
|
| Boundaries and restraints are a professional reality.
|
| > So when/if management go down the route of treating
| Software Development like they treat any other department.
|
| It's this exceptionalism that earns engineers the
| reputation of being jerks, and creates a negative feedback
| loop. Want to be free and clear to operate without too much
| bureaucracy? Play the cooperation game. This is as true
| with engineering as it is literally any other thing that
| requires more than one human.
| DangitBobby wrote:
| You're doing a lot of assuming that the engineer seeking
| greener pastures because they are, I don't know "selfish"
| or something, is easily detectible. I can confidently
| tell you that you're operating under self delusion.
|
| Also assuming that someone who isn't going to tolerate
| fuck-fuck games with assholes when they don't have to is
| themselves an asshole. It's entirely possible to amicably
| end a relationship with someone (a business) you can't
| stand, with them none the wiser that it was ever about
| something other than compensation.
|
| > Want to be free and clear to operate without too much
| bureaucracy? Play the cooperation game. This is as true
| with engineering as it is literally any other thing that
| requires more than one human.
|
| This is pure hopium. Bureaucracy is installed in
| anticipation of growth/security/safety gains, and
| existing success of the team can be completely ignored by
| someone who thinks the good of bureaucracy will outweigh
| the harm.
| msrenee wrote:
| I'd say the more personable engineer is the more
| qualified engineer even if their technical knowledge is
| less. Being able to deal with other people is a massive
| part of being good at the job.
| p1esk wrote:
| _if engineers think we don 't check references and
| backgrounds anymore - including reputation - those days
| are long past_
|
| How do you check reputation?
| woevdbz wrote:
| ?? Where is there any reference to amusement or self-
| actualization in TFA?
| proxyon wrote:
| If you read between the lines what he's saying is that it
| doesn't matter if engineers enjoy the job.
| CipherThrowaway wrote:
| Agree re the article, disagree re labor vs management. This
| mentality in an org is almost always a result of mismanagement.
| The reason is obvious: it's a people issue and dealing with
| people issues is a managerial responsibility.
|
| Thinking that managers are bad in general is only a sign of
| inexperience because it implies someone has never worked in a
| place with good management before. I've seen plenty of "fuck
| management" types completely chill out after moving to a better
| workplace.
| bloggie wrote:
| I'm not sure I would want to run a company without any gantt
| charts or deadlines. Management needs to know when a project
| becomes unmarketable or unsustainable so that project can be
| killed and resources moved to more viable projects. These
| decisions depend on variables that engineers can't see, though
| budgets and timelines are a few of them. Of course engineers
| can't take it personally when a project is killed either - some
| projects turn out that way. The best engineers know this. Your
| comment highlights well the narrow view of the subject article.
| q-big wrote:
| > The 'best engineers' empathize with the perspective of
| 'management,'
|
| I deeply disagree with this argument of "empathizing": it is
| very often the case that if I tend to disagree with another
| side and nevertheless attempt to "empathize" with it, my
| disagreement turns into furious hate for the other side.
|
| It is in my opinion often better for the peace not to think too
| much about the perspective of another side that you disagree
| with.
| pikaynu wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| edem wrote:
| 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.
| pluc wrote:
| > Design your organisation to minimise collaboration between
| teams, but have high collaboration within the team.
|
| this is a joke right?
| perlgeek wrote:
| 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.
| lloydatkinson wrote:
| 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 wrote:
| I've lost hope of anyone at the top figuring it out.
| woutr_be wrote:
| 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 wrote:
| Just 1 day? pfft
| hownottowrite wrote:
| 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 wrote:
| 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.
| anonymoushn wrote:
| Nobody asked for walls in an exit interview? All of the engineers
| you spoke to enjoyed debugging while listening to sales calls?
| Linda703 wrote:
| astura wrote:
| 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 wrote:
| In practice, they still have all the same hierarchy, except
| it's not as obvious.
| astura wrote:
| Yep, plus nobody ends up having any accountability to boot.
| JJMcJ wrote:
| Typically flat means anyone in Sales or Marketing can give
| orders to any developer and must be obeyed instantly.
| dadoge wrote:
| 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?
| [deleted]
| revskill wrote:
| 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!.
| katzgrau wrote:
| "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.
| drdec wrote:
| I disagreed with this point in the article. I do not need a
| manager that has done my job before or spends a week a quarter
| doing my job. I need a manager that knows how to get my team
| the resources it needs and knows how to to deliver a product.
| Most importantly, I need a manager that trusts the team.
|
| I've had great managers that couldn't code their way out of a
| paper bag.
| cloverich wrote:
| Yeah i agree and think it can even be phrased as just not
| micromanaging. You understand which resources benefit the
| team and delegate a certain amount of trust to trustworthy
| individuals. Then hold them accountable to that trust. Dont
| dump stuff on them and dont jerk the wheel. Share your
| constraints; etc. Learn who is good at leading,
| communicating, etc. Do skip level 1:1s to validate your
| assessments and understand boots on the ground.
|
| I use to also think being technical was a part of that but
| now i think being a good manager is worth much more on its
| own.
| watwut wrote:
| > 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.
| forgotusername6 wrote:
| There are different types of hard. Digging ditches is hard
| work, getting people to do what you want them to do is hard
| work, writing complex software is hard work. When engineers
| think about hard work they usually think about it being
| intellectually difficult. It isn't arrogance, more that they
| are just focusing on the definition of hard work that they are
| used to.
| wildrhythms wrote:
| Do you think someone is qualified to manage a process they
| don't understand?
| greymalik wrote:
| Do you think it's impossible for someone to understand a
| process without having years of experience doing it
| themselves?
| marcosdumay wrote:
| At least a few days, yes, it's impossible.
|
| But more importantly, it's impossible to manage a process
| that you don't know how to do yourself. The closest you can
| get is on a client-seller relationship.
| onethought wrote:
| The inverse question, is it even possible to have a manager
| who understands every nuance of the process they manage?
| katzgrau wrote:
| I find that, in practice, the more a manager knows about
| how things are done - the more they have the urge to
| micromanage and resist delegation, especially if they're
| perfectionists.
|
| Doesn't sound completely horrible in theory but in reality
| it's bad for everyone.
| katzgrau wrote:
| There's a group of these people called CEOs and they get paid
| a lot.
| unsupp0rted wrote:
| They manage a process they do understand (in theory):
| getting groups of people to do valuable stuff without
| irreparably imploding.
|
| I don't understand any of the tools I use in my own work
| (how does VS Code do syntax highlighting? How does the
| electricity make my laptop screen show me high resolution
| colors?). But I'm still able to produce plenty of value for
| my clients.
| brongondwana wrote:
| By far the hardest part of that transition (at least for me!)
| is going from being able to create measurable impact on the
| order of days to most things taking months or years to create
| real change.
|
| As a coder, I could get a bug report, build a fix, test it, get
| it deployed within an hour if it was urgent and simple.
|
| Now I do a lot of listening, a little bit of talking, a bunch
| of thinking and discussing with the rest of the executive team,
| and mostly make small corrections which might show meaningful
| results in 6 months' time. Every so often there's still
| something really amazing and valuable, but it's much rarer and
| less predictable when that's going to be.
|
| And yeah tons of new learning to do. Being a good programmer
| doesn't automatically translate to being good at running a
| company (though understanding tech and having been there
| certainly helps both for understanding what your staff are
| going through, and having their respect)
| CipherThrowaway wrote:
| I strongly agree that managers do not need to be technical or
| understand dev work. However, I don't have much sympathy for
| managers who are "misunderstood" by engineers. Companies that
| have issues with disgruntled engineers grumbling about
| management and process are mismanaged almost by definition.
| noduerme wrote:
| 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 wrote:
| 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 wrote:
| This. Oh definitely, this.
| gonzo41 wrote:
| 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.
| forgotusername6 wrote:
| Nevermind unmerged PRs. I've known engineers who spent years
| on a product only to have it canned when completed due to
| political reasons. They all left soon after, quite
| understandably.
| wildrhythms wrote:
| And when performance reviews come around the person who built
| the thing never gets appropriate credit because it never
| launched (not their fault). :/
| lawgimenez wrote:
| I agree with this one. Nothing frustrates me more than the huge
| friction from PR to deployment.
| [deleted]
| a-walker wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| greymalik wrote:
| I'm a developer who's been doing this for a loooong time
| and I can't imagine being able to accurately guess with
| 90% confidence the calendar day I'll have a particular
| task done. And the tasks I work on are different enough
| that a feedback loop about how much I misguessed would be
| useless for error-correcting future estimates. Maybe that
| works for factory-like tasks like how long it tasks to
| add a REST endpoint for a CRUD action?
| kqr wrote:
| No, it works for anything. The key that people
| misunderstand is that if the task is really uncertain,
| you're allowed to give a really wide range. In fact,
| you're supposed to -- that's the only way you can be
| correct 90 % of the time.
|
| As a concrete example, I recently estimated "somewhere
| between 1 week and 4 months" when asked about an semi-
| well specified feature because I felt there's a 5 %
| chance it's done in less than a week, but even under
| pessimistic assumptions, there's about a 5 % risk it
| takes longer than 4 months.
|
| When asked about a larger, unspecified projects a few
| years ago, I didn't hesitate to respond "between three
| months and 15 years". Sometimes that's the best you can
| do due to the uncertainties involved. It sounds useless,
| but it's really useful to have a quantitative measure of
| the uncertainty.
| marcinzm wrote:
| My company right now does OKRs with priority levels for each
| task. If you make it a P0 then you're saying it will get done
| this quarter baring really unexpected circumstances (ie: shit
| happens, we understand). P1 may not get done. P2 is even less
| likely to get done. This creates a natural distribution by
| holding the date constant and varying the work done by that
| date. Personally I find this more reliable and easier to
| communicate than holding the work constant and varying the
| date of each item.
| kqr wrote:
| To be honest, I also like that approach better, because in
| my experience the budget tends to be relatively fixed, but
| the work amount is often fairly flexible.
| ebiester wrote:
| Forecasting looks like this: https://medium.com/expedia-group-
| tech/monte-carlo-forecastin...
|
| It's running through simulations based on previous team
| behavior to give a range.
| biztos wrote:
| Don't you still have to correctly estimate the amount of work
| (time) to complete each task in your backlog?
|
| You can apply all the "science" you want, but at the bottom
| of it all you have engineers holding up a card with a "4" on
| it when the scrum dude says "add date picker to the Foo
| widget."
| ebiester wrote:
| When I did this last, we incorporated size of epic instead
| and looked at number of tickets on average. You still have
| to break it down but you can take into account the number
| of added tickets given a large enough sample size.
| satyrnein wrote:
| You still need story point estimates on the previous items,
| or some reason to believe that previous stories were of
| similar size (which is also a form of estimate).
| woevdbz wrote:
| 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 wrote:
| > 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?
| dilyevsky wrote:
| In my time Ads org had some pretty interesting engineering
| challenges, relatively fast promotion track and good pay
| kidgorgeous wrote:
| Yes. First rate engineers are designing rockets at Space-X
| allgreed wrote:
| 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 wrote:
| 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
| throwaway98797 wrote:
| lol
|
| brilliant engineers can have crippling life leaks that make
| them work at shitty but well paid places
| davesque wrote:
| This would only be true if finding another job was a simple
| (and reliable) process for most people. I imagine you might
| come back and say, "But finding another job should be easy for
| a talented engineer!" To which I would say, nope! Not true! The
| tech interview grind is often inconsistent and demoralizing.
| Even talented people might make a reasonable calculation to
| avoid the trouble and just stick with their current job.
| bradlys wrote:
| Correct. People also assume that you're always going to get
| paid more at a new gig. This just isn't true in SV. If you
| joined a startup and it rocketships - I've seen many smart
| engineers stick around for years just because they have a
| 7-fig TC. Why would they move elsewhere? Just isn't
| financially responsible and most are willing to suffer
| through it as far as I've seen.
___________________________________________________________________
(page generated 2022-07-24 23:02 UTC)