5 ms·

I think an important point in modern technology development is that to make anything of value happen, you constantly deal with dozens of various silos, each of

I think an important point in modern technology development is that to make anything of value happen, you constantly deal with dozens of various silos, each of which can be a lifelong specialty area. You have to learn to skim most of the time and be able to dive deep -- a bit -- as necessary. We may be saying the same thing, but I like my way better :)

pavel_lishin 8y ago
I agree that everyone needs some management skills, but I'm not convinced that most teams can be run without a dedicated manager.
- DanielBMarkham 8y ago
  Agreed. The same as most teams cannot be run without a dedicated DBA. The question is whether or not the DBA does other things, not whether that skill is needed or not. If you've got six or seven people that need constant management, you're working at a burger joint, not a tech shop. If I remember correctly, in the book "In the Plex", Google scaled out to thousands of developers without having a dedicated management slot. (This is a good time to mention that all generalizations are false, including this one) In general, in the tech world I find the biggest supporters of "X should be its own job" are either the people who do X -- or train people to do X. Customers don't care one way or another. Neither should we. If we need an X, we get one.
  - pavel_lishin 8y ago
    My understanding of what a good manager's job is consists of largely managing the interface between the team doing the tech work, and the rest of the company: ensuring there's no external blockers, making sure that requirements are accurate, that realistic expectations are being communicated in both directions, etc. I don't imagine it as someone whose job it is to ask me once an hour, "so how's it going, can you code any faster?"
    - DanielBMarkham 8y ago
      Yep. Clearing obstacles and managing externals -- although once you give somebody the title there seems to be a lot more involved. The good managers I've seen don't talk a lot. The best managers are developers who have a natural skill for the work and got voted into the job, They do that obstacle-clearing and coordination on an as-needed basis, working alongside everyone else the rest of the time. The core of the problem is that tech development involves way more skills than there are people, no matter how you want to slice them. When you go for training or start putting folks in roles, the assumption is that your role is at the center of the org. Not the value creation stream. There's an oversimplification and false focus that occurs that's antithetical to getting things done. So yes, that's the manager's job. But it rarely stays like that.
  - mmt 8y ago
    > In general, in the tech world I find the biggest supporters of "X should be its own job" are either the people who do X -- or train people to do X That strikes me as a characterization with more cynicism implied than necessary. I, personally, routinely support job specialization, even outside my own specialty. Partly, this is bias/solidarity, but, partly, it's that, even though I'm happy doing Y, I don't want to end up spending 20% of my time doing X (and neither does almost anyone else, which they may not admit). > Customers don't care one way or another. Neither should we. If we need an X, we get one. Except that, no, "we" don't get one, not if we've trained ourselves, in the entire industry, to think X isn't its own job. Instead, we get a Z-that-can-also-do-some-X (but may, as I alluded to above, actually not want to do that X, or, as other comments in the thread suggest, can't do all of X). This is especially noticeable among startup job postings over the last 5 years where Z is programmer and X is either manager or ops (including the sub-specialty of DBA). How do someone even know they need an X if no X exists in their world? How we talk about things, especially to newer entrants into the industry matters. We should care.
    - DanielBMarkham 8y ago
      I apologize. I believe you may have misunderstood brevity for cynicism.These are systemic problems. There are no bad actors and everybody means well. I came to HN because it was supposed to be a place to learn about how startups work. I'm still here years later. One of the things I learned is that you let the market pull your startup. You can't push it. In other words, you don't know when trying to make something people want where this is going to lead you. Instead you interact with the folks you're trying to help and that interaction drives the things you do. There is much wisdom here. The other major thing I've learned in this area, from my own work with tech groups instead of HN, is that people like doing what people like doing. That is, given their druthers, people will always drift back to doing certain types of things. Like making reports? I'll bet you we can take you out of this job, put you somewhere else in a completely new surrounding -- and in a few years you'll be doing reports. It's what you like doing. We tech folks are really smart people, so we've managed to take everything we've touched, split it into smaller pieces, and make them complicated. It's what we like doing. Over many years, this means that any significant tech effort contains dozens of skillsets, all of which can be very complex. This number continues increasing. So with limited resources, as a small org or startup, you're faced with either letting the job drive out what skills you have to learn/use -- or not getting the work done. In larger companies, you can have the illusion that somehow you just need to grow enough experts. Small efforts can't do this. >>How do someone even know they need an X if no X exists in their world? Because X is a skill, not a role. If you transition from "jobs require these roles" to "jobs require these skills", and you let the problem drive your learning and adaptation, it all works out. If not? Overhead and friction increase as the required number of people increase, leading quickly to very slow projects. Everybody gets a role where they do what they want, but it's at the cost of focusing on the value instead of the employees. We naturally tend to view tech development backwards from what it actually is. So good people, doing their best to help folks, end up creating interwoven problematic nomenclatures, policies, and systems. Hopefully that sounds less cynical.

pavel_lishin 8y ago

I agree that everyone needs some management skills, but I'm not convinced that most teams can be run without a dedicated manager.

DanielBMarkham 8y ago
Agreed. The same as most teams cannot be run without a dedicated DBA. The question is whether or not the DBA does other things, not whether that skill is needed or not. If you've got six or seven people that need constant management, you're working at a burger joint, not a tech shop. If I remember correctly, in the book "In the Plex", Google scaled out to thousands of developers without having a dedicated management slot. (This is a good time to mention that all generalizations are false, including this one) In general, in the tech world I find the biggest supporters of "X should be its own job" are either the people who do X -- or train people to do X. Customers don't care one way or another. Neither should we. If we need an X, we get one.
- pavel_lishin 8y ago
  My understanding of what a good manager's job is consists of largely managing the interface between the team doing the tech work, and the rest of the company: ensuring there's no external blockers, making sure that requirements are accurate, that realistic expectations are being communicated in both directions, etc. I don't imagine it as someone whose job it is to ask me once an hour, "so how's it going, can you code any faster?"
  - DanielBMarkham 8y ago
    Yep. Clearing obstacles and managing externals -- although once you give somebody the title there seems to be a lot more involved. The good managers I've seen don't talk a lot. The best managers are developers who have a natural skill for the work and got voted into the job, They do that obstacle-clearing and coordination on an as-needed basis, working alongside everyone else the rest of the time. The core of the problem is that tech development involves way more skills than there are people, no matter how you want to slice them. When you go for training or start putting folks in roles, the assumption is that your role is at the center of the org. Not the value creation stream. There's an oversimplification and false focus that occurs that's antithetical to getting things done. So yes, that's the manager's job. But it rarely stays like that.
- mmt 8y ago
  > In general, in the tech world I find the biggest supporters of "X should be its own job" are either the people who do X -- or train people to do X That strikes me as a characterization with more cynicism implied than necessary. I, personally, routinely support job specialization, even outside my own specialty. Partly, this is bias/solidarity, but, partly, it's that, even though I'm happy doing Y, I don't want to end up spending 20% of my time doing X (and neither does almost anyone else, which they may not admit). > Customers don't care one way or another. Neither should we. If we need an X, we get one. Except that, no, "we" don't get one, not if we've trained ourselves, in the entire industry, to think X isn't its own job. Instead, we get a Z-that-can-also-do-some-X (but may, as I alluded to above, actually not want to do that X, or, as other comments in the thread suggest, can't do all of X). This is especially noticeable among startup job postings over the last 5 years where Z is programmer and X is either manager or ops (including the sub-specialty of DBA). How do someone even know they need an X if no X exists in their world? How we talk about things, especially to newer entrants into the industry matters. We should care.
  - DanielBMarkham 8y ago
    I apologize. I believe you may have misunderstood brevity for cynicism.These are systemic problems. There are no bad actors and everybody means well. I came to HN because it was supposed to be a place to learn about how startups work. I'm still here years later. One of the things I learned is that you let the market pull your startup. You can't push it. In other words, you don't know when trying to make something people want where this is going to lead you. Instead you interact with the folks you're trying to help and that interaction drives the things you do. There is much wisdom here. The other major thing I've learned in this area, from my own work with tech groups instead of HN, is that people like doing what people like doing. That is, given their druthers, people will always drift back to doing certain types of things. Like making reports? I'll bet you we can take you out of this job, put you somewhere else in a completely new surrounding -- and in a few years you'll be doing reports. It's what you like doing. We tech folks are really smart people, so we've managed to take everything we've touched, split it into smaller pieces, and make them complicated. It's what we like doing. Over many years, this means that any significant tech effort contains dozens of skillsets, all of which can be very complex. This number continues increasing. So with limited resources, as a small org or startup, you're faced with either letting the job drive out what skills you have to learn/use -- or not getting the work done. In larger companies, you can have the illusion that somehow you just need to grow enough experts. Small efforts can't do this. >>How do someone even know they need an X if no X exists in their world? Because X is a skill, not a role. If you transition from "jobs require these roles" to "jobs require these skills", and you let the problem drive your learning and adaptation, it all works out. If not? Overhead and friction increase as the required number of people increase, leading quickly to very slow projects. Everybody gets a role where they do what they want, but it's at the cost of focusing on the value instead of the employees. We naturally tend to view tech development backwards from what it actually is. So good people, doing their best to help folks, end up creating interwoven problematic nomenclatures, policies, and systems. Hopefully that sounds less cynical.