10 ms·

My personal experience has been that many of the engineers most in favor of flatland management are in fact most in need of good managers themselves. One of th

My personal experience has been that many of the engineers most in favor of flatland management are in fact most in need of good managers themselves. One of the biggest challenges for flatland-style organizations is getting technical people to focus on business objectives which tend to be non-fun. For software that includes fixing a lot of hard bugs and really delivering on features like complete documentation, monitoring, and good upgrades. (Disclaimer: I have been a manager about 2/3 of the time in my last few jobs. I'm an engineer currently.)

dboreham 10y ago
Exactly. Hard to make a kid clean and tidy their room (source: parent, also engineering manager for n decades..)
- pavlov 10y ago
  Do you work for one of those companies that hire only 22-year-olds who can answer irrelevant computer science questions on a whiteboard, and then you wonder why it's hard to get engineers excited about business goals rather than endless tinkering with algorithms and languages...?
  - hodgesrm 10y ago
    Actually my current company is pretty large and it's not like that at all. The technical people are by and large extremely good. And to your first question I have been through a few interviews with those 22-year-olds who asked about irrelevant CS questions. That's a good sign to avoid the company.
  - mwfunk 10y ago
    Age has little to do with it, it's more a combination of maturity, professionalism, intellect and talent. These things are correlated with age, but not as strongly as one might think. I've worked with 22-year old developers who had all of these qualities, and developers with 22 years of professional experience who didn't. It does tend to go the other way though. Even the best ones probably wouldn't flourish in a flat org though- that's not a knock against the developers, more the unsuitability of most software tasks to such a structure (or lack of it). On the other hand, I think there's a very strong correlation between people who think they would flourish in a flat org and people who wouldn't do well in one. The only people who might do all right are those who would join a flat org with great skepticism and trepidation, because they would be paranoid enough about things going off the rails that they would obsess over making sure that their own goals are set appropriately as well as the people around them. If you get rid of managers, essentially everyone becomes a manager of sorts and they need to really embrace the role to make it work.
    - pm90 10y ago
      > If you get rid of managers, essentially everyone becomes a manager of sorts and they need to really embrace the role to make it work. This. In my years of working in Software, I've dealt with managers, both good and bad. The best ones have without a doubt been those who took care that I had to attend as few meetings as possible, that my requirements for work were met, who were open to genuine conversation about my performance.
      - rpeden 10y ago
        In the corporate world, I've worked in both accounting and software development, and what you wrote describes good manager in both fields. Although I don't have much evidence (yet, but I'm doing some research), I suspect that the qualities that make up good managers (and bad ones) is fairly similar from one field to the next.
  - dboreham 10y ago
    I run my own companies so no, but I know what you mean. I however suspect that this runs deeper than just Google's hiring process: We're all (technical folk) steeped since we were 12 years old in a culture that says that solving tricky problems in the most elegant way is what gets you love. This way of thinking predates computers by thousands of years. I think this is the root of why you see everything slant towards cool trickery rather than solid engineering and working stuff. There is something of an age factor but only insofar as the more experienced people end up having this way of thinking partially beaten out of them by real life experiences and the benefit of a long time observing the "nons" in the world.
- amackera 10y ago
  Hard to believe but most of the engineers I've worked with were actually adults, and didn't need to be treated like children.
  - paulddraper 10y ago
    Life scales.
Animats 10y ago
That's a general problem with open source projects. It leads to being at version 0.9x forever, and bugs not getting fixed.
- dasmoth 10y ago
  Very much depends on the project. Staying at 0.9 can just mean having very high standards for 1.0.
Raphmedia 10y ago
> For software that includes fixing a lot of hard bugs and really delivering on features like complete documentation, monitoring, and good upgrades. That's exactly the kinds of things I wish that I could do. In my experience it's mostly managers that want you to push features without any documentation and filled with bugs.
- wnevets 10y ago
  Even if it isn't the managers themselves that personally want to skip those things, their boss wants the next feature.
  - xorblurb 10y ago
    Then they are useless. Send us the boss directly, will save a layer of communication. Problem is the boss wants a unique interlocutor, and one who says yes. Then if he is friendly enough, engineers will prefer to do a shitty job (rush "features" and even more bugs) rather than inconvenience their manager who already committed on behalf of the whole team.
    - wnevets 10y ago
      sounds like you want a flat structure.
      - m4x 10y ago
        Or they just want to cut out unnecessary layers. You don't really want an extra level between the group demanding the features and the group implementing them. Feedback about technical feasibility, time to implement et cetera really needs to go directly to the group demanding the feature, and their responses need to come directly back to the group implementing it. A competent middle man can help those two groups interact, but generally adding an extra middle layer reduces everybody's ability to function well.
  - majormajor 10y ago
    A major part of the art of the handwavey term "good" management at the technical-line-level-and-middle-management stage is exactly in that area of "selling the rest of the business on why this will take longer than it sounds" and "protecting the team's time to work on what the team needs to work on to continue to be able to deliver stuff fast." Good management means the team can keep working fast. Bad management means that three-to-five years later, someone has to come in and really put their foot down and say "if you want simple features to stop taking six months we have to take the time now." But to be able to sell that message outside the tech team at that point, you sorta have to be an external "fixer" - IME, it's hard to sell your own ability to clean up the mess if you're seen as part of who created it, sadly. Figuring out the difference between a place with good management and bad management if you're interviewing there can be tricky - but if they don't have tests, etc, and also can't tell you their plan to add them / why they're adding them now, that's probably a bad sign. Or ask them what they've shipped recently and how long it took - maybe easier to look for the symptoms than for specific process failings, since those could be wildly varied. EDIT: I love working in flat structures where the total relevant number of people to what I'm working on is under 15. Either a small startup or a truly independent sub-unit. But there are few worse environments than a flat structure where 30+ people feel like they should have a say in a given feature.
nitrogen 10y ago
On rare occasions it's the opposite, though; I've tried in some places (as a developer) to advocate for deeper business needs, but the development manager is totally focused on the easy and fun stuff. In that case a flat developer group would've had better long term results.
mathattack 10y ago
Yes. Similarly, I've also found that people who say "I'm too busy working to bother measuring what I'm doing" are the ones most in need of measurement. (Same with "Too busy to communicate" and "Too busy to meet") There are reasons for coordination and trust, otherwise 100% of the workforce would be independent contractors.
johngalt 10y ago
Flat orgs are an overreaction to the traditional top heavy big corp structures. Where each staff member is reporting to multiple unsynchronized management chains. Nothing is more frustrating that having to be caught in the middle of three managers who all disagree with what the priorities should be, and refuse to mediate it amongst themselves. Not to mention the infighting once your company is over 1000 people and you start having boss A demand all your time specifically to frustrate boss B's plans. All of the above is non-fun. I'll do all the boring documentation, monitoring and change control and say thank you. I'm not trying to be harsh on managers (I am one), but I can't blame people for overreacting.
ACow_Adonis 10y ago
Apologies, but it has to be said: in my professional experience, it's the management that stops technical people fixing bugs, completing documentation, fixing infrastructure, providing good upgrade paths, refactoring, etc.
LaurentVB 10y ago
Isn't it true then that: good manager > no manager > bad manager ?

dboreham 10y ago

Exactly. Hard to make a kid clean and tidy their room (source: parent, also engineering manager for n decades..)

pavlov 10y ago
Do you work for one of those companies that hire only 22-year-olds who can answer irrelevant computer science questions on a whiteboard, and then you wonder why it's hard to get engineers excited about business goals rather than endless tinkering with algorithms and languages...?
- hodgesrm 10y ago
  Actually my current company is pretty large and it's not like that at all. The technical people are by and large extremely good. And to your first question I have been through a few interviews with those 22-year-olds who asked about irrelevant CS questions. That's a good sign to avoid the company.
- mwfunk 10y ago
  Age has little to do with it, it's more a combination of maturity, professionalism, intellect and talent. These things are correlated with age, but not as strongly as one might think. I've worked with 22-year old developers who had all of these qualities, and developers with 22 years of professional experience who didn't. It does tend to go the other way though. Even the best ones probably wouldn't flourish in a flat org though- that's not a knock against the developers, more the unsuitability of most software tasks to such a structure (or lack of it). On the other hand, I think there's a very strong correlation between people who think they would flourish in a flat org and people who wouldn't do well in one. The only people who might do all right are those who would join a flat org with great skepticism and trepidation, because they would be paranoid enough about things going off the rails that they would obsess over making sure that their own goals are set appropriately as well as the people around them. If you get rid of managers, essentially everyone becomes a manager of sorts and they need to really embrace the role to make it work.
  - pm90 10y ago
    > If you get rid of managers, essentially everyone becomes a manager of sorts and they need to really embrace the role to make it work. This. In my years of working in Software, I've dealt with managers, both good and bad. The best ones have without a doubt been those who took care that I had to attend as few meetings as possible, that my requirements for work were met, who were open to genuine conversation about my performance.
    - rpeden 10y ago
      In the corporate world, I've worked in both accounting and software development, and what you wrote describes good manager in both fields. Although I don't have much evidence (yet, but I'm doing some research), I suspect that the qualities that make up good managers (and bad ones) is fairly similar from one field to the next.
- dboreham 10y ago
  I run my own companies so no, but I know what you mean. I however suspect that this runs deeper than just Google's hiring process: We're all (technical folk) steeped since we were 12 years old in a culture that says that solving tricky problems in the most elegant way is what gets you love. This way of thinking predates computers by thousands of years. I think this is the root of why you see everything slant towards cool trickery rather than solid engineering and working stuff. There is something of an age factor but only insofar as the more experienced people end up having this way of thinking partially beaten out of them by real life experiences and the benefit of a long time observing the "nons" in the world.
amackera 10y ago
Hard to believe but most of the engineers I've worked with were actually adults, and didn't need to be treated like children.
- paulddraper 10y ago
  Life scales.

Animats 10y ago

That's a general problem with open source projects. It leads to being at version 0.9x forever, and bugs not getting fixed.

dasmoth 10y ago
Very much depends on the project. Staying at 0.9 can just mean having very high standards for 1.0.

Raphmedia 10y ago

> For software that includes fixing a lot of hard bugs and really delivering on features like complete documentation, monitoring, and good upgrades. That's exactly the kinds of things I wish that I could do. In my experience it's mostly managers that want you to push features without any documentation and filled with bugs.

wnevets 10y ago
Even if it isn't the managers themselves that personally want to skip those things, their boss wants the next feature.
- xorblurb 10y ago
  Then they are useless. Send us the boss directly, will save a layer of communication. Problem is the boss wants a unique interlocutor, and one who says yes. Then if he is friendly enough, engineers will prefer to do a shitty job (rush "features" and even more bugs) rather than inconvenience their manager who already committed on behalf of the whole team.
  - wnevets 10y ago
    sounds like you want a flat structure.
    - m4x 10y ago
      Or they just want to cut out unnecessary layers. You don't really want an extra level between the group demanding the features and the group implementing them. Feedback about technical feasibility, time to implement et cetera really needs to go directly to the group demanding the feature, and their responses need to come directly back to the group implementing it. A competent middle man can help those two groups interact, but generally adding an extra middle layer reduces everybody's ability to function well.
- majormajor 10y ago
  A major part of the art of the handwavey term "good" management at the technical-line-level-and-middle-management stage is exactly in that area of "selling the rest of the business on why this will take longer than it sounds" and "protecting the team's time to work on what the team needs to work on to continue to be able to deliver stuff fast." Good management means the team can keep working fast. Bad management means that three-to-five years later, someone has to come in and really put their foot down and say "if you want simple features to stop taking six months we have to take the time now." But to be able to sell that message outside the tech team at that point, you sorta have to be an external "fixer" - IME, it's hard to sell your own ability to clean up the mess if you're seen as part of who created it, sadly. Figuring out the difference between a place with good management and bad management if you're interviewing there can be tricky - but if they don't have tests, etc, and also can't tell you their plan to add them / why they're adding them now, that's probably a bad sign. Or ask them what they've shipped recently and how long it took - maybe easier to look for the symptoms than for specific process failings, since those could be wildly varied. EDIT: I love working in flat structures where the total relevant number of people to what I'm working on is under 15. Either a small startup or a truly independent sub-unit. But there are few worse environments than a flat structure where 30+ people feel like they should have a say in a given feature.

nitrogen 10y ago

On rare occasions it's the opposite, though; I've tried in some places (as a developer) to advocate for deeper business needs, but the development manager is totally focused on the easy and fun stuff. In that case a flat developer group would've had better long term results.

mathattack 10y ago

Yes. Similarly, I've also found that people who say "I'm too busy working to bother measuring what I'm doing" are the ones most in need of measurement. (Same with "Too busy to communicate" and "Too busy to meet") There are reasons for coordination and trust, otherwise 100% of the workforce would be independent contractors.

johngalt 10y ago

Flat orgs are an overreaction to the traditional top heavy big corp structures. Where each staff member is reporting to multiple unsynchronized management chains. Nothing is more frustrating that having to be caught in the middle of three managers who all disagree with what the priorities should be, and refuse to mediate it amongst themselves. Not to mention the infighting once your company is over 1000 people and you start having boss A demand all your time specifically to frustrate boss B's plans. All of the above is non-fun. I'll do all the boring documentation, monitoring and change control and say thank you. I'm not trying to be harsh on managers (I am one), but I can't blame people for overreacting.

ACow_Adonis 10y ago

Apologies, but it has to be said: in my professional experience, it's the management that stops technical people fixing bugs, completing documentation, fixing infrastructure, providing good upgrade paths, refactoring, etc.

LaurentVB 10y ago

Isn't it true then that: good manager > no manager > bad manager ?