Live data from Hacker News

What Silicon Valley gets about engineers that traditional companies do not

blog.pragmaticengineer.com

211–220 of 339 posts

Re: What Silicon Valley gets about engineers that traditional companies do not

#211

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…

Maybe (or not, I didn't think that idea fully yet) it is time to start cutting the software development jobs in two jobs: Technicians and engineers. And maybe it is also time for developers to organize take the lead of their craft.

Re: What Silicon Valley gets about engineers that traditional companies do not

#212
post #74

Earlier 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…

Just print this FAQ and hang it by your desk.

  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 tracker

Re: What Silicon Valley gets about engineers that traditional companies do not

#213
post #203

Earlier 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.

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 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

#214

I 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.

The requirements should be coming from elsewhere and hopefully you are involved at the start of the project. Hopefully you should be catching all issues regardless and the increase catches look good to your matrix.

Re: What Silicon Valley gets about engineers that traditional companies do not

#215
post #161

Earlier 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…

The idea of capturing ppl's conversations is weird. Details of that work are captured in the project stories and version control commits.

Re: What Silicon Valley gets about engineers that traditional companies do not

#216

Earlier 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.

The reasons behind the creation of Scrum and the reasons behind the adoption of Scrum are different.

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

#217
post #142

Earlier 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.

That is a company problem, not a Jira problem. (A very common company problem, and quite likely the underlying cause of a lot of people's Jira problems.)

Re: What Silicon Valley gets about engineers that traditional companies do not

#218
post #213
post #203

Earlier 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 would be interested if you have a few names of software cooperatives (still running or not).

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

#219

From 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…

We've run into the same problem. What's made this a particularly hard problem for us to address is that the intentions of involved parties are usually aligned with the best interests of the business in the short term despite being misaligned (and detrimental) over the medium and long term. In discussion it's clear that both parties are doing what they believe is right for the company, but their level and responsibilities might inadvertently encourage them to optimize for the short term. The ensuing conversation is usually a tight rope walk between trying to get both parties to understand short term vs long term outcomes and consequences while encouraging them to continue to execute on what they believe is right for the company.

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

#220
post #171

it'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…

algorithmic problem solving is very close to IOI/ACM ICPC type problems, which test on combination of knowledge of data structures+algorithms and creative ability to combine both to create own algorithms while being under interview anxiety+time limti stress. Quite essential in everything internet-scale and filters top percentile candidates pretty well.

THis process is not required for your average company where IT is a cost center and CRUD-type apps generator.

Post reply on HN