[HN Gopher] What Silicon Valley gets about engineers that tradit...
___________________________________________________________________
What Silicon Valley gets about engineers that traditional companies
do not
Author : gregdoesit
Score : 116 points
Date : 2021-01-10 18:01 UTC (4 hours ago)
(HTM) web link (blog.pragmaticengineer.com)
(TXT) w3m dump (blog.pragmaticengineer.com)
| mettamage wrote:
| What European companies are like this? I've been trying to apply
| for ages at US companies, for the reasons such as this. Reading
| HN for 6 years and being US-centered in general (thanks to tech)
| made me want to work like this. I've noticed that at European
| organizations people indeed try to pin me in a box, and then I
| can't thrive when I'm working there.
| flibble wrote:
| Flipdish (HQ in Ireland with a distributed tech team) is one.
|
| Full disclosure - I'm the technical co-founder.
| KaiserPro wrote:
| The article uses JIRA is a touchstone that seems to equate to no
| autonomy. I think this is wrong.
|
| I have worked at a good number of places, including a FAAMG.
|
| The freedom that was given to me directly correlates to company
| size & seniority.
|
| When I was younger, I didn't get much autonomy, why? because I
| was a naive arrogant prick. I would dream up solutions to
| problems that didn't exist. I would make existing problems worse
| by trying out new things.
|
| When a company gets larger, it will bump into problems, missed
| features, deadlines or massive bugs. New procedures will get be
| implemented to make sure that those don't happen again. Ticketing
| is a good thing, so long as its developer lead. It allows
| delegation of tasks, and simple tracking of state. Its an artform
| that should be taught.
|
| I was at a start up for two years that was bought out by a FAAMG.
| We were working on cutting edge computer vision research. We had
| a tight process, tracked with ticketing. We had complete
| autonomy.
|
| We were chucked into SV "culture" only to find that is somehow
| managed to make cutting edge research both more chaotic _and_
| boring. Ironically I have much less freedom than I did when I
| worked at a large financial newspaper.
| throwawaybbqed wrote:
| Can you please describe how you had a Jira/ticket system that
| you felt gave you autonomy? Very curious how it could be
| implemented in a research setting.
| lukashrb wrote:
| Are there any German companies that work like this?
| ju-st wrote:
| I'm working in a kind of internal startup of a big German
| company and we operate "SV-like" as described in the article.
| My job title is Software Developer but most of the time I'm
| convincing other developer teams to share code to speed up
| development, inventing simple solutions to complicated sounding
| wishes of product management, helping project management to
| prioritize low effort features and trying to find out what the
| customers really need.
|
| The only problem is that there is no leverage or scale because
| the software is coupled to physical goods, which means no big
| profits to pay above average salary and no career progression.
|
| And that is the point where I don't agree with the article. I
| don't see the correlation between salary and autonomy.
| itronitron wrote:
| Interesting, what the author describes has been the norm at every
| company I have worked at, and I've never worked for an SV
| company.
| astura wrote:
| Same.
| mindtricks wrote:
| From personal experience on the product side, if you want to be
| more involved with the business, I'd recommend you work on two
| things from this article. First, curiosity is an absolutely must
| have. Without it, you'll not be able to truly learn what a
| customer is looking for. Second, demonstrate you can "talk with
| another engineer" without manager facilitation. It's a signal of
| ownership that I guarantee people will notice.
| courtf wrote:
| I've done both of these my entire career and no one ever cared,
| mostly because it's not remarkable.
|
| Do you work somewhere that has a large management apparatus?
| These behaviors are sort of bare minimum expectation in smaller
| companies. It sounds like you perceived developers as a group
| to be mostly anti-social curmudgeons.
| Smaug123 wrote:
| A nontrivial part of this blog post is essentially saying
| "Silicon Valley practices leader-leader management more than most
| industries", in the sense of David Marquet's "Turn The Ship
| Around!". Points 1, 2, and 5 are precisely aspects of leader-
| leader management.
| dhenneberger wrote:
| SV-like companies try to hire the best of the best so it makes
| sense to that they would give them more greater autonomy and more
| responsibilities. These observations may not help a 'traditional'
| company become better.
| bdcravens wrote:
| In extremely small companies that are very technology driven (yet
| often pretty traditional in terms of the problem they are
| solving) you can find much of the same. (I work for such a
| company)
| opportune wrote:
| I have noticed that as SV companies get larger they tend to adopt
| the more "old school" approach. Not that it's a binary - it's a
| spectrum, and depending on management chain/how an org runs,
| people can have different experiences.
|
| I think it's caused by
|
| 1. When you have very deep management chains you start to have
| lots of people with opinions on what you should do, how you
| should do it, who you should do it with. Even if on average most
| of them aren't micromanagers, it only takes a few.
|
| 2. As you grow you start pulling in more people with experience
| outside of SV who bring in culture with them. Note that "SV" is
| also not monolithic here. Companies like Microsoft (ok,
| technically not SV) are farther to the "traditional" side of the
| spectrum.
|
| 3. "Horizontals"
| erikerikson wrote:
| Perhaps: as size increases, relationships don't scale and
| mechanisms of control and coordination become more shallow.
| Smaug123 wrote:
| Related: the "Moral Maze" of Robert Jackall fame, recently
| "popularised" (if Less Wrong can be considered "popular") by
| Zvi Mowshowitz (https://thezvi.wordpress.com/2020/05/23/mazes-
| sequence-summa...).
| plorkyeran wrote:
| The "SV style" runs into scaling problems. Engineers making
| product decisions requires that they have a solid grasp on
| everything the business cares about, which gets harder as the
| business gets bigger. Direct engineer -> engineer communication
| between teams is O(N^2) to organize things between N engineers.
|
| As you grow I think reducing engineer autonomy is unavoidable,
| and the goal is merely to stick to reducing it and not
| eliminating it.
| closeparen wrote:
| 4. Middle managers are going to do _something_ with their days.
| Once the growth frenzy stops and they 're longer occupied by
| procuring and filling headcount, they go the next thing they
| know, implementing systems of surveillance ("accountability")
| and control ("alignment").
| jgeada wrote:
| That is a brilliant take on middle management!
| beastcoast wrote:
| This is a big part of Amazon's success. Service oriented
| architecture gives teams enough autonomy to define their own
| processes. "You build it, you own it" often extends to products
| as well as services.
| hummel wrote:
| Money
| libraryofbabel wrote:
| I agree with a lot of this article and it reflects the culture at
| the kind of places I like to work.
|
| But - I'm curious what _costs_ folks have seen in making this
| switch to giving engineers more autonomy and expecting them to be
| problem solvers for the wider business rather than code-factory
| workers. My hunch is that it 's usually worth it - but what are
| the risks?
|
| It's easy to mention a couple of anecdotes about some engineer
| who made an improvement or feature that represented millions of
| dollars for the company bottom line. But what about people going
| down strange rabbit holes, engaging in resume-driven development
| or following the allure of cool tech that isn't really needed for
| the use case (e.g. "let's use Cassandra for this!"), Not Invented
| Here syndrome, premature optimization, spinning up unnecessary
| microservices because that's the way to get promoted, building a
| fancy internal system that internal stakeholders don't actually
| need or want, etc. It's really really hard to simultaneously see
| the business big picture and also be down in the technical
| details, and very easy for engineers to fall victim to the
| Dunning-Kruger effect and go off in the wrong direction. Perhaps
| the few people who are able to do this well are able to
| compensate for all the waste, but I don't think we can assume
| that it leads to good results for the business in every case.
| coderintherye wrote:
| What you noted of engineers going down rabbit holes of cool
| tech for cool tech sake is certainly an issue, which is why
| management must help keep in mind that the autonomy is given
| with a goal of "solve business problems." It requires a bit of
| careful management but it usually becomes clear over time who
| enjoys playing with new tech for the sake of new tech and who
| does it to try to find a solution to a problem. The former
| group can be put into a research team if the company is large
| enough otherwise they are likely not a good fit.
|
| As for risks, the biggest problem I've seen from this cultural
| change in a company is the disharmony it creates between the
| people who enjoy task-driven work and just working their 9-5
| vs. the people who enjoy creative problem solving. It usually
| works better to have that culture from the start and also why
| it is so hard to change a company's culture to this way of
| working because it disrupts a way being that almost everyone in
| the company is used to.
| [deleted]
| peter_d_sherman wrote:
| >""SV-like" companies think of software engineers as the people
| best suited to solve the problems that the organization has. They
| hire not only for technical skills but communication and problem-
| solving ability. Their thinking is a bit more like this:
|
| Software engineers are among the highest-paid people in our
| company.
|
| _This is because they can bring some of the highest leverage
| through coding and problem solving._
|
| We want to expose them to the business, so while they are doing
| their "normal" work, they can also find more impactful
| opportunities for the business."
| dilyevsky wrote:
| Is pay scale on this chart logarithmic?
| lawrenceyan wrote:
| Good eye.
| jedberg wrote:
| The best way to tell if a company values engineers is to ask
| which cost center they are in.
|
| Is it IT? Then they will treat you like a cog and consider you
| just a cost to the company. Is it Product? Then they will
| consider you valuable and critical to the company's success.
| mycall wrote:
| I'm lucky enough to make products for our company while being
| in IT, so it is a hybrid. With data driven decisions becoming
| more important to businesses these days, I see IT's
| transitional role as the cost side (vs. profit side) starting
| to change.
| qppo wrote:
| A question I like for non-tech businesses is: "do you see this
| as a software business or transitioning to become one?"
|
| Because these days every business has to be investing into
| software products, and the ones that don't recognize that the
| software is key to all their products are the ones that are
| dead folks walking. They're also great targets for SaaS
| consultant vultures.
| arexxbifs wrote:
| I dearly hope my cast iron skillet will never require a
| firmware upgrade.
| PascLeRasc wrote:
| Does anyone have any tips on getting out of this kind of
| company? I'm 2 years into my career but I'm one of those cog
| engineers working in IT and it's really draining my soul. I
| don't know how to talk about my job in interviews without
| giving off red flags.
| realjohng wrote:
| This is probably because Silicon valley companies have tech
| cofounders and first early hires are also engineers who become
| involved in important decision making beyond engineering, like
| product and even strategy. This creates a culture of empowering
| engineers.
|
| On the contrary, companies where tech is an afterthought-- well
| why would you empower your engineers to make business critical
| decisions if you're running a hospital or a sports team.
| quicklime wrote:
| I've worked at both SV and traditional companies, and I feel like
| this very closely matches my experience.
|
| One of the things I worry about is that even at companies that
| are doing "Agile transformations" and adopting methodologies like
| Scrum, _in practice_ have "Product Owners" who are there to give
| instructions via Jira tickets. Other roles like "Business
| Analysts" are there to ensure that lowly developers never have to
| worry about things like understanding the business themselves.
|
| So I get funny looks when I suggest that engineers should go talk
| to people in the business, and write design docs. Silicon Valley
| engineering practices can look very non-Agile to a lot people
| from traditional companies that are doing Agile.
| opportune wrote:
| Yes! The proliferation and role of "business people" in
| traditional companies is IMO their defining characteristic. It
| shows how much or how little a business trusts engineers (and
| also engineer's "status" within the company, e.g. are they
| respected and valued or treated as a disposable resource) to
| run the business as general problem solvers.
|
| The ironic thing about Agile is that it has a cottage industry
| of "scrum consultants", "scrum masters", project owners, etc.
| which advocate ostensibly for letting developers self-organize
| but which also has a vested interest for career and self-
| preservation reasons in inserting itself above software
| engineers in the decision making process.
| courtf wrote:
| I've long imagined a position just above the scrum masters:
| the scrum lord.
|
| I see this position as a critical component of any agile
| strategy that seeks to maximize scrum master productivity,
| while still allowing scrum masters all the autonomy they need
| for their day-to-day duties.
| klipt wrote:
| Why settle for scrum lord when you could be scrum king?
| Scrum emperor? One day even scrum Pope?
| optimiz3 wrote:
| Pope Scrootus the 1st
| courtf wrote:
| > scrum Pope
|
| his holiness will make his presence known in due time
| gnusty_gnurc wrote:
| Let's just call them all scrumbags
| jrott wrote:
| not sure you're going far enough there. Obviously we need a
| scrum king to guide our scrum lords as they help our scrum
| masters transform our organization.
| chris11 wrote:
| I definitely agree with you, but I don't think that's
| sufficient. I think at larger companies it would be helpful
| to spend a day or two every quarter having a scrum
| increment meeting. The SI would let scrum lords and scrum
| masters plan what experiments would occur during the next
| quarter.
| p_l wrote:
| Isn't that just the Scrum of Scrums meeting, only at
| higher level perhaps?
| loosetypes wrote:
| I appreciate your sense of humor
| surfingdino wrote:
| So true.
| walshemj wrote:
| Then they don't understand what RAD / SCRUM is for - and I
| would bet had crappy outcomes before the switch.
| celim307 wrote:
| We had a large disconnect between product and engineering. The
| directors solution was to have mandatory 8 hours of sprint
| ceremonies a week where we would review the definition of "bug"
| and "epic", every week. We also were required to sit in on all
| team meetings regardless if it was your team. We had two full
| time scrum masters for a team of six engineers.
|
| I suggested instead engineers get looped earlier into the
| process with stakeholders. The director said it was a bad idea
| as we couldn't possibly hope to understand the business side of
| things.
|
| Very glad I got out
| tolbish wrote:
| That would give developers too much power and make them non
| replaceable/interchangeable.
| consp wrote:
| They already aren't replaceable in that sense. It it
| impossible to open a can of developers and hope to get
| results straight away or hope nothing gets lost if someone
| leaves.
| p_l wrote:
| If you drop your expectations low enough, then yes, it's
| possible. It involves a steady churn state and the idea
| that "it's just how it is".
| Animats wrote:
| One could have said that about electricians a century ago. "Men
| and Volts", a history of the first 50 years of the General
| Electric Company, makes that clear.
| abalashov wrote:
| It all depends on who you're hiring and what you're building.
| Definitely applicable to startups and innovators coming up from
| the bottom.
|
| But, there are absolutely companies maintaining low-growth Clunky
| Java Accounting Application for Insurance Companies #574 for whom
| this approach is contraindicated. Those companies can hire
| relatively entry-level, average graduates, at commensurate
| salaries, and assign them highly structured JIRA tickets.
|
| Would they get better talent if their fronds tended more toward
| the SV model of compensation and autonomy described in the
| article? Absolutely. But in terms of marginal productivity or
| ROI, it's far from clear that it makes much of a difference to
| the financial performance of Cluky Java Accounting Application
| for Insurance Companies #574. That means massively overpaying for
| skills, or skill levels, that aren't really needed, or aren't
| needed enough to matter.
|
| No, it's not the kind of software development any of us want to
| do, and I think the audience for this post are for the most part
| in no danger of having to. But I think it's important to be
| honest about the fact that this sort of dimly-lit, cubicle-
| dwelling sweatshop software work _is_ a high percentage of
| software development occurring on the planet. For that type of
| company, following the "SV" philosophy would arguably constitute
| a dereliction of fiduciary duty.
|
| My view may be somewhat coloured by my exposure to medium to
| enterprise-sized companies in the telecom world, where a lot of
| the work is tedious, unimaginative and formulaic, using
| unexciting but established technology stacks, and so forth. But
| it still needs to be done, and there are companies who darken the
| skies with people to do it.
|
| Lastly, I incorporate by reference everything that has been said
| elsewhere in this thread about the nature of large organisations
| and the poor scalability of engineering-led company process. Most
| software work, by volume, doesn't consist of skunkworks
| innovation or the development of something new. Most software
| work is incremental, in many cases strictly maintenance mode, and
| caters to many stakeholders. Large organisations and big capital
| serve an entirely different purpose that is realised at points
| further along the technology and product lifecycle. In this
| comment, I merely chose to focus on (1) the problems of
| empowering "average" talent this way and (2) the poor prospectus
| for doing so.
| chmaynard wrote:
| I have worked in this field since 1980. The first time I was
| given the title "Software Engineer" was at Apple in 2001. Was I
| really a trained, licensed engineer in the traditional sense? Of
| course not. But it sure made me feel flattered and empowered.
| Silicon Valley HR execs use strategies like this to manipulate
| their employees, particularly the youngest ones.
| shrimp_emoji wrote:
| C'mon, you're _too cool_ for higher pay and worker 's rights.
| :D
| esoterica wrote:
| Why do people keep pretending like Silicon Valley engineers
| aren't one of the single highest paid demographics in the
| entire country?
| mlthoughts2018 wrote:
| Pay is nowhere remotely close to being proportional to
| impact on revenue though. Many engineers are much more
| offended by unmeritocratic pay than by absolute value of
| pay being low - hence why you can convince amazing
| engineers to work for peanuts at start-ups.
|
| I want the greatest share of the returns of my own labor I
| can get. If that results in very high salary, great, it's
| earned. If I take a risk at a place where that translates
| to much lower salary, that's fine too - as long as it's
| very objectively meritocratic.
|
| If I am making $200k per year as a top, top performer,
| while my employer is paying far more mediocre performers
| $175k (perhaps based of geolocation), or where both of us
| are bringing in ~ millions of revenue, that's super
| unacceptable.
|
| As time goes on, the surplus of my labor productivity that
| a big corporate employer can capture beyond my total
| compensation should be decreasing heavily - and expert
| software labor is one class that has the negotiation power
| to actually push that issue.
|
| So I'd flip your question on its head. Why do we pretend
| that rent-seeking executives deserve the surplus revenue
| generated by rare talented engineers? Why (with complete
| sincerity) aren't many, many, many more software engineers
| paid on the order of what Hollywood actors are making,
| while executive salaries simply have to come way, way down
| in these lines of business?
| gamblor956 wrote:
| Hollywood executives get paid more than most actors. Only
| the absolute elite talent are making above scale let
| alone more than what the executives are making, and their
| managers (aka recruiters) are negotiating that for them.
| dilyevsky wrote:
| Depending on your budget the min SAG rate can be anywhere
| from ~100-1000/day so many sw engineers in fact make much
| more than most actors
| courtf wrote:
| Exactly. The funny thing is the same people making the
| counter to your argument no doubt don't bat an eye at 8
| figure annual salaries for the best sports players. The
| argument is the same in either case.
| walshemj wrote:
| Compared to other professions? maybe SV is just treating
| "Engineers" more like other older professions and has less
| of the class distinctions you see in the UK for example.
| glitchc wrote:
| Initially this was true, certainly SV would use higher
| salaries to draw developers and engineers to the valley.
| But cost of living has exploded since then. A modern
| developer living in SV does not command a higher standard
| of living as food and housing costs are significantly
| higher than most of the rest of the country. A similar
| trend plays out on the east coast so it's not just SV.
|
| It's balanced by the CoL adjustment. In short, SV engineers
| are not better off, and haven't been for the past decade.
| This is apparent by the observed exodus in the light of
| Covid forcing a shift to primarily remote work. Engineers
| are trying to reclaim their wage advantage by moving to
| cheaper locations, and companies are fighting back by
| reducing compensation accordingly.
| markalexander wrote:
| Sort of. Often a big chunk of your CoL is going into a
| massively appreciating asset. People always seem to
| ignore this when talking about the top n most expensive
| cities in the world. You can literally sell your
| apartment and go live in a mansion most other places on
| the planet when you feel like it.
| codesnik wrote:
| hm. do many people in silicon valley buy their apartment
| or house there these days? Is it even accessible?
| markalexander wrote:
| People in general or people in tech? Well what's the
| typical mortgage multiple, 6 or 7 times salary? So for
| the latter, it seems pretty attainable to get an
| apartment at the lower end of the market to start out on.
| Correct me if I'm wrong, though.
| MattGaiser wrote:
| Software developers enjoy great pay, great perks, and have
| plenty of job opportunities if anyone abuses them, in North
| America at least.
| draw_down wrote:
| I think the first two are complicated by the eventual (even if
| slow) inclusion of layers of process, sign offs, and approvals
| required for a given piece of functionality to go live.
|
| You start off with engineers having autonomy then something bad
| happens one day, so you introduce an approval process to make
| sure that doesn't happen again. Then one day someone notices
| visual/UX inconsistencies between products so a process is
| introduced to ensure consistency. Then someone notices the tone
| of the copy is not what they think it should be so it is decreed
| that all copy should go through the writing team. Etc. Eventually
| shipping becomes as much about fighting through these thickets of
| bureaucracy as about improving things for users or, you know,
| writing code.
|
| You end up with a situation where someone who has never heard of
| you or your stupid project asking you fundamental questions about
| its existence which have already been answered at the outset of
| the project... but why should they care? You answer to them.
| Their job is not to help you make users' lives better. Their job
| is to stop peons like you from screwing up.
| mlinksva wrote:
| These things (1. autonomy for software engineers; 2. curious
| problem solvers, not mindless resources; 3. internal data, code,
| and documentation transparency; 4. exposure to the business and
| to business metrics; 5. engineer-to-engineer comms over triangle-
| communication; 6. investing in a less frustrating developer
| experience; 7. higher leverage --> higher {autonomy, pay}; the
| "biggest" is a repeat of 2) seem like plausible differences
| between "SV" and "traditional" companies.
|
| I wonder if there's data (survey? perhaps correlated with
| compensation?) to back up and establish magnitude and
| trend/diffusion or refute any or all?
|
| Also would be interesting to look at those characteristics for
| non-employer open source projects and government. There would
| surely be lots of variation across projects and
| departments/governments, as there would be across companies,
| though I'd guess for non-employer open source 1, 2, 3, 5 would be
| very high, 4, 6, 7 unclear or lacking, and for government
| possibly even lower than traditional companies across the board?
| Just speculating, again, curious about data, or more speculation.
| :)
___________________________________________________________________
(page generated 2021-01-10 23:00 UTC)