| Spent years at Intel. Definitely saw what is described here. Must also add that it is a big company with no clear culture, so many people will have been in teams for years and not have encountered what skynetv2 is describing. My two cents: Intel is full of people who are career oriented and not product oriented. Their main goal is to get a promotion, and often find means to do so without contributing anything meaningful to Intel's products. It's also full of senior leaders who believe strongly in credentialism[1], complexity[2], and style over substance (i.e. how the message is delivered vs the content).[3] From a SW standpoint, I have not yet been in a team where all teammembers can handle branches.[4] This is quite acceptable. In one team I was in, I was leading the efforts for a product that required features A and B by the customer. I was a junior member of the team with no domain knowledge, but I was somewhat of an expert for that customer's domain. Everyone was on board with the technical work. In every meeting we had for about a year, there would always be some person in the team who'd suggest things that would nullify feature B. I would have to remind them that we agreed to do features A and B." The response would always be "Oh, we're also doing feature B?" The person who would say this varied from meeting to meeting. But I was very frustrated that they couldn't remember this basic fact, and often ended up writing code that had to be undone. And then deal with their frustration as if I had never mentioned feature B to them. I can understand if this happens once or twice, but I have to remind them in every meeting. But this was normal behavior. I was the odd person who thought this was unacceptable. Oh, and coming to meetings unprepared is the norm. No one will read your emails briefing them about the meeting ahead of time. [1] "Let's hire the PhD with no experience and not the internal MS employee who's already doing the job they are hiring the PhD for" [2] "I don't care if your code sped up our workflow by 5x. It's just what, 200 lines of code? Anyone can do that." [3] Presentations break most rules of effective communications/presentations. A senior person once told me "You explained things too well, and your slides are fairly sparse. Fill it up with jargon and lots of plots, and don't explain it as well as you did. If senior management understands your work too easily, they will believe the work you did was trivial. If they have trouble understanding it, they'll be in awe." [4] One former manager: "Every person will get his/her own private branch. Do all your experimental work there. There will be no more branches." A senior member in another team said "Why complicate things by adding new branches for our various experiments? Let's just keep it in the main branch and enable the different algorithms via command line flags." |
For perspective, this is typical LargeCorp behavior, especially at a company like Intel which makes 77 billion/year in revenues (700k/employee) at a 25% net income margin! The unwritten rule is that managers aren't incentivized to police this behavior. It's liberating to recognize this and modify one's approach.
> Oh, and coming to meetings unprepared is the norm. No one will read your emails briefing them about the meeting ahead of time. >A senior person once told me "You explained things too well[...] If they have trouble understanding it, they'll be in awe."
Wise words. In cultures that do this, you have to adapt and work more on narrative/story-telling. In many ways, this is how things actually work no matter how efficient you think you're making the team. Instead, write the same emails, but only to gather your thoughts. Then, lead the discussion. In large teams, it feels like this approach reminds me to avoid doing someone else's work.