mindtricks

It's an interesting point about motivation and work load. My experience with burnout occurred at a time where I was regularly doing 60 hours / week, and enjoying it! The motivation hit came when a new manager moved into the team, and he suddenly wanted to shift my role in a career direction I did not agree to. Prior to him joining, I felt my path was progressing in the direction I wanted, with the blessing of my previous management.

It's amazing how fast a single person can flip that motivation versus work load into the wrong direction.

Facebook is an ad company, and if that market is declining, those cuts may come from non-technical groups meant to serve those accounts and markets. There are likely other programs necessary with high marketing needs that I could imagine need culling and thus fewer people.

When I was in business school for my MBA, the human component was absolutely covered, and I suspect that is the case with many of them. Part of the problem may be though that there are subjects (finance, operations), where I can see the concept of a human resource becomes a bit abstract in order to focus on other concepts. In this regard, schools can certainly do better to connect the people element across disciplines.

For those with a complete disdain for "business types", I'd encourage you to read Peter Drucker. Some of his opinions may feel a bit outdated, but he speaks quite a bit to the knowledge worker and their needs.

The reason most young engineers think this way is 1) they think their work is self-evident and doesn't require demand creation, 2) their management does not engage with marketing and therefore can't convey the value down, and 3) confuses "growth hacking" and "advertising" with the broader work that marketing supports.

...and for the records, they're completely justified here. They have a lot on their plate as a new engineer and this is not an area that has immediate value to them.

I struggle with this as well. My team grew during COVID, and many of them are in different locations. In many ways, they haven't been able to gel as a team. There are other managers who had teams before COVID hit and their virtual hangouts just amplify the bond they had before.

People will complain about these events, but I just don't know any other way to help teams learn about each other.

I'm not sure I 100% agree with the rule, but sales teams should definitely consider it deeply.

It's worth the money for a sales team that understands this process. If your team isn't influencing the RFP, that means they have no real relationship with the client and relevant stakeholders. You'll likely just pull in cost-conscious or high-maintenance clients.

The author makes innovation out to be something akin to "if we focus on this, then it will change", but that's not how this typically works. Most development is based on smaller improvements and discoveries made years in the past. And those take time to mature and scale.

Sometimes they converge around the same time and it looks transformational. More often though, they are slowly incorporated into the progressive change we enjoy.

It's also likely that areas that are important to him, just don't have a market. It doesn't mean people aren't innovating, it just means that resource allocation towards innovation went to other areas (for good or bad).

People need to internalize that more. The gut-check reaction from most people is that process = overhead. It may be true that it creates that from time to time, but essentially a process should help align, remove confusion, maintain flow, and open up organizational capacity to do higher-level and more impactful work.

Most of what you have shared can be easily explained. IT trying to be responsive to you by making sure you have a laptop seems reasonable -- they may be concerned if they wait after Christmas, it would lost in the shuffle. They just made not have had the EQ to think delivery affected you, especially if you gave them address to ship it to them.

Since you're working with a tool (and want education), your manager just may want to expose you to the vendor to help you succeed. It may be that talking with the vendor in this way may not be easy to set up.

And I say this because it sounds completely normal to me for this size of a company.

That said, if "best intent" is still not enough to justify their requests and actions to you, then that's on you to decide the work style and company you like. And if you feel you have the opportunity to pursue opportunities elsewhere that best fits your comfort zone, then you should.

Instead of root cause analysis as blame laying, look at this as more of an identification of diagnostically important reasons. The above example doesn't help anyone. If code was late, would you accept "our developer is incompetent" as a root cause? Of course not. It's possible that they are, but it's also possible that requirements were not clear or that they took toe long to clarify, which led to a reduced amount of time to do actual development.

In a bigger sense though, the exercise is to force you to take a moment to look beyond band-aid solution, not as an exercise to critique capitalism.

In all fairness, the author is not a product manager by title or training. He's only sharing "product management" tricks or techniques that's helped him during his own development. If you've done these things for a while, may not be much to take away here, but for junior PMs or junior engineers, this is probably enough to shift their thinking a bit.

We lack public dancing space, yes, but the US typically has a lot of space open for exercise, although not in the same manner. In almost every town and city you'll find basketball courts, baseball fields, high school football stadiums with tracks typically open (and available) around them. It's organized in a different way and promotes different types of social interactions, but that's more a result of underlying desire for sprawl...which is something China can't afford.

It's not about new, it's about highlighting progress against a plan that will likely create new competitors on a global stage while closing out any free market competition within their come country.

To add to that, if you default to the position that any meeting is pointless, you'll find yourself continually frustrated and likely wrong at times. Talk to your manager about time management and let them know where you think your time is best served. They may agree and give you the cover you need to duck out, they might revamp some meetings to be more effective, or they may just give you the context you need to have the meeting become more valuable to you personally.

yes, but they also deserve the criticism that comes with the action. it was the right action, but done way too late, and in a way that now looks vengeful and petty.

I've worked in large and small, with good and bad cultures. And to be clear, that is not my view of developers. I point it out because I agree with the author of the article that there are differences in companies. I'm sorry that those traits did not get you where you wanted, but they are not bare minimum in a lot of companies. I've walked engineers from their seats over to the counterpart's seat and have had others who do not go outside of their area due to an inaccurate belief that it's not what their manager wanted.

From personal experience on the product side, if you want to be more involved with the business, I'd recommend you work on two things from this article. First, curiosity is an absolutely must have. Without it, you'll not be able to truly learn what a customer is looking for. Second, demonstrate you can "talk with another engineer" without manager facilitation. It's a signal of ownership that I guarantee people will notice.

If it doesn't exist, we can call it Orwell's Law - Whatever Big Brother is capable of seeing, it is seeing.

Trying to do this now. They aren't budging on the rent, but are pitching a reduction to removal of parking and pet fees. I don't know if this is because they fall out of rent control regulations. Was aiming for a 10% total reduction, but they've effectively hit a 4% reduction in my case.

The trolley problem came up a lot in The Good Place, which may be why discussions around it have suddenly become a bit more mainstream.

It didn't seem that long ago that having an island shaped like a skull was a cost-prohibitive proposition, but seems we're almost there.

Take an ownership role in what your team is trying to build and the purpose in which it's intended to serve. If you don't, people around you won't feel the need to either. And those that do need you to be an owner when you're not, will find ways to go around you.

While I'm sympathetic to the author, we have a significant amount of history showing that two parties work quite well. We certainly have our issues with long-term thinking that's not helped by this system, but in general, America is still doing quite well.

The shallow library argument is becoming increasingly dated. If you compare it to studios who have been around for decades, then sure. If you want to limit it to "quality" content, then maybe. If you want to look at it from a pure numbers perspective, Netflix is killing it.

https://variety.com/2019/tv/news/netflix-more-2019-originals...

Every PM needs to do that, but working directly with a customer isn't always an option for the engineer. Point above is just to point out that thinking about whether you'd use or pay for the service yourself goes a long way in changing a mindset and building empathy. It's not a recommendation to make up stories.

As a long-time product manager, I completely agree that customer empathy and domain knowledge go a long way, especially around tactical needs. The easiest way to start is to just ask yourself, "If I were using this product/service/feature, would I want it to work this way?"