241–249 of 249 posts
Why do we expect to have good managers when we promote based on technical competency rather than leadership ability? Sure, a certain basic level of technical competency is needed, but after that management and development require different skills.
Earlier quoted context omitted.
“No True Senior SWE” paradox? 10yrs is a very long time in Computer Science. All the engineers I’ve worked with from earlier eras are very influenced by what they started their career with. Heck I’m the same way as I approach my decade threshold.
Title inflation. I speculate based on no evidence other than my own observations that it's because companies aren't willing to pay entry or junior engineers well enough, so lots of them get hired at lowball rates with an implicit understanding that they'll get promoted to senior after 3 years and get the a corresponding pay raise. Either that, or they don't get promoted or a raise, change jobs, and get the senior tit…
Earlier quoted context omitted.
You don't pay someone $200k to churn out CRUD - there's plenty of lowcode solutions like Flask for that! I somewhat agree, though, the core issue with "paying for business value" is how difficult it is to really define that across an org.
>You don't pay someone $200k to churn out CRUD I've got some bad news for you about what 90% of FAANG work is like
Earlier quoted context omitted.
Speaking truth to power is rarely easy. Some leaders can take genuine feedback others cannot. Until you have a good pulse on the situation, is it really surprising most people default to inauthentic critiques?
This is why I'm very skeptical on the use of 1-on-1 meetings with management as a means to keep a finger on what's going well or badly in an organization. If someone is OK with telling management things they don't want to hear, they'll tell management those things regardless of 1-on-1s.
Like the whole premise of a skip level is the management hearing more things.
a.k.a. “Innovation”.
For whatever reason, I’m one of those engineers that big organizations seem to hunt down for their “innovation” agenda. I have much to say about these experiences. In particular, the advice given by innovation gurus like business professors, authors, and management consultants, is terrible.
Earlier quoted context omitted.
"It can be hard to see if they're contributing anything valuable" Indeed. It's easier to evaluate "the appearance of change" than actual value or improvement. When I consider this problem, my current belief is that only long-term discipline from senior leadership can change this system.
I was thinking about all this recently and came up with the question: In the event that someone fails, is it possible for it to be you? There are people who cannot fail at their jobs. I want one of those jobs. An upper manager who attends meetings and "makes decisions" and is personal friends with the CEO often cannot fail. If the product stops selling, it will be considered a failure of those below the upper manager…
I’m seeing a lot of comments that seem to point to first line management as the problem here. In my own anecdotal experience, I’ve seen a lot more “fake work” come from listless leadership that lacks a true vision for the product. That rolls down to Product Managers that can’t prioritize features and don’t really understand what they’re building or why. Ultimately this leads to engineers and members of the team worki…
> Gut from the top if you want to get rid of the problem. It’s not the L5 engineer or the first line manager that’s holding any product back. I tend to agree but there's a real danger in leaving engineers to their own devices. I know this will be downvoted, but software engineers are the worst at planning their own work. The vast majority will just go off and do wtf ever they want. There really has to be guard rails…
As an engineer-turned-manager, I am fascinated by how poorly other departments handle planning (at our company). Devs are just amazing at getting things done when left alone, provided they know why feature X is important.
See: https://www.goodreads.com/book/show/35051753-developer-hegem...
Earlier quoted context omitted.
That doesn't always (or usually) work in some of these BigCorps. It's not that they don't give you freedom to go ... do stuff -- they often do -- but there are also are often very concrete boundaries about who is allowed to actually have the stuff they do go into any kind of production codebase. And very rigorous review processes, etc. and often the first question in a code review on something exotic and new at a pla…
It was many years ago but when I was at Google I started a new project in my 20% time and then took it all the way to production, it's still there and handles millions of requests per second because it's integrated into many of their biggest products (it wasn't a standalone thing). Yes, I had to write design docs, do PRDs, do privacy reviews, get launch approvals and many other things. Sometimes I had to integrate th…
For the decade I was there, I couldn't honestly think of something I'd want to put that kind of effort into so that some human-dialtone like Sundar could cancel it later, or some pushier and better organized person could take credit for it.
But I have certainly thought of them after I left.
Earlier quoted context omitted.
Work more means what? It's about efficiency in terms of performance metrics.
It might be a combination of efficiency and generating value. If you're efficient enough to generate $1000/hr but the org has no opportunity or product for you that can generate this, efficiency in performance metrics alone doesn't move the company's bottom line.