What Silicon Valley gets about engineers that traditional companies do not

Post by sesuximo » Mon, Jan 11, 2021, 4:19 AM UTC

closeparen wrote: post #56

opportune wrote: post #16

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. Eve…

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").

Post by tehjoker » Mon, Jan 11, 2021, 4:28 AM UTC

celim307 wrote: post #46

quicklime wrote: post #18

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…

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

Post by cjfd » Mon, Jan 11, 2021, 4:30 AM UTC

courtf wrote: post #24

opportune wrote: post #21

Earlier quoted context omitted.

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

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.

Post by tehjoker » Mon, Jan 11, 2021, 4:31 AM UTC

courtf wrote: post #38

klipt wrote: post #36

Earlier quoted context omitted.

Why settle for scrum lord when you could be scrum king? Scrum emperor? One day even scrum Pope?

> scrum Pope his holiness will make his presence known in due time

Post by TedDoesntTalk » Mon, Jan 11, 2021, 4:36 AM UTC

pm90 wrote: post #161

spfzero wrote: post #127

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…