Earlier quoted context omitted.
Why settle for scrum lord when you could be scrum king? Scrum emperor? One day even scrum Pope?
God-Emperor of Scrum. The code must flow.
In the grim darkness of the future, there is only Scrum!
What Silicon Valley gets about engineers that traditional companies do not
261–270 of 339 posts
Re: What Silicon Valley gets about engineers that traditional companies do not
#262Earlier quoted context omitted.
In many companies, the 'product' department exists to protect the owners from the leverage developers would have if they had access to the business context.
Thats an interesting take. But wouldn't product end up having the same leverage? Or is the goal to divide product and engineering work so that no one person has the complete view of the business?
The product department (of a sizeable software company) generally lacks the technical ability to actually construct a competing product with the business knowledge they have.
They understand the business' financials and interface directly with customers, but they don't understand how the product works. Any features or issues end up being proxied through these nontechnical resources.
This is why you will hear devs complain loudly about the parasitic product department (or equivalent layer above them) that always just seem to be
> getting in the way
However, because developers often don't actually want to interface with customers and just want to build cool tech, and charming socialites are very glad to act as that interface, this usually works. As a secondary effect they (non-intentionally) obfuscate the inner workings of the company from the devs who would otherwise (as the GP points out) realise how much they are being (ab)used and turn the screws on the upper management.
Re: What Silicon Valley gets about engineers that traditional companies do not
#263Earlier quoted context omitted.
Superstar athletes/actors have much higher roi - nobody is buying your product bc of star c++ developer you hired. Besides there are only like 50 or superstar players/actors at any given moment. Pretty sure you can find this many engineers who made millions
I guess we need data to back this up - I’m not buying it without more data. Even the top, top valued sports franchises only have estimated market caps in the range of $5 billion. In other words, for small cap companies, yes, the ROI of athletes to their franchises is relatively higher than engineers to their companies. But for most of the SP500 this is not true, and there are lots of software-heavy companies with muc…
This seems like it's incorrectly estimating orders of magnitude.
Some actual numbers:
In 2019, Google's gross revenue was ~$162b. ~$76b went to "costs of revenue", ~$26b went to R&D, and ~$11b to stock-based compensation. It's unclear what % of costs of revenue is attributable to "salaries of software engineers", though. Let's approach it another way. Google employs 30k+ SWEs, the vast majority of which are in the US. The median outlay probably falls somewhere in the L4 - L5 range, though there's a fat tail at the top. If we want to be conservative, we can just ignore the tail and say ~300k/dev. $300k * 30k = $9b (this is probably low).
Google's net income in 2019 was $34b. So you could multiply SWE comp at Google by not-quite-5 and zero out Google's net income.
What do top pro athletes make? Wikipedia says the top pro athletes earn mid-high eight-figures/year.
There's some headroom to pay engineers more, but it's definitely not "top pro athlete" more. Engineers can and do make that kind of money by founding & growing successful startups, not by working for FAANG (possibly with a very small # of exceptions at the top).
Re: What Silicon Valley gets about engineers that traditional companies do not
#264Earlier quoted context omitted.
This is true, but I've also seen "product leaders" in organizations not articulate a clear vision, requiring the engineering staff to do a Socratic-like process to pull tangible requirements out of said "product leader". It's a tedious process so I'm not surprised engineers throw their hands up and just have a PM do it. I do think SV puts more trust in their engineering teams to produce polished software, whereas oth…
Completely agree, same thing has led to massive growth of product mangers, product owners, and various other titles that do similar things. The devs still tend to have to ask a lot of questions to get anywhere useful but in these situations the P* roles at least give them some traction to work from and get movement.
Frankly, since I've moved to the Netherlands, every project I worked in seemed to exist exclusively to justify a comfy, lazy job for incompetent Dutch POs, scrum masters,"customer journey experts", copywriters, designers. There is way too much money in this country and an incredible amount of bullshit jobs.
Re: What Silicon Valley gets about engineers that traditional companies do not
#265Earlier quoted context omitted.
But it's sold by a company with a website, and if it's in-house, (probably quite a big 'if') its developers probably don't want to be lumped in with its phone line, office PC etc. sysadmins (and I'm sure it's mutual). I think that's the point. Cookware's just a further-from-tech example of it.
I'd be perfectly happy being lumped in with the Sys Admins. They are, in most companies, the most misunderstood role. There's an expression that basically says "When things are going great, everyone wonders what sysadmin does. When things are going poorly, everyone wonders what sysdamin does". A good sysadmin team is amazing and, in many cases, vital to a successful business. I think the only other role that gets ign…
I wasn't saying their useless at all, I said the feeling's probably mutual, is just a different role, so if they're lumped together then as you say, at least one has been misunderstood.
Re: What Silicon Valley gets about engineers that traditional companies do not
#266Earlier quoted context omitted.
That's interesting... I think. Could you give an example (as contrived as you wish) to illustrate this point?
My guess is that if developers understood the business, they would understand how simplistic a lot of the business models are, and how much of the profit is derived directly from their skilled labor and yet how much of the profit goes directly towards someone else, and developers would suddenly realize they have leverage because they are essentially the profit model.
As long as the engineers are replaceable by other engineers, that’s not really leverage. The leverage is the capital to pay the engineers’ salaries and the risk tolerance for the business model possibly failing.
Re: What Silicon Valley gets about engineers that traditional companies do not
#267There is a second kind of leverage that startups in particular can get out of their developers: expecting them to live for the job.
The choice between a company where (a) you work on assigned tickets, but standard business hours and weekends off and X days of guaranteed holiday per year versus (b) a high autonomy, high pay but if the company needs you to pull a 90-hour week then you do it without asking - it's a tradeoff. Whether you get to write your own JIRA tickets is just one of many dimensions here.
One of those two options is not compatible, for example, with having responsibilities outside of work such as childcare.
Re: What Silicon Valley gets about engineers that traditional companies do not
#268I'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…
As a person who was there for the early days of Agile, I just want to say it's sad that's what Agile has become. You're right, of course. But that's not what was meant. Somehow "Individual and interactions over processes and tools" became "individuals, please stop interacting and conform to these processes and tools".
It gets worse. If you're caught in a power grab/political game as a developer, some manager consciously use this to slow you down in comparison to their favorite developer.
I was a developer brought into a team along with codebase. They would allow their own devs to go full SV-style, free. But when it comes to me; "please check with PO, create a jira subtask for this"
Re: What Silicon Valley gets about engineers that traditional companies do not
#269Earlier quoted context omitted.
Completely agree, see it at companies like Google turning more and more into deep management chains. Some of the good remains (code & documentation transparency, engineer to engineer communication), but much off the decision making is shifting up the chain Do you mind expanding on what you mean by "Horizontals" here?
>Some of the good remains (code & documentation transparency) Not after the infamous need-to-know memo. Team docs visibility defaulted to "only to people I explicitly share with" for almost a year now. It's only a question of time until code branches follow suit.
> Not after the infamous need-to-know memo.
I couldn't find that memo, could you please link to a copy?
Re: What Silicon Valley gets about engineers that traditional companies do not
#270I'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…
I think it also depends a lot on the type of dev and if they want to take responsibility. I have experienced many devs that just didn’t care about the business and design side of things. “Leave me alone and go talk to the product owner”, was something I gotten quite often. But, to be fair I often also got “We want to be more involved in decision making”.
If you set up the responsibility, power & accountability right. Then the developer will have to care and take responsibility. Otherwise, their deliverable is wrong, and they're out. As simple as that.