Live data from Hacker News

What Silicon Valley gets about engineers that traditional companies do not

blog.pragmaticengineer.com

161–170 of 339 posts

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

#161

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…

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 political.... I would start looking elsewhere.

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

#162

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…

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.

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

#163

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…

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

I have to ask though: if a company built on engineering doesn’t empower its engineers to make product decisions, who can make them?

In my anecdotal experience, the “product” people generally have lesser context than the engineers, and often rely on engineers to do their jobs. The good ones make a serious effort to get at least a vague understanding of how the product works and are hungry to hear ideas on how to deliver more value.

However most PMs will not be this way. Their primary instinct is to interface with the product hierarchy and explain to engineers what the “higher ups” want. They exercise this power by vetoing ideas that don’t fit into this narrative, even if these ideas would improve the product. Engineers then mostly don’t really share everything that they’re working on with the apathetic PM; the motivated ones build things anyways risking rebukes while others will do just what product asks for.

The only scalable solution really, is to create processes and career paths for engineers who are inclined to product design to become PMs, or at least spend part of their time as PMs.

At Service Oriented B2B companies, there is another class of people who become excellent PMs: the Customer Service Managers, who have dealt with Customers and their issues, and have a deep understanding of the problems and frustrations faced by users of these systems.

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

#164
post #36
post #24

Earlier quoted context omitted.

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.

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

Scrumplestiltskin. He promises to teach you to spin stories into code but then takes credit for your prototype.

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

#165
post #137

Earlier quoted context omitted.

That's a good theory, but it doesn't always work that way. I was working on the most profitable product the company had, but was laid off anyway. The new 6 month CTO had a new idea for how software development should be done and I wasn't part of it. Meanwhile at my prior job in IT my boss begged me to stay, I think because I made him look good.

Can relate to the latter. I've left about half a dozen jobs before striking out on my own, and the places where my boss actively pleaded with me to stay were places where I was definitely an operations cost centre and a galaxy away from anything resembling a profit centre or a revenue driver. Politics. I was competent, precocious, energetic, participated in many meetings and liaised with lots of teams with which peop…

The money train is usually the part of the company that attracts the wrong kinds of people. They know it’s the easiest way to succeed: by being part of the team that brings in a lot of revenue. It becomes easier to show your “contributions” in monetary terms even if you may have not been directly responsible for that. As a result, these competitive types will also try to remove anyone who isn’t an “ally” regardless of whether these people provide value to the business.

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

#166
post #122

Earlier quoted context omitted.

Now fly my scrumlings! Bring me their estimates! Eeehehehe

Meh. A real Evil Scrum Lord makes his victims enter the data by themselves into Jira.

Twice. Once in points after Planning Poker has sized the story -- the second time in hours.

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

#167

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…

I've been the client engineer before, trying to get through the opaque 'solution support' folks to the actual engineers of the product. No dice. We could never get the problem solved and we ended up ditching the product.

When I eventually got an NPS e-mail from them, I gave them a 1, and explained that I couldn't get through to actual engineers so we gave up, and then a solution engineer followed up and apologized and informed me that if there was anything they could do, to let them know.

I never wanted to bang my head against the monitor harder than in that moment.

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

#168

Earlier quoted context omitted.

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…

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.

That's interesting... I think. Could you give an example (as contrived as you wish) to illustrate this point?

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

#169

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…

These are people whose entire job consists of sitting in meetings and firing off emails. They can't conceive that other people do work collaborating outside of a meeting room.

Not just collaborating. Any kind of work.

We plan 8 hours a day of work for developers, but they spend 4 hours in meetings, 2 hours fielding questions and just 2 actually working.

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

#170
post #122

Earlier quoted context omitted.

Now fly my scrumlings! Bring me their estimates! Eeehehehe

Meh. A real Evil Scrum Lord makes his victims enter the data by themselves into Jira.

Hell no. At least then I know it’s entered in a sensible way. If I let the scrum lord do it it’ll be a mess.
Post reply on HN