7 ms·

Really resonated with this, reminded me of the journey I went on over the course of my dev career. By the end, my advice for every manager was roughly: * Don't

• agumonkey 2y ago
  talking about ownership, I ran into some git repo with a "declaration of non ownership" an economy of giving in a way
• dakiol 2y ago
  With modern team structures it’s difficult to have ownership all the way to prod. My team consists of: one product manager, one staff engineer, one or more lead engineers, one or more senior engineers, one engineering manager. The PM wants his share of the cake, so any big feature needs to go through his approval (“does this feature delivers value?”, “how many users will use the feature?”, etc.) The staff engineer needs to validate any design (that’s his job), and provide feedback if he thinks your design “sucks”. So if the feature ends up being successful, he gets points. The senior and lead engineers need to own the design and implementation details. The leads would probably want to cover a good chunk of the solution so that it appears in their performance review. It’s gonna be though for senior engineers to get a good share if the leads are already one step ahead. The engineering manager will own the timeline. He will ask you about estimates, but most likely you’ll feel the pressure of whatever imaginary deadline is set. So there you are in the middle of all those people wanting their share. If you don’t manage to own a good chunk of that work, you won’t be able to show it in your perf. review. Owning is hard. I have to say, though, that I only have experienced this in tech companies that are around 5-7 years (old enough to have well established processes, young enough to still hire like there’s no tomorrow) and that are obsessed with FAANGs: they will hire faang engineers only if they could. This mix ends up badly, because suddenly every team needs to be a high performing team, everyone is raising the bar and speed is number one prio. When working with companies that hire no faang engineers, everything feels better.
  • bibabaloo 2y ago
    I feel this so much. I feel like most of my job is playing politics to make sure people are happy and let them feel like they're adding value. Rather than shipping things to users to improve the product. It's honestly so depressing. Strongly considering going back to work at a small startup, to avoid having to work with these layers of middlemen that really add little to no value.
    • agumonkey 2y ago
      the one who solves this problem will flood the world with a neverending wave of light.. every day I wonder how come I do so few now that I'm paid compared to when I was jobless and hacking prototypes for $0 finding the recipe for creating goal driven, high speed, high quality, frictionless teams is a difficult quest
      • travisgriggs 2y ago
        Lobby your government to tax management hours. That’ll fix things. I often wonder how some open source projects manage to be so successful/productive with so little of what looks like corporate management.
        • pineaux 2y ago
          How would you implement this though? Wouldn't things just be renamed?
      • Micoloth 2y ago
        A difficult quest indeed, but not impossible. Sometimes teams like this do exist. You know the ones. They founded the trillion-dollar companies you hear about and became billionaires themselves
        • Vilian 2y ago
          Nah, it's usually luck and robbing someone else work, windows apple Facebook etc
• frigidnonce 2y ago
  [flagged]
  • nox101 2y ago
    Can you unpack your comment?
  • aylmao 2y ago
    I've worked at FAANG. Actual humans too.
• layer8 2y ago
  * Separate bullet points by blank lines on HN. ;)
  • spuds 2y ago
    Yeah, I'm facepalming on that one. Thanks!
• tayo42 2y ago
  > Stop making reactive decisions. If something bad happened on a total, extremely unlikely lark, don't act like it's going to happen again next week I hate this, like when there's an outage and the outcome is 100 half baked ideas that must be implemented, that just make things worse to work with
  • spuds 2y ago
    Yeah. And all the time spent on those 100 half baked ideas take away from time that could be spent working on the most likely cause of the next outage. (Real forward-looking risk reduction work.)
• aylmao 2y ago
  Recently, I was thinking plenty about trust within organizations, and it resonated with me too. I've worked at a few startups and have seen high-trust environments lead to a lot of productivity, comfort and success— and the opposite for low-trust startups. In general, I think startups tend to lean towards high-trust, especially when they're small and early, but I was part of a 15-person one that was quite the opposite, and it was terrible. The hiring process wasn't great. Long take-home task, and that was the only technical interview. A lot of talking, but not much noteworthy signal on the rest. Very long wait times. Now I know this is a red flag for low-trust companies. If they're not building trust at the hiring-stage, it means even after joining the organization it'll take time to acutally "be part of the team". Once at the company, I had no permission to poke around— everything was hidden by default. There was no space for discussion, I was expected to learn, not to comment. There was plenty of micro-management; after all, if they don't trust you, they need to keep an eye on you at all times. You're probably doing something wrong. The chasms were deep too; the company was building a web team to spin a contractor's project into a full web product, and I was supposed to lead it. We were disjointed from the rest of the company though, and would only hear about requirements through the founders. The team had interest on being more involved with the main product, but management just wasn't interested in making it happen, and just had us loiter around for a few months until they gathered requirements, and then implement some rather disjoint features. The project failed. I'm working somewhere else now. tldr; low-trust environments kill projects
  • spuds 2y ago
    Yeah, I think there's almost always a point where a company decides they need to stop generally trusting their employees. Then all the trustworthy ones start getting more and more frustrated, or just start checking out. Agreed that most startups lean towards trust. Need to keep that going as long as possible, and stay away from hiring managers who think their primary job is "protecting" the company from anyone who might make a mistake.
    • aylmao 2y ago
      > Need to keep that going as long as possible, and stay away from hiring managers who think their primary job is "protecting" the company from anyone who might make a mistake. On that note, a quick shot-out because I've been lucky enough to see the opposite happen at a big company too. Performance cycles at the company very much disincentivized big bets. Some engineers really thought project "X" was important, but it was risky— if it didn't pay off by the end of the cycle, per the way the bureaucracy worked, it wouldn't be great. The manager very much tried his best to protect them against this. In fact I don't think it paid that cycle, but the project remained active until it did eventually pay off. Shoutout to managers like this. The easy route is to act like a messenger for higher-ups, and never put your own skin in the game— but there's some out there that want to do what's best, not what's easy.
• Aloisius 2y ago
  > Require ownership all the way to prod and beyond, no matter the role. (Turns out people tend to really like that.) Depends on what you mean. Individual ownership over code/feature/module/etc would seem to run counter to the article - it's just another fiefdom. Collective ownership? Sure.
  • T-Winsnes 2y ago
    I think the right balance here is to have ownership of the outcome rather than the thing. E.g. you have ownership of making sure the feature you’re working on makes it to production and works properly With that ownership comes there responsibility and accountability of making sure it happens. The level of responsibility and autonomy that comes with that is what I’ve found people react positively to
    • Aeolun 2y ago
      Ownership to ‘make sure it happens’ is entirely different from being able to ‘make’ it happen. The first is absolutely toxic.
• motorest 2y ago
  > * Stop making reactive decisions. If something bad happened on a total, extremely unlikely lark, don't act like it's going to happen again next week. I don't think this item was well thought through. Taking proactive decisions means allocating work for tasks that do not solve a concrete problem but bear the risk of introducing regressions. On the absolute best scenario, things continue to work as always. On the absolute worst scenario, you introduce a critical regression that brings down the service. There is literally no upside and all downsides. There are many reasons why "if it ain't broke don't fix it" is tried and true. > * Resist the urge to build walls between people/teams/departments. Instead, build a culture of collaboration (Hard and squishy and difficult to scale? Yup. Worth it? Absolutely.) That really depends on what you mean by "walls". The reason Conway's law is a thing is that in order to have functioning teams you also need functional independence. If you need to book a meeting with anyone to justify pushing a change to a service you do not own, that's already a wall. No matter how easy it is to get through that wall, it's still easier to not have to go through it. I can tell you an example of how independence always beats collaboration. Once I worked on a project where QAs were a separate team entirely, and made it their point to be the sole owners and maintainers of all automated test suites beyond unit and integration tests. We experienced a major regression that the regression test suite wasn't caught. I went right to the head of QAs and asked if I could push a commit to add a couple of regression tests. He politely declined by saying that they were already working on it and I wouldn't need to bother with that. Great, a victory for not building walls I guess? Except that his "we are working on it" ended up being "we added a ticket to our backlog and we might pick it up two months from now". Literally. And they never did, by the way, and the same regression was eventually introduced without anyone noticing. In case you wonder how I solved that problem, I created my own regression test suite. Conway's law always wins.
  • khafra 2y ago
    The context of "stop making reactive decisions" isn't "start making proactive decisions." It's to just make fewer decisions. The specific example is of a rare event which, while regrettable, does not justify the cost of policy changes to prevent it.
    • 2y ago
• miki123211 2y ago
  > * Stop making reactive decisions. If something bad happened on a total, extremely unlikely lark, don't act like it's going to happen again next week. I feel like everybody needs to internalize this one (and that notably includes governments and politicians), but it's a really hard problem to solve. If something bad happened, people (whether that be higher-ups, journalists, lawyers or your constituents) expect you to do something about it. "yeah, a child just got raped on our property but we don't have to do anything about it, it probably won't happen again" is not an acceptable answer in most circumstances, even if it's the right answer.
  • lysecret 2y ago
    Yea Germany quitting all nuclear comes to mind…
    • Timwi 2y ago
      I thought of that too, but also the US banning Kinder Surprise eggs.
    • yard2010 2y ago
      Bad example in my honest opinion: Merkel made me believe it's the "worst case scenario" kind of thing - same reason there shouldn't be capital punishment. If you can't afford to pay the price in the worst case scenario you shouldn't take the risk. That being said, I believe failures and mistakes are simply part of our lives. I would turn the other way and run when someone says that he found the perfect system, in which there are no losses failures and problems. You are always limited by what you don't know you don't know.
      • Cpoll 2y ago
        > If you can't afford to pay the price in the worst case scenario you shouldn't take the risk. Which probably precludes leaving your house (or staying in it, for that matter).
• kookamamie 2y ago
  > Require ownership all the way to prod and beyond Ideally this sounds great, practically it rarely happens in modern organizations. Companies, and corporations especially, do not like the idea of engineers having personal ownership over things, as that makes them harder to replace, i.e. reduces the redundancy of the organization.
  • Lanolderen 2y ago
    Redundancy is honestly a good thing. Some smaller companies not in IT have their entire software/hardware infrastucture dependant on a single person who's been there for 20 years and it's objectively dangerous. Is ownership incompatible with redundancy though? The way I understand it ownership is more so about keeping the app in the specific teams hands to avoid having secretaries running from team to team trying to keep teams from unintentionally sabotaging each other and handling suggestions in a constructive way so everyone is involved in the architecture and general direction of the product and they don't feel like code monkeys. You can still have 20 people on a single project each owning it to an extent. You probably even get more redundancy that way since people are incentivized to look at the bigger picture if they can impact it. PS: Stupid question but is there an actual definition for ownership? I think I might be talking out of my ass here.
• mihaaly 2y ago
  Excellent points! I wonder why these almost never considered.
• wkrsz 2y ago
  > Resist the urge to build walls between people/teams/departments Do you often have to deal with support staff reaching out directly to developers on Slack to investigate some problem – without going through "normal" process of creating a ticket that gets assigned? Or even asking for features. Developers generally want to be helpful, but also small requests often turn out to be rabbit holes. And even in best case it distracts from work that was explicitly assigned and scheduled. I noticed I experience a bit of anxiety every time I'm doing some work that came through backchannels. The way I try to alleviate is create the ticket myself, mention its source and assign it to myself. This way switching context is visible and I can tell myself that "if manager doesn't want me to spend time debugging this now, they can react".
  • 9rx 2y ago
    In fairness, it seems the problem in your case is that the "manager" has built up walls between people, trying to own the work, and in that not allowing you the full context that would allow you to make informed decisions around such asks. "The manager not wanting you to spend time debugging this now" should be a false premise. Knock down the walls and you will know yourself that you shouldn't spend time debugging it now.
    • wkrsz 2y ago
      That makes sense. Either knock down the walls all the way and empower developers to make decisions, or keep the walls and let all requests go through the pipeline.
• theropost 2y ago
  I completely agree. I’ve had the privilege of working with a very small team of engineers—a team with diverse life experiences and unique areas of expertise but a shared work ethic: the willingness to try. We always said that most of our time was spent failing, and that’s what made the moments of success so rewarding. When we finally succeeded, it wasn’t just about the victory; it was the culmination of relentless effort that allowed us to push forward, improve our product, and refine our ideas. Our approach was unique. We engaged directly with the people who did the work, learning from their insights and challenges, and built tools specifically for them. It wasn’t an Agile team or a Waterfall approach, or any other rigid corporate framework. It was an ad hoc team that came together organically to solve problems—and solved them faster than large corporations, consultants, or armies of workers ever could. With just four people, we scaled applications, built automation systems, and tackled complex problems that delivered multi-million-dollar savings across the board. The process was simple: no micromanagement, no unnecessary oversight. Everyone contributed based on what made sense, and we all collaborated freely to solve problems as they arose, moving seamlessly from one challenge to the next. It was innovation through cohesion—a kind of synergy that can’t be forced or replicated through standard processes. It’s the magic of the right people, in the right place, at the right time. Over the years, the tools we developed have grown into critical applications used by professional organizations, with over 3,000 users relying on them daily to make their work hundreds of percent faster. Yet, when these tools are handed over to large organizations for "modernization" or "corporatization," they often end up spending exorbitant amounts of money, adding no meaningful features, and making the tools less effective. Teams of 30 people fail to replicate what our small team accomplished. It’s a strange and frustrating reality. I’ve tried to find ways to replicate this success, but I think it comes down to that intangible element—a “ragtag team” dynamic where the right people come together with a shared drive and passion. It’s rare, and perhaps it doesn’t exist as it once did. Maybe it’s out there, but we need to find ways to enable and foster it.
  • RHSman2 2y ago
    I think there are ways of philosophy not process. And the philosophy has to be agile to those in it.
• kazinator 2y ago
  The Process Person who wants to build a Mature software organization will say, process is seriously needed.
  • kubanczyk 2y ago
    That dork can only become factory manager when there are factory workers, see? "Process" is just a word for a production line of some kind - narrower or broader, but still a life-sucking endeavor.
• steelframe 2y ago
  > Stop making reactive decisions. If something bad happened on a total, extremely unlikely lark, don't act like it's going to happen again next week. This is a central theme in Bruce Schneier's 2003 book Beyond Fear, which I continue to recommend 20 years after I first read it.
• beryilma 2y ago
  I really believe in the ownership model, which is why I hate the Jira ticket-based development model so much. There was a time in my company where a single developer, who owned the product, would ship an entire app in a year. Now we have a "cross-team" where you have to constantly manage all feedback and try to shut down stupid ideas from getting into the product. I really hate design by committee: all talk and no ownership.
• munksbeer 2y ago
  In my humble opinion, this is excellent advice. Honestly, so on point.