There's a reason 5 Why's Analysis is a thing. If you just say "here's a bunch of stuff we're changing," but you haven't said enough about the root cause, then no one will understand whether we're doing enough (or too much; or the wrong things). I like the framing of being empathetic - everyone is smart, doing the best they can with their knowledge and experience at the time - but sometimes we didn't do all the right things, and getting feedback from more senior engineers helps drive that improvement.
> There's a reason 5 Why's Analysis is a thing. If you just say "here's a bunch of stuff we're changing," but you haven't said enough about the root cause, then no one will understand whether we're doing enough (or too much; or the wrong things).
No, that's not the point at all.
Root cause analysis and context and tradeoff analysis and plans are still critical requirements.
But not everyone needs to do root cause analysis and evaluate tradeoffs and review plans. Some stakeholders don't need any of that. They pay you to care, so that they don't need to.
What these stakeholders care about is whether you can fix things, how are you planning on how to fix things, how many resources you need to allocate to fix things, and when are things fixed.
Different audiences require different messages because they have different concerns and responsibilities.
Does a project manager need to know the failure rate of a DSL connection of a customer that reported an outage? You might, but does the project manager need to?
Since this is at the top of Hacker News: this article is not good advice generally. Here's what I do (and mentor people to do the same):
1. Don't start with the argument, start with the data. Debates/arguments/discussions etc. are what to do about the underlying data, but I've found very often the disagreement stems from people having different bits of data. Before you get into how to marshall an argument, you have to start with collecting what ground truth is. Many people don't practice this intentionally, so they get into a debate over some decision the team is making without having all the facts.
2. Form opinions easily, be ready to discard them quickly. I am quite happy to share my understanding of some technical matter, and I almost always provide that understanding with an invitation for people to tell me why I'm wrong.
3. Over the short term, yes, it's hard to change people's minds. Over the long term, you don't have to change people's minds, you can change the people you work with. You can vote with your feet or (if you're more senior) you can influence how your organization hires and promotes people. I actively seek out working with people who disagree with me in interesting ways. Not pedantically, and not over minutiae, but in ways that change how I see a problem. It turns out, when you seek out people who are good at productively disagreeing, you don't run into some of the problems OP writes about as often.
4. One of the ways to help sift out who the people are you want to work with is by offering feedback. Most people are terrible at giving feedback, so it's important to first get good at giving feedback. The author says that people don't learn from feedback, people learn from consequences. One of the effective ways of delivering feedback is to structure it as "Here was the situation, here are facts about what happened, here is the outcome." However, once you get decent at giving feedback, some of the benefit of giving the feedback is in the signal of how the person responds. The people I want to work with generally take this feedback well, and in turn offer me similar feedback.
5. Debate what matters. A lot of technical debates engineers engage in are either not important to the end product are easy to change later. Don't waste your time on those.
Mostly agree with this article. When I mentor people about managing, some other bits I also usually mention:
1. 'You’re not “part of the team” anymore.' - You're not part of the software dev team, but if you're doing things right, you're part of a team, just a new one. I encourage manager mentees of mine to read a book "Five Dysfunctions of a Team" which talks about figuring out who your "first team" is. Even in environments where you manage an autonomous team, you likely are working alongside other teams towards some bigger goal. Some of the things that worked being part of a software development team continue to work in the new setting, but you also need a new set of tools.
2. It's a two-way door. I've bounced back and forth between IC and manager roles. Some of it is just how the job market is (you look for a job, there aren't manager jobs, you go back to being an IC). Sometimes, people do it intentionally because they like being an IC. It's ok to try out being a manager, and realizing you don't like it.
A lot of what's here isn't specific to managing, and if you advance in your career as an IC, you'll experience similar.
The limited amount of true people management I've done has felt like a really valuable educational process, even if I never embrace wearing that hat exclusively.
Back in Soviet times there was a trend in Sci-Fi depicting the bright communist future when people changed professions every few years or so, often between manual and intellectual, to stay sharp.
Interesting parallel I was unaware of. On a personal level I have found it very useful to alternate between mental and physical work for the sake of endurance. If I was mentally tired I could usually still do physical work. This was helpful within the scope of a day or week and I imagine that such alternating also aids longterm endurance.
Not a question, just thought I'd throw out that I worked through Black Art of Java Game Programming when I was learning Java in 1997 or so. I still have my copy because I don't like getting rid of books. I found it really helpful for learning patterns for building medium sized software projects. I hadn't realized that you wrote that until years later when you mentioned something about it in The Startup Way.
No way! I would absolutely love to hear what you thought of that book. In fact, you may be the first person I've ever interacted with who actually read it!
I was in middle school at the time, learning programming. I think by that time, we had home Internet, but it was really slow, and so a lot of my learning about programming was either from the help files that came with the IDE (at the time for me learning Java, that meant Microsoft Visual J++) from books I convinced my dad to get me from Barnes and Noble as a reward for doing the "important" summer reading. I had a couple Java books before, but they were more focused on the mechanics of the language. Your book was the first that talked about how to put together a system.
As a specific example, I had never been exposed to much in the way of networking concepts before. Black Art has a chapter in adding networking functionality to a game which was my introduction to networking concepts and how to build networking software. Until much later when I learned about higher-level frameworks, I used the design patterns for network programming in several projects in school over the next several years.
Not OP, but within Amazon we have pretty good connectors around integrating with our task system (so you can pretty easily ask your GenAI tool "look up the next item in our sprint board, let me know if you have any clarifying questions, but otherwise start implementing it"). We have decent integration with internal wiki and search systems, so it's easier now to figure out the best Amazon way to do some coding task. And Amazon being a big doc-writing company, there are lots of great tools for helping improve all phases of writing.
I work at Amazon (standard disclaimer: just sharing my own experience, not an official spokesperson, etc.)
I can't say that this isn't happening, but at least the parts of the company I get visibility into, what the article describes isn't my experience. There is a lot of interest in using GenAI, but people are mostly getting kudos around creative uses for GenAI, not just for raw amount of tokens. For most scaled GenAI efforts, there is a lot of focus on output metrics (metrics like accuracy, number of findings, number of things fixed, and so on).
I also work at Amazon and my coworkers are playing 20 questions every morning to keep their metrics up. Like anything else there it depends on your org & managers.
I'm surprised how few comments are written with the prior that Amazon managers aren't stupid or uninformed about how incentives work.
My guess would be that someone created the leaderboard without a lot of consultation with managers, and that some employees feel a competitive urge to try to "win" the leaderboard by burning tokens.
Mmm, no, I don’t think it’s equivalent. I think they know that if you make the work hard, some employees will have trouble keeping up and will do things like peeing in bottles. And they’re OK with that, because they think there are enough people who can keep up that they can push the weaker people out. I think they believe that the peeing in bottle is relatively rare. I’m unsure whether that’s right or not. It’s been reported that it happens, but I have no sense whether it’s common.
Amazon is a massive company, your single experience is worse than an anecdote because there is no way verify.
What we can verify is how how Amazon already treats workers, they will surveil anyone within their systems regardless of the futility of said surveillance. Why are we suppose to not believe them using LLM systems as a means to further control their expensive employees from unionizing or seeking out solidarity with fellow workers? All LLMs do is enable tyrannical managers more power to hold over other workers, said workers are forced to engage in self alienation for fear of losing your job or forcing to do meaningless work as that is what's being tracked (and what LLMs excel at producing).
Hardly a good proposition for any worker.
I'm sorry but I fully do not believe you. This is a company that fires workers for taking too long of a bathroom break where said workers piss in bottles for fear of getting fired and you're going "hey guys, it's not too bad. Only some workers get whipped, others don't!"
The intentions of a government aren't enough. You need feedback systems. China doesn't have effective feedback systems, because the CCP actively destroys them. No one is "turning towards China" - they have negative net migration since 1968 (https://data.worldbank.org/indicator/SM.POP.NETM?locations=C...).
reply