Autonomy is certainly a huge factor. Providing engineers with the tools and compensation they deserve is how you set them up for success. If they have to think about being underpaid or potentially having higher outcomes elsewhere, that’s mindshare / allegiance you’re losing out on as a company. Part of the reason why comp packages for senior level roles are so high especially in stock, see https://levels.fyi
What Silicon Valley gets about engineers that traditional companies do not
271–280 of 339 posts
Re: What Silicon Valley gets about engineers that traditional companies do not
#272I'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…
Regular practice in other industries don’t need Agile to work fast, be creative, or hold people to account for their work. How is software different in this regard?
Re: What Silicon Valley gets about engineers that traditional companies do not
#273Earlier quoted context omitted.
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…
> If eg the engineer engaged in these conversations decided to leave, it would preserve the record for the person replacing them. How many of those recordings are ever played back? None, in my experience.
I was referring primarily to slack conversations. Usually when searching for a unfamiliar service or tool, I first do a slack search, then look at a KB/Wiki, then at code etc.
Public slack threads are pretty great since you can follow the decision making process when solving problems. Great slack threads may even include data on what the author tried/didn’t try etc.
I agree with you that video recordings are for the most part useless. Until we find a way to get high quality automatic transcription of videos and add them to a good search index, they will have limited use.
Re: What Silicon Valley gets about engineers that traditional companies do not
#274Earlier quoted context omitted.
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.
In a perfect world yes. But the majority of JIRA stories that I’ve come across often don’t contain complete information. The best, well disciplined folks recognize that they will inevitably forget details and write careful summaries, most people write a few bullet point to satisfy the acceptance criteria for the story.
Slack conversations often contain more data. It’s also easier for me to follow a human conversation than a poorly written summary with many missing details.
Re: What Silicon Valley gets about engineers that traditional companies do not
#275Earlier quoted context omitted.
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 o…
> The money train is usually the part of the company that attracts the wrong kinds of people.
Waiting for it...
> 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.
Ah, there it is. I had to learn this lesson the hard way, and let me tell you, the kool-aid is no longer so sweet. The money train is often just a mobile coliseum. There's no escaping the gladiator aspects role. It's disappointing.
Re: What Silicon Valley gets about engineers that traditional companies do not
#276I'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…
or you could offer - optional non compulsory - support for recording and transcription to the engineers and pay them overtime to jointly produce a final copy / summary (destroying the materials unless required for compliance) as we used to do.
Re: What Silicon Valley gets about engineers that traditional companies do not
#277I was at Apple during the golden SJ era and it was like this. I remember asking my manager (in my first year or so, fresh out of school) about something and he replied "That's what we're paying you for!"
I was at Skype during the eBay years and it was similar. Lots of autonomy. Then Skype got sold, Silverlake instituted Scrum training for everyone, and well, look what happened. Product owners took over; the engineers became Jira-ticket minions.
That said, I do understand the problem with giving engineers too much freedom, if there's not enough maturity on the business side. I've been at places like that, too. Engineers gone wild. Just burning money.
I see too many startups adopting Agile/Scrum for lack of a better clue on how to run software development. These days I refer people to Basecamp's Shape Up for "just enough" structure.
Re: What Silicon Valley gets about engineers that traditional companies do not
#278I'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…
> "Product Owners" who are there to give instructions via Jira tickets
A good product owners facilitates the communication between business people and engineers (or designers, or others). They don't dictate instructions, they regularly spend time with business people to understand their needs and what they care about, work with engineers and designers to craft solutions that are the best suited to what the business needs. When the relationship works well engineers are shielded from constant interruptions, and can rely on one person to answer their business questions instead of trying to have discussions between all the stakeholders.
As an engineer I was myself very skeptical of the role in the past but then worked with 2 awesome product owners for a few years and it was a fantastic experience.
Re: What Silicon Valley gets about engineers that traditional companies do not
#279Earlier 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.
To be fair, I've seen engineers with a similar role.
Re: What Silicon Valley gets about engineers that traditional companies do not
#280Earlier 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?
Product folks (generally) can't implement their ideas on their own. Devs can.