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…
I think the key is whether you consider an engineer a business person. That is what links most of the things in the article: a business person needs to know certain business things to be effective, and so if you're considered a business person you get told things like what the competive landscape is, what the budget is, and so on. For me, the engineer is actually the only person who can do those business functions pr…
What Silicon Valley gets about engineers that traditional companies do not
211–220 of 339 posts
Re: What Silicon Valley gets about engineers that traditional companies do not
#212Earlier quoted context omitted.
> traditional companies that are doing Agile. Aka "Wagile". "We have a standup every morning, where you're required to report on how many of your assigned Jira tickets you completed yesterday and get berated for any incomplete ones no matter the cause! No excuses! We've committed to these deadlines and budgets, that you know nothing about having not been consulted on anything."
That’s just the tip of the ice berg... I call it the tyranny of project managers. When I worked for a large multinational in SF, 100M+ users we operated very much in the “SV” style the article describes. I got to see how our satellite offices in other parts of the world operate; EVERYTHING was in calendar, work was tracked in 15 minute intervals, meeting about meetings, and follow up meetings after the meeting, and a…
FAQ
Q: What are you working on?
A: Look at the issue tracker
Q: Are you working on X?
A: Look at the issue tracker
Q: Are you still working on X?
A: Look at the issue tracker
Q: Is X finished?
A: Look at the issue tracker
Q: Did QA look at X?
A: Look at the issue trackerRe: What Silicon Valley gets about engineers that traditional companies do not
#213Earlier quoted context omitted.
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.
Note that this is the case in most industries, not just software. And that's why the "patrons" "bosses" "chiefs" whatever they are named over time always fought to keep their employees silenced, non-organized... Maybe now is the time to consider cooperatives and getting rid of all or part of the hierarchies (some cooperatives work well with simpler hierarchies). They want disruption, we cut the ties.
The article and the conversation here suggests that the Silicon Valley model is a good way to give developers more leverage and also to get more out of them.
That model is generally far from cooperatives and still has plenty of hierarchy.
Getting 'organised' and into cooperatives might still work, I don't know? I'm just saying that the available evidence here points to a very different direction.
(Cooperatives have been tried, and there are some software companies inside and outside of Silicon Valley that work along similar principles. But by-and-large they aren't the companies eating the world.)
Matt Levine's Money Stuff often harps on the theme of investment banks being run like workers' cooperatives in practice.
Re: What Silicon Valley gets about engineers that traditional companies do not
#214I once had a rather prestigious developer position in a Silicon Valley company. The "approachability" was a double edged sword. One problem I fought was that a lot of people expected handholding from me, or wanted me in their meeting to "feel important." There really is value to having your manager act as a gatekeeper. Another problem I had was that less ambitious people in other departments (support, qa,) would thro…
> would throw their work over the wall to me For myself as QA, I would see the throwing the opposite direction. Devs started having me close out unit tests, giving incomplete work hoping I find their issues, gathering requirements to know what to test etc.
Re: What Silicon Valley gets about engineers that traditional companies do not
#215Earlier quoted context omitted.
When I was managing engineers, I would insist that the engineer talk 1:1 to the engineer on the client (or customer) side when doing fixes or feature enhancements that happened to be requested from outside the company. This always caused consternation among scrummasters and product managers, and there always had to be a discussion about it. But it sped things up tremendously, because the engineer could do things like…
There’s some value in capturing these conversations for the record. If eg the engineer engaged in these conversations decided to leave, it would preserve the record for the person replacing them. I do agree that if this process is used to score political points though, then it loses all value. Maybe a compromise is to capture the summary of these conversations somewhere. But honestly if an org has become this politic…
Re: What Silicon Valley gets about engineers that traditional companies do not
#216Earlier quoted context omitted.
That’s just the tip of the ice berg... I call it the tyranny of project managers. When I worked for a large multinational in SF, 100M+ users we operated very much in the “SV” style the article describes. I got to see how our satellite offices in other parts of the world operate; EVERYTHING was in calendar, work was tracked in 15 minute intervals, meeting about meetings, and follow up meetings after the meeting, and a…
How about “people over process”? Yet we are slaves to Agile Scrum process and procedure. Double talk.
Plus, most implementations of Scrum are bullshit. Scrum does not recognize the role of a "project manager". There's the product owner, the scrum master and the development team. That's all.
The scrum master only exists to guarantee the process is followed. The scrum master is just a scrum evangelist, not a real leader.
Re: What Silicon Valley gets about engineers that traditional companies do not
#217Earlier quoted context omitted.
Jira, for all it's warts, is a massively configurable piece of software that can be deployed/used in a hugely broad variety of ways. I once worked at a place where Jira was without doubt a positive force within the company. There was an Altassian-trained Jira specialist working there who collaborated setting up each Jira project, and provided ongoing advice/assistanece to users (both PMs and devs). This was in a comp…
Yes, Jira is very configurable. But whether you'll be allowed to configure it is an open question. I worked on a team that had a very finely tuned Jira workflow. Then one day we discovered that all our customizations had been eliminated. The company had decided that it wanted all configurations to be based on a company standard, and no deviations would be allowed. We weren't even warned ahead of time.
Re: What Silicon Valley gets about engineers that traditional companies do not
#218Earlier quoted context omitted.
Note that this is the case in most industries, not just software. And that's why the "patrons" "bosses" "chiefs" whatever they are named over time always fought to keep their employees silenced, non-organized... Maybe now is the time to consider cooperatives and getting rid of all or part of the hierarchies (some cooperatives work well with simpler hierarchies). They want disruption, we cut the ties.
Hmm, that is a weird conclusion to draw from the observations. The article and the conversation here suggests that the Silicon Valley model is a good way to give developers more leverage and also to get more out of them. That model is generally far from cooperatives and still has plenty of hierarchy. Getting 'organised' and into cooperatives might still work, I don't know? I'm just saying that the available evidence…
I don't think a company's purpose is necessary to eat the world but that's going into opinions so I will refrain.
Re: What Silicon Valley gets about engineers that traditional companies do not
#219From my experience, the triangle communication is great within the engineering department. It can cause big problems if persons from outside engineering wander in and communicate with an engineer. Typically, this is a problem when the engineer happens to want to be helpful and winds up spending time on a matter unrelated to the task they have committed to delivering. We've seen hours, days and even weeks of time cons…
What's worked for us is to not restrict communication, but to hold our engineers accountable to what they say they'll get done and when. If something slips and it's not for a technical or personal reason (i.e. some risk materializing or needing to take unplanned time off), but rather because someone floated in and asked for something that wasn't scoped in, that comes up in a review and reflects poorly on the engineer and the asking party. On the other hand, if the engineer is able to get all of their scoped work done and also get the unplanned work done, that reflects well on the engineer and potentially the asking party. In our experience, approaching these situations in this way also has the benefit of preserving and encouraging individual autonomy.
Re: What Silicon Valley gets about engineers that traditional companies do not
#220it's funny, as the faang interview process, as i know it, does not select for the hybrid dev/product skillset the OP describes. in fact, it shies away from it about as far as you can get, instead focusing on beloved algorithmic problem solving, which i guess is a good fit for standardized testing and leveling, but will tell you nothing about broad skills in both software development and product design/management as d…
THis process is not required for your average company where IT is a cost center and CRUD-type apps generator.