[HN Gopher] Getting things "done" in large tech companies
___________________________________________________________________
Getting things "done" in large tech companies
Author : swah
Score : 263 points
Date : 2025-05-06 11:04 UTC (11 hours ago)
(HTM) web link (www.seangoedecke.com)
(TXT) w3m dump (www.seangoedecke.com)
| dcminter wrote:
| Absolutely true, and absolutely one of the reasons that working
| in large tech companies can be soul destroying.
| underdeserver wrote:
| I see it completely differently.
|
| If the execs don't see the value, customers don't see the
| value, and you can't prove money is being made (or saved),
| where is the value of your work, really? You're not paid to
| make art.
| lazide wrote:
| Well, that is also why large segments of the big corp work
| environment check out and do the absolute minimum - or even
| create chaos to make it less obvious who is doing what for
| whom.
|
| Because the paycheck is indeed useful for them, eh?
| underdeserver wrote:
| These people are comfortable collecting a paycheck despite
| providing little value. I'm not.
| lazide wrote:
| Sounds painful!
| dcminter wrote:
| Do you like working with those people? That's part of it.
| underdeserver wrote:
| Some of them I do, some not. They generally believe it's
| their bosses' responsibility to make sure their work is
| valuable. I guess that makes sense, but I'd like to own
| that responsibility myself.
| ta1243 wrote:
| This is why small companies can compete. What they lose out
| on economies of scale, they gain on avoiding this.
| lazide wrote:
| They can also get completely nuked by market forces a lot
| easier.
|
| Also, pay is usually a lot less.
| dcminter wrote:
| You're right, but this assumes that the execs have the
| insight to see that maintenance tasks save money. If
| preventing next year's incident isn't understood as being as
| valuable as doing the hero work to untangle this year's
| incident then it can be hellish unless you like hero work.
| whstl wrote:
| I don't disagree with the article, but after working in big tech,
| two HN startups, a couple unicorns and others, in two continents,
| I don't really find this too actionable.
|
| In the last ten years (and even in the 20-people HN startups),
| the day to day work of engineers has become so incredibly
| specialised and divorced from the needs of decision-makers _and_
| the customers that there is almost nothing I can do to influence
| whether someone views me as doing my job or not. Mainly because
| of the presence of Product Managers that insert themselves
| between engineers and the rest of the company.
|
| I'm always interested in delivering value, but the fight
| necessary to actually do so has become stressful. It's no longer
| a collaboration, all my contributions must be filtered through
| the ego of the person speaking to decision-makers.
|
| In fact, the only time I was actually _satisfied_ with my work in
| the last 5 years (as opposed to my paycheck) was when I was
| acting as interim Product Manager for 9 months. Unsurprisingly,
| me and my team managed to deliver three projects that other teams
| tried and failed several times.
|
| Most of that was accomplished by communicating with stakeholders
| and actually figuring out what they needed, rather than endlessly
| "trying to put my own spin" on it.
|
| So yeah, I'm gonna keep delivering whatever is asked, getting the
| blame for bugs and not getting the credit for features. At least
| the pay is alright. I'm constantly searching for the place where
| I can actually fully contribute, though.
| _fat_santa wrote:
| > At least the pay is alright.
|
| I don't know why but this part of your comment really stuck out
| to me. I have a whole different take on getting stuff done
| specifically at big tech companies, mainly that being
| "stagnant" is not such a bad thing at a place like Google or
| MS.
|
| Say you're like an L-whatever at one of these big tech
| companies and you bring home say $300k/yr. You don't live in a
| HCOL so the pay is astronomical compared to anywhere else and
| even if you work on the same boring project for 10 years there,
| you can still say you spent 10 years working at MS or Google
| and that would get you red carpet treatment just about
| anywhere. I'm sure this would bug a go-getter and would
| certainty bug a younger version of me, but if you're that kind
| of person you're most likely trying to work at a smaller
| company where you get more say and sway.
|
| And to add a bit more to this it's not like I don't care, it's
| just what I care about has changed over the years. When I was
| younger I was concerned with climbing the ladder and getting
| prompted. Now that I'm older I care way more about my family
| and friends than I do my company. If I was at one of these big
| tech companies and someone told me I was stagnant and would
| never get prompted I would just tell them so what. I bring home
| $300k for my family and I have a good work life balance (most
| likely). And do I really give a damn about the initiatives of
| some corporate behemoth, no and to be totally blunt the only
| thing I like about them is the paycheck and what it does for
| the rest of my life (all the free shit at the office is just a
| bonus).
| pydry wrote:
| That sounds great if you can ride that into retirement but if
| you get laid off and you start having to justify your
| existence again in the job market I dont think "I took home
| $300k for doing nothing and then got laid off" is a great
| sell.
| _fat_santa wrote:
| But that's kinda the beauty of it. If you get laid off from
| one of these places the next place doesn't know that you
| took 300k home to do jack, all they know is you worked for
| a super prestigious company for 10 years and you can
| plausibly make up the rest about what you actually did
| there.
| yawgmoth wrote:
| > you can plausibly make up the rest about what you
| actually did there.
|
| I would never do this, and if you would do this I
| wouldn't want to work with you. Maybe I'm a sucker, but I
| sleep alright.
| chausen wrote:
| What about actually accomplishing some things over 10
| years while maintaining good work life balance?
| whstl wrote:
| That's the dream, but it requires either luck (to fall
| into a great company) or burning of political capital
| (plus luck).
| dbalatero wrote:
| It's not like the parent would have accomplished nothing
| in the 10 years. I think they are just talking about
| framing it in language palatable to the interviewer
| across the table.
| whstl wrote:
| Even in the most dysfunctional organizations you can't
| spend 10 years doing nothing.
|
| GP was achieving what their bosses asked of them. It's
| just that it didn't align with their own professional
| goals of improving the product they work on.
| kunzhi wrote:
| Sorry, 20 years experience of actually doing things here.
| I've spent 10 of those years now doing consulting with
| everyone from 3-person pre-series-A startups all the way
| up to the Fortune 50.
|
| Let me unequivocal: you can spend 30-40 years at a
| company _doing absolutely nothing while getting paid for
| it._
|
| Do not let anyone try to convince you otherwise. I've
| seen such much unethical bloodsucking in my career that
| at this point I wouldn't mind seeing a few companies
| collapse under the weight of their own karma.
| bluefirebrand wrote:
| > Let me unequivocal: you can spend 30-40 years at a
| company doing absolutely nothing while getting paid for
| it.
|
| Maybe this was true for 40 years from the 70s to the
| 2000s, or maybe even the 80s-10s, but I don't think this
| is true anymore
|
| Certainly not in software engineering, in a world run by
| JIRA
| joezydeco wrote:
| You haven't been on LinkedIn in the last few years, then.
| johnnyanmac wrote:
| unfortunately I have. It is indeed a hellscape of, as the
| kids say, "aura farming". Microsoft really seem to want
| to turn it into Instagram for some reason.
|
| I still use it as a job board, personally.
| happymellon wrote:
| Is there any other meaningful job board (outside of
| "whose hiring" on hn)?
|
| I haven't had to apply for a job for a while, so
| genuinely curious what people would use these days if
| there wasn't anything coming via word of mouth.
| toomuchtodo wrote:
| https://hiring.cafe
|
| (no affiliation)
| babyent wrote:
| Chances are high anyone to corroborate was laid off and
| does the same thing anyway lol
| babyent wrote:
| Chances are high anyone to corroborate was laid off or
| has moved on, and does the same thing anyway lol
| blitzar wrote:
| There is a very high probability that someone you work
| for did just this.
| stronglikedan wrote:
| Everybody does this to some degree. Even you.
| ImPostingOnHN wrote:
| If you're going to lie about experience anyways, you
| don't have to work for the FAANG company in the first
| place.
| anon84873628 wrote:
| It's not lying about your experience. Just not hustling
| to "get things done" or caring so much about personal
| satisfaction in the work.
|
| Better to do some carpentry or pottery outside of work
| and put your pride in that.
| masom wrote:
| This becomes quickly apparent in a smaller company or if
| you have a manager that knows what they are doing.
|
| You'll get hired, if you pass the technical interviews,
| but if you cannot contribute at the level they hired you,
| you'll be exited and that will be suspicious for your
| next application.
| thinkingtoilet wrote:
| >but if you cannot contribute at the level they hired
| you, you'll be exited
|
| But this is the case for anyone anywhere, it doesn't
| effect the OPs position one way or another.
| johnnyanmac wrote:
| it'd be quicker if they feel you either lied or do not
| live up to your name. Easier to fire you and find someone
| on your level but much cheaper.
| blitzar wrote:
| > This becomes quickly apparent in a smaller company or
| if you have a manager that knows what they are doing
|
| Sounds like an unlikely problem and by then you can pull
| a reverse end run around your manager to their manager
| who doesn't know what they are doing and will believe
| anything the guy who worked at google says.
|
| Most people here actually work for _that_ guy.
| bluecheese452 wrote:
| If you took home 300k for 10 years then you don't have to
| worry about getting a job.
| PaulHoule wrote:
| For many people expenses expand to fill income. Some
| people think that the real brilliant investors of the bay
| area are the real estate investors who captured all the
| value.
| jsight wrote:
| I don't think the point was literally doing nothing, but
| rather doing solid technical work with relatively low
| business value.
|
| This person could move on to do solid technical work with
| higher business value at a place that used their skills
| more effectively.
|
| The former isn't great, but it is a reality at many big
| companies.
| johnnyanmac wrote:
| >you bring home say $300k/yr. You don't live in a HCOL
|
| Oh, I didn't know we were fantasizing about 2022.
|
| > you can still say you spent 10 years working at MS or
| Google and that would get you red carpet treatment just about
| anywhere.
|
| well, not in 2025. Market is rough and it's all topsy tuvrvy
| out there, with lots of companies pretending to hire but not.
|
| >If I was at one of these big tech companies and someone told
| me I was stagnant and would never get prompted I would just
| tell them so what. I bring home $300k for my family and I
| have a good work life balance
|
| Even tech isn't immune to "move up or move out". Google's had
| plenty of layoffs these past few years and that's an easy way
| for the gravy train to end. Hope you got plenty of savings.
| spacemadness wrote:
| I don't think this world exists anymore. A lot of people I
| know are stressed out of their minds for the last few years
| by being way overworked and under constant threat of a
| layoff. I'm not talking about startups, I'm talking about
| Big Tech Corp. But I guess the mythical coasting engineer
| making a big tech salary that everyone talks about will
| never go out of style.
| theK wrote:
| So, fire the Product Managers?
| whstl wrote:
| Or at least hold them accountable for failing to get things
| done and communicating badly with developers. Which is
| something that I'm yet to see.
|
| In previous companies, as an engineering manager, I had to
| burn a huge amount of political capital to steer my team in
| the right direction, several times.
|
| My people (engineers) want to achieve their goals and create
| value, and the higher-ups want working software making money.
| I don't see why this has become so hard to achieve.
| lazide wrote:
| Because it's easier to create chaos for some people than it
| is to actually do what they are supposed to do.
| switch007 wrote:
| How do the evade accountability so often and so deeply?
| It's bizarre.
| whstl wrote:
| By shielding decision-makers/customers and engineers.
|
| To give an example of when I had to burn political
| capital:
|
| I had to "skip rank" a few times and go directly to CEOs.
| They are appreciative when you provide concrete facts,
| such as "I worked for two weeks on the redesign of this
| page that zero people use and I'm frankly tired of this
| bullshit".
| lazystar wrote:
| CEO's and VP's and customers appreciate this type of
| work, but YMMV. Speaking from experience, you'll be
| surrounded by more enemies in your day-to-day when the
| side effect of your customer obsession negatively impacts
| the KPI's that are used to stack rank your direct
| management chain against other teams and managers. it is
| quite kafkaesque to be treated as the black sheep after
| you save $10m a year for the org, then get a pay decrease
| + meets expectations 8 months later.
| whstl wrote:
| Your reply sounds too ironic and too real at the same
| time. :D
|
| But you're 100% right. You have to know when to use the
| nuclear button. And sometimes you can't press it, which
| means you take a backseat and watch the company burn
| money for no reason. This is the point where I start
| agreeing with _fat_santa's post [1].
|
| [1] https://news.ycombinator.com/user?id=_fat_santa
| lazide wrote:
| Usually the same way folks like Trump do it.
|
| DARVO, leverage, etc. etc.
| FireBeyond wrote:
| But that can go both ways. As a PM at a previous
| "engineering-led" company I was on more than one occasions
| given a prototype that Engineering had been working on for
| several months (with zero Product awareness, let alone
| input), and told "here, shoehorn a PRD and PMF around what
| we already built".
|
| In this case, the failure was my PM leadership.
|
| I said "I'm not sure about this, I think we need to do more
| research and figure things out", and got called out for
| "not being a passionate advocate and evangelist for my
| products".
|
| So I dug in, and with many iterations, and experiments with
| Engineering we came to something that did have some
| traction...
|
| "You need to strongly hold your opinion!" (Uhhh...) "Four
| months ago you weren't convinced about this, now you are!"
|
| It's all about the political capital, whomever you are.
| Sadly.
| esafak wrote:
| I can't tell if you know :)
| https://medium.com/illumination/google-once-fired-all-
| manage...
| icedchai wrote:
| Good PMs are worth their weight in gold and actually make
| engineers' jobs easier. Bad PMs create a useless
| "translation" layer that doesn't help anyone (except,
| perhaps, themselves.)
| abhisek wrote:
| How will you define a good PM? I have been looking for this
| definition for a while.
|
| In my startup experience, it seems to me the best PMs are
| the CTO and the early engineers who has near infinite
| business and user context.
| whstl wrote:
| Same experience, IME founders make amazing PMs, because
| they care about the company and they care about people
| not wasting their time.
|
| Not OP, but I can answer:
|
| They're ok with ideas coming from someone else, check the
| ego at the door and listen to both engineers and
| customers. They make engineers work less and produce more
| value. Most important, they don't have a "vision", they
| help organize the team so the team has a shared vision
| built by the team.
|
| EDIT: Also: They're not competing with the engineering
| manager or lead developer for some sort of leadership.
| They're talking with customers instead of asking sales to
| do it. They're working on the product aspect of tasks
| instead of offloading them to engineers.
| icedchai wrote:
| yes! The best PMs I've worked with have been founders.
| icedchai wrote:
| Communicates well, focuses on the people, problems and
| solutions, not tools and processes.
|
| Example: good PM will build a mock up of a UI, go over it
| in detail with engineers, then let them break up their
| own work. They are focused on the actual product. Bad PM
| will write 10 Jira tickets without any real context,
| assign them without discussion, then add 20 different
| tracking fields that nobody will use.
| NickC25 wrote:
| Was a PM before I went off and started my own non-tech
| company.
|
| My definition of a good PM is someone who can champion
| both customers/users and developers concurrently, while
| sticking to the company's value prop and competitive
| edge.
|
| In some cases, it's boiling down the needs of the
| customer into something achievable before sales gets in
| the way with over-promising and under-delivering. In
| other cases, it's telling the executives to stop wasting
| engineering's time with excessive meetings and scope-
| creep. It could be simply going and getting the engineers
| coffee. It could also be telling engineering to stop
| over-engineering the MVP and to simply get what needs to
| be done, done.
|
| In simple terms, someone who can go to bat for any facet
| of the company at any time externally or internally, in
| order to make sure right product is being built in a
| timely manner that aligns with both business needs and
| most importantly, customer needs.
| qznc wrote:
| Trying to make it more like a checklist:
|
| * Do the developers know what the customers want?
|
| * Do the customers have realistic expectations?
|
| If yes to both, then the PM in between is doing a good
| job. Bonus points if higher management is aware of that.
| NickC25 wrote:
| Exactly.
|
| A good PM should effectively get out in front of the
| sales team to make sure customers/users feel heard and
| understood, and also to communicate to the
| customers/users what is and isn't possible within a given
| period of time.
|
| A good PM should also know how to communicate a "no" to
| anyone in the business cycle from anyone else in the
| business cycle. Their job is effectively to be the
| firewall/filter from one team to another.
|
| No, customers don't want Feature XYZ even though
| engineering wants to build it No, engineering can't build
| Feature ABC even if a customer wants it No, sales cannot
| promise Feature 123 to customer, especially without
| checking with engineering first. No, executives can't
| force engineering to focus on the CMO's pet project, or
| force sales to hit numbers if the product sucks or isn't
| what the market wants
|
| And so on
| nicoburns wrote:
| > it seems to me the best PMs are the CTO and the early
| engineers who has near infinite business and user
| context.
|
| That's basically the role of the PM: to have all the
| business and user context and to use that to harmonise
| vision between the various "stakeholders" (parts of the
| business, users/clients, etc). But one doesn't have to be
| the CTO or an early engineer to have this
| context/skillset.
| whstl wrote:
| Bingo.
|
| It's exactly the same for designers.
|
| Good ones can shave days off complex tasks, and even help
| the code be more beautiful.
|
| Bad ones can turn a 5-min feature into a week's worth of
| work. For absolutely no gain, and possibly creating a few
| bugs along the way.
|
| Unfortunately the only way designers and PMs can learn this
| is by working together with engineers. Everyone needs to
| check the ego at the door. Which is borderline impossible
| with some personalities (from all sides).
| malfist wrote:
| My previous PM was ultra valuable. Put devs in contact with
| the customers, got out of the way of deciding what to
| build, and then sheltered the devs from the chaos of
| customers. He was also smart about what could be done and
| in what timeline, always working from the estimates
| engineers gave, working backwards and deciding what scope
| could be cut and where, who if another team could loan us
| people. He was the right balance of umbrella, partner and
| pass through. It was magnificent.
|
| My company, being more than a little bit toxic, he got
| transferred to a new manager who took an instant dislike to
| him and he was pulled off all his projects and then fired
| for not delivering anything. (bit of an exaggeration, he
| got put onto one of those "all responsibility, no
| authority" type projects where he was responsible for
| making sure everyone at the company stopped using the VPN,
| but he had no authority to force teams to build or migrate
| services to be available outside the VPN, and there were 2+
| decades of services to migrate, and he couldn't direct
| people to stop connecting to VPN if they needed something
| that was inside the VPN)
|
| The PM that came along to replace him described himself to
| all the engineers as "the next Elon", wouldn't let
| engineers talk to customers, personally decided what
| features to build with no input from the dev team, even
| when making technically difficult decisions. He asked for
| estimates from devs but never used them. Often giving us
| both half the time asked for, and half the engineers asked
| for to deliver a project. He never deflected chaos from
| customers, just added a translation layer that made it
| impossible to make the customers happy. Everything was an
| emergency, every feature necessary for an MVP. He'd
| constantly harass people for status updates, forget what
| they were working on and harass them again. He constantly
| asked for documents to be written for himself that he never
| bothered to open the links too.
|
| He was actively toxic, wrong and an impediment.
|
| He'd send out launch announcements to the org celebrating
| the projects that were completed and it was customary to
| list key people who delivered the project. He'd forget
| whole teams of people that worked on the project. One time
| he left me off of a project that I lead, got everyone in
| our sibling team that was helping out though. One person he
| never forgot to list as being a key person involved in the
| project was himself. Even in projects he had never heard of
| before having to write the launch announcement.
|
| That behavior was rewarded, for whatever reason. Although
| he finally left the company when one of the many rounds of
| "you must work from the same office as your manager"
| bullshit caught him up and he wouldn't relocate from canada
| to the US.
| dreamcompiler wrote:
| > That behavior was rewarded, for whatever reason.
|
| Sounds like you're describing someone with narcissistic
| personality disorder. Such people are often
| extraordinarily good at convincing the people above them
| they walk on water while shitting on everyone below them.
|
| My greatest wish is for managers to be trained to
| recognize people with NPD and other disorders and to
| remove them from the company quickly. They can cause
| tremendous damage to the organization in a very short
| time.
| kylereeve wrote:
| That's my experience with PMs (of all flavors of P;
| Product, Project, Program). A good one is invaluable and
| can really accelerate and unblock a project, especially
| one with a broad scope and many teams that depend on each
| other. A bad one is an active impediment and prevents
| actual work from getting done. I'd rather have no PM than
| a bad one, but a good PM is worth their weight in gold.
| whstl wrote:
| > I'd rather have no PM than a bad one, but a good PM is
| worth their weight in gold.
|
| Yep that sums it up.
|
| A mediocre one is already a huge problem, a bad one is
| able to tank projects.
|
| A mediocre boss or mediocre engineer can at least get out
| of the way.
| everdrive wrote:
| I left the government for corporate work, and we didn't have
| project managers as a specific role. Of course, people were
| managing projects, but it was nothing like it was in the
| government. In my short experience, project managers:
|
| - Have no understanding of the technology they're "building."
|
| - Don't understand who is responsible for what.
|
| - Would have NO idea if things were set up incorrectly.
|
| - Are solely working through a checklist of items and asking
| "is this done, or do you have dependencies?"
|
| - The checklist itself was just built by interviewing
| different stakeholders, but it's the PM who puts it together
| and of course the PM who doesn't really understand the
| detailed or high level view of the project.
|
| It's pretty maddening, and self-evidently stupid. I really
| cannot fathom why my company and other companies fail to
| understand what a waste of time and money this is. And worse,
| than the PMs are often leading to worse outcomes. Please keep
| this in mind anytime someone tells you that we need to "run
| government like a business," or suggests that businesses are
| wildly efficient whereas government is never efficient. If we
| had EVER had a useless PM like this back in government I
| would have forced them off the project as part of our
| criteria for success. In the corporate world, there's really
| no such option, because project success is always secondary
| to the businesses wants.
| lazystar wrote:
| product, not project :-)
| shermantanktop wrote:
| Same pathology, different symptoms. They are professional
| proxies.
| parliament32 wrote:
| I think liability is more important. In my anecdotal
| experience, PMs are eager to take credit for successes while
| passing blame for failures. If a PM "owns" a product and
| calls the shots, it should be crystal clear to leadership
| that they're accountable for outcomes.
| devrandoom wrote:
| Also bear in mind that you're slowly strolling on the road to
| burnout.
| whstl wrote:
| Definitely.
|
| It took me years to realize it but I became kind of a magnet
| for dysfunctional organizations. Apart from the current one
| and the previous YC startup, it was just bloated places that
| barely shipped anything.
| deadbabe wrote:
| So you're saying the only time you were satisfied with your
| work is when you took the role of a product manager who stepped
| in between the engineers and the rest of the company and had
| all their contributions filtered through your ego?
|
| Yea, that sounds pretty satisfying...
| phkahler wrote:
| >> Unsurprisingly, me and my team managed to deliver three
| projects that other teams tried and failed several times.
|
| Not sure how important delivery was to the company, but it's
| nice when your personal goals match those of the company.
| whstl wrote:
| No.
|
| Keep in mind that:
|
| - I didn't step in between engineers and the company. I am an
| engineer.
|
| - I didn't step in between my team and the decision makers.
| It wasn't me who "invented" the requirements, nor it was me
| who said the projects were complete.
|
| - It was the only time in the last few years where I could
| actually follow the advice in this article and ship things
| people need. Because I could TALK with people.
|
| - My entire team got salary increases all across the board.
|
| - Everyone has an ego, and everyone has a personality. But
| nobody in a team should get to put "more" of their
| personality over the others. We had brand guidelines and
| accessibility requirements, but other than that we decided
| things together.
| peterldowns wrote:
| Based. Nice work!
| codingbot3000 wrote:
| Out of curiosity: Why didn't you continue being product
| manager?
| sharkweek wrote:
| I read the comment and had the same question!
|
| I did this myself and ended up with a really satisfying 4ish
| years as a PM.
|
| That being said while I was perhaps fairly cynical about why
| PMs needed to exist before trying the role myself, after
| being in the role for an extended period of time, fully
| understand why the role exists now.
|
| Of course there can be bad PMs, a good/great one is super
| worth it.
| whstl wrote:
| We probably agree with each other!
|
| I'm not really cynical, and even before I wasn't!
|
| I just think it's a role that's way too critical, and a bad
| PM can do a lot of damage.
| whstl wrote:
| Good question.
|
| Mostly politics, I guess?
|
| The CTO was about to be fired, so I had nobody to fight for
| me. The Chief of Product didn't like the optics of a non-PM
| being more successful than a PM in delivering work.
|
| (EDIT: As I said, I delivered from start-to-finish 3 projects
| that other teams had considered "impossible", mostly because
| of bad specifications and overengineering, often caused by PM
| miscommunication. The PMs of other teams REALLY took the
| blame here: one was fired and sued by the company before I
| joined, and the other confessed to me he was "asked to
| leave")
|
| As for why I don't change careers, I'm an Engineering Manager
| and I made twice as much money than a senior PM at my
| previous organization.
|
| I still long for a position where I can be both technical,
| product and business minded. But I guess the only job where I
| can do that is as a founder.
| johnnyanmac wrote:
| >The Chief of Product didn't like the optics of a non-PM
| being more successful than a PM in delivering work.
|
| Its crabs all the way down:
| https://en.wikipedia.org/wiki/Crab_mentality
|
| That is one big reason I want to remain an IC for my
| career. There's slightly less ego to deal with and usually
| more passion among people compared to management. That
| passion is pretty much the main thing keeping me in this
| career.
| aprdm wrote:
| This really depends on the company. There are many companies
| where eng has way more weight than PM. And that eng aren't so
| divorced from customers. Even big tech.
| whstl wrote:
| I kinda keep hoping to get into one of those but so far only
| tiny startups are like this. Maybe I should go back to big
| tech.
| malthaus wrote:
| communication is probably the most important skillset in any
| organisation and 9 months of interim work is not sufficient
| enough for you to realize it.
|
| so this reads like any other salty engineer who thinks he's
| smarter than everyone in the org, business people are useless
| and if only he would yield decision power, all issues would be
| solved immediately.
|
| but guess what, it's usually not true and that mindset is
| usually not good to collaborate with either.
| whstl wrote:
| I guess actually delivering work according to specifications
| and making both stakeholders and customer's lives easier is
| never gonna be good enough for the peanut gallery.
|
| And it's not about having "decision power", whatever that
| means. I was there to collaborate, listen, document,
| communicate down and deliver. And I did. I got my raise, my
| team got raises, projects were completed, management was
| happy, customers are using it to this day.
|
| I wanted to be in control of my career and my output like the
| article describes. For nine months, I was.
|
| Everything else is bullshit rationalization.
| conrs wrote:
| I've had a very hard time with the Product Manager discipline.
| From the books and podcasts like Lenny's, it all makes perfect
| sense, but it seems like in practice it is as you described -
| they've inserted themselves in between and often don't
| represent either side well. It's lead me to develop product
| management skills myself, which are honestly incredibly useful
| in avoiding wasted effort. But it does make me wonder whether
| the dichotomy is worth it or if product management should be
| part of a senior engineer's skillset.
| yks wrote:
| any concise introduction into those skills you could
| recommend?
| whstl wrote:
| That makes me think.
|
| I never really worked with a PM that was good at preventing
| wasted effort. Or even mediocre at it. Most assumptions I saw
| them making were incorrect, unless it was a VERY SIMPLE
| product.
|
| To me this is something that engineering should be doing,
| just like splitting tasks and double-checking designs.
|
| Of course not every engineer can do it, but some of us have
| been doing it, negotiating deadlines and deliverables our
| whole careers. So I don't really understand why our industry
| insists on having us throw away those abilities.
| munksbeer wrote:
| Frankly, for me, the best value product managers can
| provide is being the buffer and/or unblocker. I want other
| team C to do task X, because it unblocks my team and
| others, but somehow I can't convince team C to do it. Well,
| that becomes the product managers job. They _should_ know
| the path to delivery and understand why this is important
| and negotiate with team C to drop other stuff to deliver X.
| And they can tell anyone above team C why this is
| happening. And I have worked with some product managers
| like that, but unfortunately they are rare, and most just
| get bullied by stronger willed (obstinate) tech teams. It
| isn't an easy job.
|
| I'm quite fortunate that at the moment I have a great
| relationship with all of our peer teams and we generally
| sort it out amongst ourselves. We don't have a product
| manager involved at all for the last few years.
| anon84873628 wrote:
| On the other hand, I've seen engineers make unilateral
| decisions that had completely unacceptable UX or ops
| impacts, that didn't align to the original design spec, and
| that they didn't think to tell anyone about until way down
| the road.
|
| Everyone needs a counterpart to "trust but verify".
|
| At my company, engineering managers are ultimately
| responsible for the deadlines and deliverables. It's an
| anti-pattern for PMs to also be the project managers - that
| is a bad combo and it should either be owned by the EMs or
| a dedicated role.
| phillipcarter wrote:
| As a PM I've always held the opinion that I'm genuinely not
| needed for a ton of work if the lead engineer is reasonably
| product-minded and understands current customers. Most
| existing customer pains are plainly evident and so long as
| it's not a wild amount of work, my job is to just give a
| thumbs up and move on.
|
| Where it gets nasty is the new opportunities. Assuming your
| system of patronage at a company is a good one, there's a lot
| of work in finding new opportunities in the first place and
| testing them out. And often the cat herding of developers who
| do some of this (great!) but want to just run wild without
| testing any of their assumptions (not so great!) and trying
| to balance the excitement and creative forces with whatever
| framing is needed to satisfy others in the company. That gets
| most complicated when various stakeholders hold opposing
| positions on "what we should be focused on", and if you don't
| have a PM absorbing that damage for you, you're just going to
| end up doing that all day instead of building software.
| mateo411 wrote:
| One of the functions Product Management is to be an
| intermediary between the business/sales and Engineering.
| Sometimes you might have issues working with Product
| Management, but you don't want to interact and build features
| for a bunch of stressed sales folks, so they can make their
| quota.
|
| It would be very hard for a company to build a sustainable
| business that way.
| PaulHoule wrote:
| Behind any web application _that works_ there is a gardener.
| rileymat2 wrote:
| > But they're not doing their actual job, which is to deliver the
| most value they can to their company.
|
| The article goes on to talk about legibility of value or
| perception of value which is a subtly different concept.
| agentultra wrote:
| > this fact is a trap for competent but unagentic engineers
|
| Is "unagentic engineer" a euphemism for human/not-AI?
|
| Unfortunately for companies whose engineers work this way,
| they're on a one-way trip to expensive cloud bills, data
| breaches, and frustrated customers.
|
| A good amount of that "never done," work is:
|
| - Patching security vulnerabilities
|
| - Fixing mistakes made due to lack of planning/testing
|
| - reducing costs due to lack of planning (ship it now, make it
| better later)
|
| - responding to customer feedback
|
| If the business you're working in doesn't see the value in the
| work you do then, when you can, find a new place to work. They'll
| sink their ship well enough on their own.
| jagged-chisel wrote:
| > Is "unagentic engineer" a euphemism for human/not-AI?
|
| I read this as engineers without agency - those who have little
| to no freedom to make any decisions on their projects.
| Spooky23 wrote:
| "Unagentic" is a terrible made up word to say that employees
| lack agency.
|
| Basically, people like when employees show initiative, operate
| independently and influence their surroundings independently.
| At least they like to say that.
|
| It's a common trap for engineers, many of whom like to burrow
| in and crank out stuff. You're toiling away slaying tickets and
| doing your thing, but become invisible or don't realize
| managements attention elsewhere.
| stuartjohnson12 wrote:
| It doesn't have to be that way, but that's certainly the
| default unless executives put in the work to make certain kinds
| of work legible.
|
| A great example that is less cynical is interface design - I
| greatly enjoy building user interfaces that are correct for
| lots of little interactivity details. It pains me to release an
| interface that breaks on tablets, or where the container
| doesn't have padding so the button awkwardly juts up against
| it.
|
| This kind of attention to design detail is not automatically
| rewarded _except_ for at companies and startups for whom that
| 's something that is valued, and design intuition is praised.
| I've had people come to me for work in the past specifically
| because they love that I pay extra attention to this stuff.
|
| That said, in many places this is not appreciated at all and
| none of this would be a value add.
| 2mol wrote:
| > Is "unagentic engineer" a euphemism for human/not-AI?
|
| No, it refers to people that are not "high agency", i.e. they
| might be smart and competent but need guidance on what to work
| on, as opposed to taking initiative themselves.
| frozencooler wrote:
| > Is "unagentic engineer" a euphemism for human/not-AI?
|
| Pretty sure it means someone who plods along in life, going
| with the flow, working but with no self-conceived roadmap of
| ambition, low extroversion, low desire to make decisions, etc
| TheOtherHobbes wrote:
| Of course you're right. But that's the point of the article.
|
| Companies, departments and teams operate on a spectrum from
| reality-centred to status-centred.
|
| In a reality-centred culture all the things you mentioned
| matter. Reality-centred management understands this, manages
| it, and rewards it.
|
| Reality-centred cultures are better at medium/long-term
| planning and at handling issues rationally.
|
| In a status-centred culture the most important product is
| status in the hierarchy. A "competent" engineer delivers status
| to superiors. That's their only job. The quality of the
| product, codebase, and the customer relationships is secondary
| - sometimes irrelevant.
|
| Status-centred cultures tend to be reactive, not innovative,
| and the orientation is emotional, not rational. Hierarchies are
| strict, communication is poor, and low-status people are
| treated badly. (Because how else is everyone else supposed to
| know they're low-status?)
|
| No one cares when things work smoothly, but if there's a
| problem that causes a loss of status, someone has to be blamed
| for it.
|
| Status cultures don't necessarily implode. If they have an
| effective monopoly, they can survive for decades.
|
| They're more likely to seem like huge players until suddenly
| one day they aren't any more, and everyone wonders what
| happened.
| agentultra wrote:
| Nice reply, all true.
|
| > Status cultures don't necessarily implode.
|
| True! And they're often not a great place for developers to
| work (unless you want to join in and become a manager and
| leave development behind).
| nickysielicki wrote:
| > Status cultures don't necessarily implode.
|
| Sometimes they do, though. And while it's spectacular to see
| it up close, it won't make you feel any better.
| pydry wrote:
| This whole article could be boiled down to "it doesnt matter what
| you do it only matters what executives perceive you as having
| done".
|
| The thing is, if in order to be successful in a big company you
| need to be a great salesperson and technically adept as well as
| organized then basically you're already a great entrepreneur.
| You're just a pet entrepreneur being kept on a leash.
|
| And yes, lots of companies want pet entrepreneurs. That way all
| they need to bring to the table is capital.
| eXpl0it3r wrote:
| Is this sentiment the reason why a lot of "engineers" will
| provide terrible quality in code / tests (lack thereof) /
| documentation / etc.?
|
| If all that matters that someone at the top sees it and is happy
| about it at this specific moment in time, why bother writing code
| that can last and doesn't leave behind an absolute unmaintainable
| ball of mud?
|
| We don't need gold plating and yet billions could be saved by
| having invested more than the bare minimum.
| spicyusername wrote:
| I don't think anyone purposely writes terrible code.
|
| You know the old standard: Never attribute to
| malice what is equally explained by incompetence
|
| But certainly stagnant conditions or burnout can prevent people
| from really putting in the extra effort. Why go the extra mile
| when it's consistently not rewarded, and in some cases
| punished?
|
| Also many software engineers are just not very good, frankly.
| It's extremely difficult to become an actuary without a strong
| mathematics background. It is very easy to become a software
| engineer with any kind of background, even if being a good one
| is just as difficult.
| beezlebroxxxxxx wrote:
| More and more you run into people who simply don't care about
| craft and quality.
|
| I can already hear the chorus of people that will scream "I'm
| not paid enough to care" or "it's just a job for some people",
| and those things are often true; but, nonetheless, people used
| to take much greater care in their craft even when they were
| paid less. There was a sense that, even if it was just a job,
| it should be done well. A certain sensibility of care and
| craftsmanship has faded away.
| pydry wrote:
| The chorus drones on about you're paid to deliver value and
| customers dont pay you for docs or tests or refactoring.
|
| If anything this is worse.
| ImPostingOnHN wrote:
| _> More and more you run into people who simply don 't care
| about craft and quality._
|
| Many talented and conscientious craftspeople, to pay the
| bills, work jobs which don't afford them full creative
| freedom, or even appreciate it.
|
| _> people used to take much greater care in their craft even
| when they were paid less_
|
| Did they? Maybe this is the golden tint cast when we
| reminisce about _" the good ol' days"_. I currently know some
| people who take much greater care in their craft, than some
| other people I used to know.
|
| The attitude of _" I'm not paid enough to do that"_ feels, to
| me, to be closely correlated with a company asking the
| employees to do more for/with the same or less, giving less
| freedom to choose what to do, micromanaging/policing how they
| do it, and all the while showing a decreasing amount of
| loyalty and humanity towards them. It'd be unreasonable to
| expect the employees to then suck it up, grin, and bear it --
| They are equal partners in an employment relationship in
| which one party is attempting to unilaterally change the
| status quo.
| TeMPOraL wrote:
| > _A certain sensibility of care and craftsmanship has faded
| away._
|
| It got replaced with _professionalism_ , as in "being a
| professional", which nowadays seems to mean prioritizing
| business needs above all.
|
| Caring about quality and craftsmanship is _not_ professional
| - it 's just not being economical with company time and
| money. It's better for the business for dev teams to tick
| features off a list as quickly as they can, because marketing
| can polish a turd and shove it down customers' throats _much_
| more cost-effectively than devs can make a half-decent piece
| of software that provides genuine value.
|
| No surprise more and more people don't care. They keep
| hearing everywhere - _including here_ - they should abandon
| childish pursuits, stop reinventing the wheel, writing too
| clever code, shaving yaks, going down rabbit holes, etc. -
| they should be _professional_. Well, that 's what we're
| getting now.
| bluGill wrote:
| > Caring about quality and craftsmanship is not
| professional - it's just not being economical with company
| time and money.
|
| I disagree, but only partially. The real question is when
| is the project done as in you would shred the source code
| and nobody would ever care. Some projects are done when
| they ship version one - you wouldn't fix any bugs or add
| new features, so code quality doesn't matter. Some projects
| are never done - someone will be touching this code in 50
| years (after you are dead), so quality matters.
|
| If the code is done then craftsmanship doesn't matter and
| putting effort into it is an unprofessional waste of time.
| However if the code will be maintained for years in the
| future then not putting effort into craftsmanship is
| unprofessional. You need to know where you are. Sometimes
| writing ugly code is a good use of your time, sometimes
| writing good clean code is well worth it.
|
| The important thing is to know where you really are. The
| wrong choice will hurt you.
| Glawen wrote:
| It sure makes children cry when we talk about quality.
| Thing is, who holds the truth with respect to quality and
| craftmanship? And how to identify the person which will
| improve quality ? Which path is best to follow ?
|
| I inherited a failed project, where each team member
| developped a repo. Nothing is unified, and it's a big
| architectural mess. Nothing really stands out, but god did
| I hear them crying about giving them time to build quality
| software.
| dakiol wrote:
| > people used to take much greater care in their craft even
| when they were paid less
|
| I think people used to care more when there were less BS
| involved in the software development process. Nowadays you
| get: scrum masters, product managers, product owners,
| engineering managers, daily standups, refinements, "getting
| things done", "shipping impact", "10x engineer", "red-carpet
| engineers from FAANG", and CEOs that want X or Y for
| yesterday. So, yeah, in that kind of environment, I couldn't
| care less about anything. I just do it for the money.
|
| All my craftsmanship goes into my personal projects.
| nspassov wrote:
| The level of respect that the typical manager or C-level has
| for the developers' efforts and time spent into keeping up-
| to-date with the industry has decreased, and now with the big
| promises of AI it will become even lower. Professionalism
| demands a certain baseline level of respect for one's effort
| and expertise.
| Capricorn2481 wrote:
| It's a lot simpler than you're making it: PMs don't want to
| pay for those things.
|
| If you tell them what tests are, they will say that's a waste
| of time and we need to ship features. If you tell them
| there's a huge security vulnerability that will take 15 hours
| to fix, they will get vaguely angry with you in a way that
| directs you to another task, to avoid explicitly saying
| "we're not working on security." They are very good at this
| malicious misdirection. Their goal is to not understand their
| own liability and make it your choice to work overtime for
| free.
|
| I'm dealing with this right now, a company with multiple data
| breaches who is trying to blame us, the new guys, for a
| breach that happened before we joined the project. They
| refuse to notify their customers because they "don't know how
| much data was leaked" (because they turned off the logs to
| save money). They have been so disgustingly negligent through
| this process I am considering leaving my job just to not deal
| with this one client.
|
| There are developers that don't care, but many that do. And
| they have stories similar to mine. They are told not to care
| by managers. I've never met a good PM. I'm sure they are out
| there, but I'm convinced this position is a magnet for the
| scummiest snake oil salesman on the planet.
| nijave wrote:
| Why be a professional brush removal specialist when you can
| be a professional Fire Fighter?
|
| There's software engineers and there's enterprise software
| developers and companies tend to want more of the latter than
| the former.
| ElevenLathe wrote:
| I agree that this attitude shift has taken place, but I would
| theorize (can't prove it, because history isn't an
| experimental science) that this is a symptom of the larger
| revolution in our global political economy in the last
| several decades.
|
| In a world of job-for-life employers and defined benefit
| employer pensions, it makes sense to optimize for craft to a
| greater extent (because you can build a reputation at your
| company as a maverick whatever-you-are and therefore get
| assigned to the most fun projects) and there is little
| incentive for resume padding. Also, if your management is
| from the older operations-focused school, they may have some
| genuine interest in the quality (or, at minimum, the
| efficiency) with which you do your work.
|
| With increased velocity of employer-hopping and financialized
| retirement savings (401ks instead of pensions), it now makes
| little sense to try and build a reputation in your company.
| Even if you stay for decades, your colleagues will rotate
| around you and its therefore almost impossible to build a
| reputation as a craftsman. Also, without a defined-benefit
| pension, you are increasingly incentivized to over-save for
| your retirement (even if you would only like to target a
| modest amount of retirement income, the only way to achieve
| this for sure is to have an enormous amount of savings).
| Finally, your management now has no interest in operations at
| all. Instead, they are all in on the "theory of the firm"
| which among other things is meant to justify a make-the-
| stock-go-up-no-matter-what strategy.
| atoav wrote:
| Everybody has their reasons to take on the role. If you make
| no-/low-budget films this is important to remember -- that
| camera person might want to try things out, that actor needs
| something for their reel, the sound guy might just want to make
| contacts in the industry, etc. If you manage to align your goal
| of making a film with theirs, everything works out.
|
| Now if you don't let engineers live out their passion, you made
| the choice to select for the ones who just do it for the money.
| That can be a legit choice, but comes with risks.
| Capricorn2481 wrote:
| Lots of PMs want to "go go go" fast and will not settle for
| anything less. We write tests and docs for the clients that let
| us. But the reaction from a lot of CFOs is offense that we
| would even suggest adding code that isn't features.
| al_borland wrote:
| I think that's part of it. I think the other half of the
| equation is the engineer isn't planning to work for any company
| long enough to need to deal with the results of what might
| happen in the future. If they have spent their whole career job
| hopping, they may have never learned the hard lessons from some
| decisions they've made. They think they did the right thing,
| but never saw the result, so they keep repeating the same
| mistakes.
|
| This is my general theory, as someone with nearly 20 years at
| the same company, who has seen many people come and go who
| repeat the same mistakes again and again. They often have a
| certain arrogance that comes from never having dealt with their
| own failings. Or it may be false bravado to hide their fear;
| I've seen that one too.
|
| I spent a good 12 years rolling with the punches and adopting
| every change that came my way, wondering why some others were
| resistant to change. Now I get it. While I think we do still
| need to grow and evolve, the change for the sake of change gets
| old. This is especially true when the change ignores the
| underlying root problems and bakes them into the new systems.
| If we aren't going to solve the hard problems, what's the
| point? I want to actually fix the stuff, not just add yet
| another coat of lipstick on the pig.
| Palomides wrote:
| "once software is done, you might be tempted to maintain it, but
| don't fall into that trap!" seems like a bleak thesis to me
| spicyusername wrote:
| They are implying that it is up to the decision makers to
| decide whether maintaining it is valuable.
|
| Never maintain it for "free".
| pphysch wrote:
| most generally useful software is maintained for free
| artyom wrote:
| Your work in a large tech company is done when your manager (or a
| manager two levels above) gets promoted.
|
| Then the cycle starts again.
| nyanpasu64 wrote:
| > What does it mean to get things done in large companies? Most
| importantly, it means finishing things.
|
| So that's why Google releases a new chat app every two years...
| wpietri wrote:
| I fundamentally object to any notion of done-ness that is solely
| focused on pleasing the few people who happen to be in positions
| of power.
|
| Are we all embedded in absurd structures of primate dominance?
| Sure. Primates gonna prime. But that is no more the root of
| what's going on than being able to mark something done in Jira,
| or getting a compiler to stop complaining. Proximate hurdles are
| not ultimate goals.
|
| Nobody gets to the end of a technical career and says, "Welp,
| that was 40 years well spent making a rotating series of bosses
| and grandbosses happy."
| virgilp wrote:
| I don't know. I'm 30 years into those 40 and, while I can list
| plenty of "achievements" ... that's not what got me promoted.
| There _is_ value in making bosses & grandbosses happy.
|
| I don't think it's good for you to be a cynic(because there's
| more to life than "promotion!"), but I think it's good to
| know/be well aware of the cynical viewpoint, because there's
| often a lot of truth in it.
| wpietri wrote:
| We agree: There is value in making the compiler happy.
| There's value in getting tasks done. There's value in
| pleasing bosses. They are necessary means to an end.
|
| However, my point is that one's analysis of the purpose can't
| stop with any of those. That focusing only on any one of
| those is ultimately shallow.
|
| And in particular, my critique of this article is that he's
| just shifting focus from one proximate goal to another. Is
| pleasing the bosses necessary? Under our current dominant
| theories of work, yes. Is it the point? No. Always and
| forever: no.
| virgilp wrote:
| Agreed - the better take is "getting promoted in large tech
| companies requires marketing" (and even that is only true
| for the senior roles, in the junior roles, being good at
| your trade is typically enough to get promoted to "less
| junior").
|
| But people have different ways of expressing this same
| idea, because it gets tiring to see/read it in only one
| form.... so I guess one has to get a bit provocative in
| order to draw attention :)
|
| (and to be fair, given how distasteful many programmers
| find the "marketing" part, it's somewhat useful to have
| many different ways to tell them that it's needed).
| johngossman wrote:
| Agreed, and as I tried to say in another comment, the real
| purpose is to help the company make money (and achieve its
| other goals). Ideally your management knows what those
| goals are and pleasing them is a proxy for that. Not always
| true, but in that case you have another problem, and its
| good to know that.
| yodsanklai wrote:
| > that was 40 years well spent making a rotating series of
| bosses and grandbosses happy
|
| Isn't that the definition of being employed? pleasing the
| persons who pay you to do what they ask?
| joncrocks wrote:
| The golden rule. He (or she) who has the gold makes the
| rules.
| unwind wrote:
| I had to look up "skip-level" since my large tech company lingo
| was lacking.
|
| It is defined as:
|
| _used to describe someone who works for a company at two levels
| higher than another person, or a meeting or relationship that
| involves an employee and a manager at two levels higher_
|
| by Cambridge's dictionary[1]. That makes it really complicated
| when the article talks about 1-3 skip levels, I'm not sure how to
| interpret that ... is it (my level + 1 + _n_ ) or (my level + 2 *
| _n_ )?
|
| Edit: the mathyness.
|
| [1]: https://dictionary.cambridge.org/dictionary/english/skip-
| lev...
| stepanhruda wrote:
| Skip level is your manager's manager, presumably 2 is one
| further step etc
| pitched wrote:
| You "skip" over your boss to talk directly to your boss's boss.
| If the hierarchy is very deep, you can skip even more levels
| lolinder wrote:
| This piece appears to be a quick summary of a much better and
| more thorough piece by the same author that was discussed
| extensively a few months back:
|
| _How I ship projects at big tech companies_ (1425 points, 381
| comments) https://news.ycombinator.com/item?id=42111031
| karmakaze wrote:
| The post is apt in getting things 'done'. I prefer to get things
| done. Of course I can't always just do what I consider important,
| so I balance them, I meet the requirements of 'done' without much
| more, and I spend more time than most getting important stuff
| done, sometimes things that take a longer time--I'll do the
| gardening so that it eventually gets done.
|
| People won't notice this extra effort for a long time, but from
| time to time, some problem/issue will arise and one of those
| things in my garden will be instrumental in solving or mitigating
| it. Over time, you get recognized as someone who gets things done
| well.
|
| Basically get stuff 'done' in 80% of your time and make your own
| 20% time. What's funny is that I've often been given explicit 20%
| time, but I've found that I can't schedule/manage that time
| explicitly like that, so I went back to taking approximately 20%
| time if/when I thought it's appropriate.
| davidmurdoch wrote:
| > they start delivering a stream of marginal improvements to a
| particular subsystem1. From their perspective, it feels like
| they're crushing it. After all, they're putting out work at their
| top speed: no downtime, no waiting on other teams. But they're
| not doing their actual job, which is to deliver the most value
| they can to their company.
|
| These people are often force multipliers, or "developer velocity
| engineers". They do work that doesn't deliver direct customer
| value, like updating old dependencies, swapping out deprecated
| APIs for new ones, always fixing warnings in CI pipelines and
| lint tools, etc. They free up others to deliver the "value" at
| higher speeds.
|
| But yes, they are the first to go when layoffs happen. But I
| think these types are absolutely necessary for an efficient org,
| and no matter how many times this type is fired for it, someone
| will end up falling into the same work again eventually - because
| this "no-value" work needs to get done.
| hoseja wrote:
| enshittification: perspective of the camp guard
| soVeryTired wrote:
| Simultaneously correct and devastating. Where I work, senior
| leadership don't have a technical background and so don't know
| when something is "good enough".
|
| The result is that most of our products are dogshit and are force
| fed to users within the company and to its clients.
| johngossman wrote:
| While I generally agree with this, I'd add one thing: to
| understand what your managers want, you really need to understand
| the business. At the highest level, how does your company make
| money, or at least think it's going to make money? What other
| things does the company value? It's surprising how often I find
| developers who don't know, either because they aren't curious,
| are too busy to learn, or (surprisingly common) think it's
| somebody else's job to make money...they're just doing what
| they're told. My advice is to actively try to meet upper
| managers, sales and support people, marketing people, and ideally
| customers. You almost always learn something you can apply. In
| big tech it is way too easy to be insulated from what the output
| of your job actually is. This applies even if you work on
| internal systems---somewhere those systems either add value or
| protect the company, and understanding that helps get your job
| done. And if it turns out your group doesn't add value, or you
| can't figure out how it does, then start looking at what groups
| do add value and whether you can move there. I did a few jobs
| that were not clearly aligned with the company needs and those
| always turned out to be a mistake. The valued work not only pays
| better is (usually) more satisfying.
| hnthrow90348765 wrote:
| I think it's fair to think of yourself as a carpenter. Devs
| talk a lot about this being a craft. You build to spec but
| point out problems when the spec is not possible or silly.
|
| It's the business's jobs to know how to explain the business
| and their needs. If they can't explain it, they probably don't
| understand it. If they do understand it but can't explain it,
| they probably need to work on their soft skills. You're also
| going to learn the business implicitly if they're explaining it
| well.
|
| You could be a developer that also knows the business, but
| where's the compensation for going the extra mile? Especially
| when the layoffs come around. Another perspective is if you
| have time to work the business side, what could you have been
| working on technically to improve things? So there's
| potentially an opportunity cost too unless everything is
| currently as optimal as it can be.
| johngossman wrote:
| It just happens that two of my good friends are carpenters.
| And they are highly aware of the business. They have to be in
| order to ensure they have work as construction and remodeling
| and other types of work ebb and flow. It's precisely when the
| layoffs come that it is valuable to understand the business.
| You are absolutely right that ideally the business people
| understand and explain the business, but are you really going
| to trust your livelihood so completely on that? Sometimes
| their job is to keep you working, fixing bugs, adding
| features, until they reach the point they can lay you all off
| (this pretty much happened to a bunch of my friends at an
| early job). Furthermore, just building to spec suffers from
| the Henry Ford problem of the customer asking for faster
| horses. Unless your business people understand the tech as
| well or better than you do, it is very likely you can improve
| the product more if you understand the business than if you
| just do what you're told. This does not have to be very time-
| consuming, and ideally your manager helps, but just paying a
| little attention, spending some time with people in other
| disciplines, can have huge payoffs.
| nitwit005 wrote:
| > to understand what your managers want, you really need to
| understand the business.
|
| That assumes your manager, and the managers above them,
| understand the business, and care. This is often not the case.
| cljacoby wrote:
| I have mixed feeling on this.
|
| Some parts of this are probably good advise, at least with
| respect to clocking titular promotions. No disagreement around
| visibility of delivered "big wins" being key.
|
| However, I feel like this article is subliminally pro-management,
| with the thesis statement essentially being just make your
| manager (and their manager) happy. But what happens when there's
| no clear direction from management on what the team's goals are?
| Or when priorities shift on a weekly, or even daily basis? It
| seems pretty hard to deliver anything meaningful, if by the time
| you're finished they've already moved on to the next shiny thing.
|
| Additionally, in my experience this "make your manager happy"
| approach goes hand-in-hand with a "yes boss" manager-subordinate
| relationship. Managers are empowered to flurry out executive
| dispatches on what, when, and how things ought to be done, and
| engineers are encouraged to follow orders. Results are normally
| not great.
| nickysielicki wrote:
| The solution to this is pretty simple: when you find yourself
| working for idiots, just quit. It'll suck for a little while,
| and then it will get better. Which is much better than spending
| months trying to make stupid and under-qualified people
| understand things that smarter people would understand
| intuitively.
| kylereeve wrote:
| On the flip side, when you have a manager who's genuinely on
| your side and wants to help you produce value (seems rare, I've
| been lucky enough to land one or two), "pleasing your manager"
| can accelerate career advancement and actually delivering
| working software you're proud of.
| WaitWaitWha wrote:
| In my experience, the two most important things to get "things
| done" is the other part of that sentence, the "things".
|
| Without well defined scope and deliverables, you cannot get
| "things done".
|
| Never-ending projects means the scope was not well defined, there
| is a constant scope creep, or the deliverables were not well
| defined. Or, worse there are good idea fairies in the
| organization.
|
| (https://www.urbandictionary.com/define.php?term=Good%20Idea%...)
| stego-tech wrote:
| While the OP's post is helpful, I'd argue it glosses over several
| other, far more critical points that other commenters have
| touched upon here:
|
| * Doing work on the _right team_ is more important than doing the
| _right work_
|
| * Good PMs and managers are more critical than good work
|
| * Good reporting structures are more important to visibility than
| a high-quality result
|
| * Doing work that aligns with leadership goals is infinitely more
| valuable than work that supports the functioning of the business
|
| * Always be ready to do the whole thing yourself, because
| politics in big tech will always disincentivize cooperation
| across silos.
| 2d8a875f-39a2-4 wrote:
| "Getting things done" means applying torque to one or more of the
| cogs in the corporate cash flow machine of which you are a part.
|
| Unfortunately that doesn't always correspond with "build a better
| product". If it doesn't but it is what you personally want to
| "get done" then you're going to need to circumvent the people
| whose job it is to keep you turning those cogs.
| cjs_ac wrote:
| > In large tech companies, this fact is a trap for competent but
| unagentic engineers. They see an infinite queue of tasks that
| they're capable of doing, and they start delivering a stream of
| marginal improvements to a particular subsystem. From their
| perspective, it feels like they're crushing it. After all,
| they're putting out work at their top speed: no downtime, no
| waiting on other teams. But they're not doing their actual job,
| which is to deliver the most value they can to their company.
| From the perspective of their manager and skip-level, they're not
| getting anything done.
|
| I strenuously disagree with this premise, not because I don't
| think this ever happens (it definitely does!), but because it's
| not the responsibility of an individual contributor to attempt to
| divine the organisation's priorities: that's a core management
| function.
|
| My employer buys forty hours of my time each week. It's my
| employer's responsibility to allocate tasks to me in order to
| best suit the organisation's needs and goals. Recently, I spent
| an entire week waiting for a specific person to review my code.
| It's my responsibility to (tactfully) inform my managers of this
| problem, but it's _not_ my responsibility to _solve_ this problem
| on my own initiative. The person might have a temporary backlog
| of tasks, they might be dealing with personal issues, they might
| have some workflow problems: in some of these cases, the root
| cause is something I _shouldn 't_ know about.
|
| This isn't to say that I'm just the monkey at the bottom of the
| tree being shat on by those further up: I do pass my (frequently
| misinformed) opinions and observations up to my managers, but
| it's up to them to decide whether and how to act upon them. They
| have more information - feedback from more people for a start -
| and consequently can make better decisions than me.
|
| If you feel that you have to fight your organisation to serve its
| needs, something has gone seriously wrong - possibly with you,
| but more likely with the organisation itself. Organisational
| pathologies are themselves Chesterton's fences - they exist for
| _some_ reason, even if the reason is stupid - and are
| consequently difficult to fix. Perhaps making things difficult
| for you makes things easier for everyone else. Perhaps fixing the
| issue will involve so much change to the way the organisation is
| managed that it 's actually better to leave things as they are.
| nickysielicki wrote:
| > because it's not the responsibility of an individual
| contributor to attempt to divine the organisation's priorities:
| that's a core management function
|
| The trope that ICs are incapable of understanding and balancing
| business interests against their wishlist of work items is just
| a cope that incompetent management chains tell themselves,
| because they need to believe that there's something that
| they're providing to the team that it won't get elsewhere. The
| fact of the matter is that understanding your project in depth
| does not cause myopia. Big tech is fat with managers who
| provide absolutely nothing to their teams, other than filling a
| management req which was conjured up out of thin air. The best
| teams have technical leadership and work relatively
| autonomously.
| ImPostingOnHN wrote:
| _> It 's my employer's responsibility to allocate tasks to me
| in order to best suit the organisation's needs and goals._
|
| I don't disagree that your personal employment relationship is
| like that, but keep in mind that you are describing only you
| here.
|
| Contrast with another example: It is _my_ employer 's
| responsibility to describe the organization's needs and goals,
| and to give me the freedom and leeway to figure out how to best
| accomplish them according to agreed-upon measures.
| rzz3 wrote:
| I don't want to be negative, but writing a mathematical proof and
| planting a tree are about the worst metaphors I could possibly
| think of. Building a house is probably a better example for
| something that could be infinitely maintained and improved.
|
| After the bad metaphors, all the article really says is "do
| visible work and finish it". This seems obvious.
| jere wrote:
| > The easiest way to do this is to deliver things that they
| already know about, such as projects that they've asked you to do
|
| I've struggled with this recently. I feel like advancement
| requires getting credit for the idea itself, otherwise you're
| just implementing other people's designs. But ideating (will
| actually good ideas) is pretty tough.
| panny wrote:
| >Declare victory and walk away: go and do something else
|
| That works really well if you're a contractor/job-hopper and can
| actually walk away. Otherwise, someone who doesn't understand the
| code will be asked to make modifications and you, the original
| author, will be called back in to rescue the thing when it has
| turned into a dilapidated mess.
|
| The problem the OP is having is not failing to please his boss,
| but working for a boss that isn't technical and has no idea what
| is happening. Those bosses are generally terrible for your career
| and if you have one, you should just quit.
| gwbas1c wrote:
| Yesterday I pointed out to the founder of the company that I work
| for, in the context of tech debt:
|
| "Well, since we moved the goalposts on that project, now we're
| out of 'credit card' tech debt and now in 'Adjustable Rate
| Mortgage' tech debt. Our goal should be to get to 'Fixed Rate
| Mortgage' debt."
|
| The problem is that too much tech debt can hold back feature
| development, or even materially impact hosting costs. In our
| case, we're a 10-year-old startup, and many parts of our stack
| were built in a way that makes them very hard to maintain, or on
| end-of-life technologies that are impractical to hire for. To be
| quite blunt: The tech debt got to a point where we spent more
| time on the debt than feature development.
|
| The problem with this article is that it glosses over the impact
| of tech debt, and how it needs to be handled. An umpteeth
| refactor for a 3% performance improvement is very different than
| a 3000x performance improvement that reigns in hosting costs.
| Backfilling unit tests needed to prevent regressions when
| building a new feature is also different than rewriting a major
| UI component because it depends on a UI toolkit that was end-of-
| life 7 years ago. All have a very different impact to the
| business and product.
| cubefox wrote:
| Yeah. I would phrase it like this:
|
| There is two things to avoid: "overengineering" and
| "underengineering". The first case has happened when it later
| turns out that the developer did put in too much work into a
| feature than was necessary in retrospect, in the second case
| that they did put in too little work.
|
| At the time of engineering it is usually not clear how much
| work would constitute over- or underengineering, as this
| depends on how much the feature gets to be used and evolved in
| the future.
|
| But usually it makes sense to "err on the side of
| overengineering". Because (limited) overengineering merely
| means some development effort was wasted, while
| underengineering can easily mean years of painful tech debt
| that is an order of magnitude or two more expensive than the
| wasted effort from overengineering.
|
| (It's similar to building a house. You usually want to make
| _doubly_ sure you really do everything right or more than
| right, because if there are any flaws that turn up later, this
| often gets very expensive to rectify, sometimes so expensive
| that it isn 't even worth fixing at all.)
| gwbas1c wrote:
| > But usually it makes sense to "err on the side of
| overengineering". Because (limited) overengineering merely
| means some development effort was wasted, while
| underengineering can easily mean years of painful tech debt
| that is an order of magnitude or two more expensive than the
| wasted effort from overengineering.
|
| In our case there was a lot of overengineering by novices, so
| a lot of the tech debt involves unwinding overengineering to
| make a simple change. Some of the "credit card" debt was
| simply using too many 3rd party libraries.
|
| > (It's similar to building a house. You usually want to make
| doubly sure you really do everything right or more than
| right, because if there are any flaws that turn up later,
| this often gets very expensive to rectify, sometimes so
| expensive that it isn't even worth fixing at all.)
|
| My fish tank guy told me how he once went to install in a new
| home, and the general contractor put a structural beam every
| 3-4 inches under the fish tank. It make it impossible to put
| in the filters. (In contrast, I only have one structural beam
| in the middle of my 180 gallon, through-the-wall, tank.)
| cubefox wrote:
| I would guess underengineering (quick and dirty solutions)
| leads to a lot more tech debt in expectation than
| overengineering.
| gwbas1c wrote:
| It's neither: Underengineering will lead to
| unmaintainable spaghetti code. Overengineering will also
| lead to unmaintainable code, but it's more like lasagna.
| Glawen wrote:
| Very nicely put
| bdangubic wrote:
| in my experience both are more like nachos :)
| cubefox wrote:
| I'd rather live in an overengineered house than in an
| underengineered one.
| highfrequency wrote:
| > How can you finish things in a world where you can keep
| improving systems indefinitely? It means getting them to a point
| where the decision-makers at the company are happy.
|
| Rational mindset for an employee, but the problem (for the
| company) is that upper management is usually unqualified to
| distinguish good vs. bad technical work. So under this advice,
| engineers do the minimal work to "deliver" lots of features in
| order to check off the OKR for upper management, but the
| engineering is done poorly. Upper management has no insight into
| the quality of the work, but over time the bugs and performance
| degradation pile up, while engineering managers get promoted and
| OKRs completed.
|
| The only real resolution is to push technical expertise as high
| up into the org as possible, so that even if engineers are only
| appeasing upper management, upper management will demand good
| quality work. Apple is the notable example of this org structure:
| there are no general managers except Tim Cook; everyone who
| reports to Cook is a technical expert.
| SanjayMehta wrote:
| I feel the author's telling us to play politics without using the
| word politics.
| pmarreck wrote:
| > If you want to get things done you can't be a gardener.
|
| Unless you are selling your own product or service that you
| yourself are working on (possibly indefinitely).
|
| Which is surely an enjoyable position, as long as you don't mind
| having no like-minded coworkers.
| al_borland wrote:
| While I understand the point being made, and have experienced
| this reality first hand, I still object to it.
|
| I have seen countless projects spun up, the company declares the
| problem solved (done), and then the team is disbanded to go work
| on new problems.
|
| What happens next? The product they built has issues, new
| features are needed, the rest of the company keeps evolving...
| all the while, there is no one to actually maintain that "done"
| project and it becomes technical debt.
|
| Eventually a new manager comes in, sees this mess of an old
| project and builds a new team to solve this problem all over
| again from scratch. They have to learn everything all over again
| and repeat a lot of the same mistakes of the first
| implementation, and the cycle continues.
|
| This doesn't seem like an effective way to run anything. If I can
| use an air conditioning metaphor, it is more efficient to set the
| house at a temp and keep it there, than to keep turning the AC
| off, letting the house heat up, and trying to bring it back down
| from 90.
|
| I had a little side project at work that upper management didn't
| care about, but was immensely useful to various support teams. At
| one point it had over 500 unique users internally, through word
| of mouth, as it was only designed for one team of about 50. The
| initial build took some effort, but once it was running it still
| needed care and feeding to keep it relevant. I managed it
| personally for over 10 years, and my priority was always
| responding to organizational change to keep it relevant and as a
| trusted source. The second it fell out of date, people would lose
| trust in it and start looking elsewhere, which is when tooling
| starts to fracture. It didn't take much time. Sometimes I'd go
| months without touching it. Most updates took 5 minutes, some
| more involved changes might take a day here or there. But that
| was important work to prevent needing to re-invent the wheel down
| the road once it became too painful to use due to lack of
| maintenance.
| antognini wrote:
| > If I can use an air conditioning metaphor, it is more
| efficient to set the house at a temp and keep it there, than to
| keep turning the AC off, letting the house heat up, and trying
| to bring it back down from 90.
|
| While I get what you're trying to say, if I can be a bit
| pedantic this is not more efficient thermodynamically. It is
| more efficient to let the house heat up and then bring its
| temperature back down.
| steele wrote:
| Shallow content slop red flags abound. Might as well keep moving
| the definition of done goalpost-- nothing is done until it
| provides utility that a customer exchanges money for. How about
| until there are enough customers are paying to make the system
| profitable? How about nothing is done until you hear it referred
| to as "legacy"?
| dogleash wrote:
| I've been trying to figure out what bugs me about this advice. I
| think it's narrowly tailored to people with zero technical
| leadership on their project, but also doesn't give them enough
| groundwork to really succeed either.
|
| Someone fresh enough to think anyone cares about the backlog
| deserves a manager that knows to meet them where they are, not
| expect the employee to meet them in the arena of management
| games. In practice, this often doesn't exist. Rather than the
| lowest rung of management bridging the gap into the tech, it's
| usually on seniors to "manage up" and shadow manage the team.
| Seniors good at this are more common, but time strapped with the
| rest of their dayjob.
|
| The target audience of this article needs a powerleveling guide
| to all the management skills of a senior, because they're in a
| vacuum with no seniors and their managers are not leaders. But
| instead it's the tiniest taste of the management world needed to
| orient someone towards being a better cog.
| RainyDayTmrw wrote:
| I strongly dislike "alignment" as a buzzword, and I think its
| existence is ipso facto an indication of our industry's
| dysfunction, but it nevertheless represents a legitimately
| important concept. You, your manager, and (to quote the article)
| some appropriate number of your skip-levels should ideally agree
| on what the most important next work items are. And to the extent
| that you don't, that's a problem for you as the individual
| contributor. Is this right? Is this fair? Of course not. Not in
| any moral sense, at least. But those are the cards we're dealt,
| and we play them as best as we can. The article is right that, on
| some level, we are paid to do what we are told to do. This is not
| a great outcome. Some of us are fortunate enough to have some
| sway in the opposite direction. This is the so-called "managing
| up" - another buzzword I strongly dislike, but again represents a
| legitimately important concept.
| nspassov wrote:
| I continue to be amazed how the respect for the work of IT
| professionals gets lower and lower. This article attempts to
| reduce software development down to "people pleasing". A
| prostitute is also paid to make the "investors" happy but even
| people who've never hired one agree that not every demand by the
| "investor" can be fulfilled and that the prostitute can set
| boundaries. Yet, when it comes to software development, people
| such as the author of this article claim that the only true
| definition of done can be derived solely from the desires and
| wants of the business people (some of who tend to change opinions
| depending on what time they'd woken up). Imagine if civil
| engineers operated in this way.
| d_burfoot wrote:
| This is one of a whole genre of HN-boosted blog posts that are
| basically saying to engineers: "you can't just write code, you
| actually have to do sales also". People who don't like sales
| think that they can go to a big company and just do engineering
| work. Nope, it doesn't work that way: you still have to promote
| your work, you still have to sell your work, you still have to
| talk to your customers, you still have to understand business,
| you still have to make deals, etc etc.
| t8sr wrote:
| Would you rather work with (hire for your startup) someone who:
|
| 1) Always pleased middle management in a large bureaucracy by
| moving metrics, then bailed out just before the project collapsed
|
| 2) Ignored the noise, fixed real problems and left the project
| better than they found it?
|
| After 20 years of tech career and 3 FAANGs, I know my answer.
| This article is decent enough advice for the first 5 years of
| your career, so you get some seniority and money.
|
| Once you have those two things, what they give you is the agency
| and the safety to walk away from bullshit.
|
| After that the game changes: it's about credibility and being
| sought after by your peers, who, at this point, should also hold
| senior IC positions at companies whose help you need, sit on
| standards committees, have maintainer rights in the Kernel, etc.
|
| Your long-term professional success will come from being an
| excellent technical peer, rather than pleasing random middle
| managers you will never work with again. Your personal job
| satisfaction will come from honing your craft and solving real
| problems for real customers, not from hitting some arbitrary
| business milestones. (Obviously those two things sometimes align,
| but if you're forced to make a choice.)
| madmountaingoat wrote:
| I hope this was more of a philosophical musing than career
| advice. I've not worked at every big company, but I have worked
| at a few. I agree that in the context of a big companies, "done"
| is a metric; and career success at that big company depends on
| moving the metrics those leaders track. But in my experience
| modern big companies also look at peer review and if you're
| always committing junk, those reviews are not going to be kind.
| So like everything, it's a balance. Please your boss by closing
| tickets. Please your peers by writing good code.
| ary wrote:
| > ... it means delivering the kind of things that are legible to
| the decision-makers at the company: i.e. visible to your manager,
| plus 1-3 skip levels, depending on your title. The easiest way to
| do this is to deliver things that they already know about, such
| as projects that they've asked you to do, or incidents that are
| serious enough that they're involved in them. It's possible to
| make other work legible to them as well. If your work produces or
| saves money, that will make it immediately legible, for instance
| (or you could just be really convincing). By default, work you do
| isn't legible: to the decision-makers, it's generic technical
| nonsense. They don't know whether it's crucial high-impact work
| or pointless code reshuffling, and will tend to assume the
| latter.
|
| This person understands the "business" side of the tech business.
| I couldn't agree more. Where many struggle is that they can't
| communicate legibly about the indirect benefits their work has
| for the business. The classic "refactoring" (which he mentions)
| is a great example.
|
| Refactoring code has a context dependent benefit to a business.
| When you're searching for product/market fit is has essentially
| no benefit, and then you're Microsoft and the code is deep within
| Windows and affects the performance of every Win32 app it can
| have extreme benefits. In the end it's all about how you relate
| your work to either making or saving the organization money, and
| doing so indirectly can be legible if you take the time to figure
| out how to best communicate it to the target audience (and how it
| can be conveyed to customers).
| bluefirebrand wrote:
| I couldn't agree more. It really is important for developers
| careers to learn at least a bit of business speak, and try to
| learn how to frame problems in ways that business people
| understand and care about
|
| At the end of the day, most decisions at a business come down
| to a cost versus benefit, assuming that the business is
| behaving more or less rationally
|
| Most business people in my experience also view the software
| itself as an expense, not an asset. I find that software devs
| do not understand that. "What do you mean the software is a
| cost center. This whole business sells software, how can we
| make money without software?"
|
| This isn't how many business types view it. The software
| doesn't matter to them at all. They would love if they could
| just sell nothing, so their costs would be zero and their
| profit margin would be infinite. That is the actual dream
|
| It's not rational but you gotta understand that sales doesn't
| sell on rational, they sell on vibes, good relationships,
| bribes, whatever they can get away with.
|
| Trying to be rational when selling puts you on too level of a
| playing field with other sellers, so they pursue other angles
| conductr wrote:
| That's all great but, how?
|
| First, recognize that if you're in the situation at the beginning
| of the article. A dev, banging out tasks that don't quite move
| the needle or seem important towards actually achieving any
| milestones. It's possible thats by design, your the random job
| site broom sweeper cleaning up at the end of the day
| (construction metaphor). It's also likely your
| management/leadership is failing you. They're failing by not
| prioritizing your work. You need to know what larger goals exist
| and are politically important to the organization and then what
| tasks you can do to accelerate that goal achievement. This is
| what your manager should be doing. If they're not, and you just
| work on a random list or todos, start pushing them for
| prioritization in every 1 on 1 and every checkin or whatever
| touchpoint you have. Make sure you understand what other higher
| level goals the prioritized work supports so you know where to
| fill in gaps and can be proactive and mention when you think
| something is off track (eg "hey boss, I'm working on X but it
| seems somewhat redundant to Y, can we merge these as a cohesive
| solution?")
|
| Once you get this part down, you start learning the decision
| makers in the company (or the highest ones you have some access
| to) and you start getting their opinions on what projects are
| higher priority or more crucial to the business. If you can build
| rapport with a few of these people and make sure you're
| contributions are known and appreciated towards things they find
| valuable and important, your career will start to progress
| fast(er) in almost every aspect.
|
| When these people eventually leave for a new gig, you want to be
| the ones they try to poach. If they stay and get promoted, you
| want to be the ones they think of for their new initiatives.
| Velorivox wrote:
| > The wealth of the mega corps does allow most goals to be
| accomplished, at great expense, with Just A Job workers, but
| people that have experienced being embedded with Really Care
| workers are going to be appalled at the relative effectiveness.
| --- John Carmack
|
| https://news.ycombinator.com/item?id=26170052
| pphysch wrote:
| tl;dr: "fuel your career with technical debt"
| csours wrote:
| I've noticed that people who are good at getting promoted are
| good at claiming success.
|
| Claiming success is not wrong per se, and getting promoted is not
| wrong per se, but sometimes the claimed success does not
| accurately represent value delivery.
|
| "Definition of Done" is a social exercise, not a technical one.
| nine_k wrote:
| > _If you want to get things done you can't be a gardener._
|
| I'd say that you can be a gardener, but you have to periodically
| demonstrate the harvest.
| uptownfunk wrote:
| Just ship or push to clarify reqs until you ship. Don't let
| anything else hold you back (oh let me ask my manager etc etc).
| Clarify the reqs, get sign off and ship. It's that simple.
| akomtu wrote:
| Sometimes I think that the big tech corporations are soul
| extraction factories that only incidentally vacuum money. This
| article says, in essense, that millions of very bright college
| grads in the US fly to big tech hoping to make the world a better
| place, but instead their skill of recognizing truth gets
| perverted by corporate politics, and the sum of their work simply
| manufactures and monetizes addiction.
| scrubs wrote:
| You want interesting? You want insight? Let's talk to the author
| here in 20 years, and review this question. In addition to
| operationally defining "get things done" and our own 20 years we
| can learn about,
|
| - why done means "some manager is happy" is just a silly
| definition leading to notions of things like customers, SQA/TQA
| etc..
|
| - impediments to getting things done, which must be solved first
|
| - on grit: sometimes you gotta hang tough and do the right thing
| when the people you're helping are morons and reject what you do
|
| - towards defining what "value" is
|
| etc.
___________________________________________________________________
(page generated 2025-05-06 23:01 UTC)