7 ms·

Currently working at a place that considers itself 'flat' I can say that it's one of the most confusing things ever, and the management tries to continually tel

by Sleaker 11y ago

Currently working at a place that considers itself 'flat' I can say that it's one of the most confusing things ever, and the management tries to continually tell me that it's such a great thing that everyone can take ownership of things themselves. It's a bunch of bull really, it just means no one has to take responsibility for failures to meet goals, there's no pressure to meet deadline and there's no actual ownership of product. This article hits all the points on the head about said flat structures, and how they don't work at all. They breed distrust, and resentment toward management because of an apparent (or real) lack of defining what's expected.

Ntrails 11y ago
Whilst I don't doubt your experience - your anecdote doesn't mean that there can never be a functional "flat" structure for a business and that any attempt to implement such a thing will destroy your company. I don't really think the article comes close to showing that either, but that's just an opinion.
tonecluster 11y ago
I have also found that the flatness fails quickly when the loudest, most aggressive, least-respectful-of-authority, best-dev-in-the-room type takes the (de-facto) leadership position, bullying others who challenge him. Schoolyard stuff, to be sure, and since most people don't like conflict for extended periods of time, you end up with a local "leader" (scare quotes intended) despite the intention to remain flat. It's the "rock star dev who's also a jerk", and eventually it creates chaos.
- hodwik 11y ago
  I actually think that's where flatness works best. Rather than being whoever can kiss the most ass and not upset the boss (the usual system), a flat system ends up being a battle for leadership which puts the smart and commanding at the top. "Rock star dev who's also a jerk" is who should be the boss.
  - jacques_chester 11y ago
    Where I work we have a role called "project anchor". It comes with no extra pay, no special perks, no particular enumerated powers. The anchor does not determine product features or direction, that's the product manager's role. The anchor doesn't hire, fire, reward or punish other engineers, that's the engineering manager's role. The anchor isn't necessarily the strongest engineer on the project, either. Anchors are mostly there to break ties and hold project context over a longer time frame. A founding anchor has a strong influence on the project's technical direction, but it's not a fiat power. You still need to discuss it with your peers. And it works pretty well, because the only reason you get asked to anchor is due to the feedback of your peers. Then again, our hiring process has a notorious bias against rockstar jerks.
    - mattip 11y ago
      Is there more info around about this style of project management? My google-foo is not getting any hits
      - jacques_chester 11y ago
        I work for Pivotal Labs. Our starting point is XP for engineering, Lean for design and product management. Daily standup, weekly IPM, weekly retro. Lots of people know us mostly for Pivotal Tracker, which is built to support our daily and weekly workflow. On any given engagement, we always argue for a minimum team of one product manager, one designer, two engineers. We used to be a purely engineering shop, but (before my time) the thinking grew to include all three roles in each project. Previously anchors were also de facto product managers, which is a tricky and exhausting doubling-up of duties. When this happens now, we call it "super-anchoring" and it's seen as a project smell. I've had to act as a super-anchor once or twice; it's how I learnt that having a separate product management role is essential to a healthy project. I like how we work. As an engineer I trust product managers to worry about what to build next and why, I trust designers to be across the user's needs and UX flow and conceptualisation. They trust me to pick a simple, robust engineering solution without gold-plating. Anyone can give input, of course. I've had PMs make great engineering suggestions. I've seen engineers with UX breakthroughs. Engineers in an IPM ask all sorts of fiddly questions that will typically lead to product changes. We ultimately own our own roles and get final say on them. It works because it's built on mutual trust and respect.
- rmc 11y ago
  Sounds like "The Tyranny of Structurelessness"

by Sleaker 11y ago

Ntrails 11y ago

Whilst I don't doubt your experience - your anecdote doesn't mean that there can never be a functional "flat" structure for a business and that any attempt to implement such a thing will destroy your company. I don't really think the article comes close to showing that either, but that's just an opinion.

tonecluster 11y ago

I have also found that the flatness fails quickly when the loudest, most aggressive, least-respectful-of-authority, best-dev-in-the-room type takes the (de-facto) leadership position, bullying others who challenge him. Schoolyard stuff, to be sure, and since most people don't like conflict for extended periods of time, you end up with a local "leader" (scare quotes intended) despite the intention to remain flat. It's the "rock star dev who's also a jerk", and eventually it creates chaos.

hodwik 11y ago
I actually think that's where flatness works best. Rather than being whoever can kiss the most ass and not upset the boss (the usual system), a flat system ends up being a battle for leadership which puts the smart and commanding at the top. "Rock star dev who's also a jerk" is who should be the boss.
- jacques_chester 11y ago
  Where I work we have a role called "project anchor". It comes with no extra pay, no special perks, no particular enumerated powers. The anchor does not determine product features or direction, that's the product manager's role. The anchor doesn't hire, fire, reward or punish other engineers, that's the engineering manager's role. The anchor isn't necessarily the strongest engineer on the project, either. Anchors are mostly there to break ties and hold project context over a longer time frame. A founding anchor has a strong influence on the project's technical direction, but it's not a fiat power. You still need to discuss it with your peers. And it works pretty well, because the only reason you get asked to anchor is due to the feedback of your peers. Then again, our hiring process has a notorious bias against rockstar jerks.
  - mattip 11y ago
    Is there more info around about this style of project management? My google-foo is not getting any hits
    - jacques_chester 11y ago
      I work for Pivotal Labs. Our starting point is XP for engineering, Lean for design and product management. Daily standup, weekly IPM, weekly retro. Lots of people know us mostly for Pivotal Tracker, which is built to support our daily and weekly workflow. On any given engagement, we always argue for a minimum team of one product manager, one designer, two engineers. We used to be a purely engineering shop, but (before my time) the thinking grew to include all three roles in each project. Previously anchors were also de facto product managers, which is a tricky and exhausting doubling-up of duties. When this happens now, we call it "super-anchoring" and it's seen as a project smell. I've had to act as a super-anchor once or twice; it's how I learnt that having a separate product management role is essential to a healthy project. I like how we work. As an engineer I trust product managers to worry about what to build next and why, I trust designers to be across the user's needs and UX flow and conceptualisation. They trust me to pick a simple, robust engineering solution without gold-plating. Anyone can give input, of course. I've had PMs make great engineering suggestions. I've seen engineers with UX breakthroughs. Engineers in an IPM ask all sorts of fiddly questions that will typically lead to product changes. We ultimately own our own roles and get final say on them. It works because it's built on mutual trust and respect.
rmc 11y ago
Sounds like "The Tyranny of Structurelessness"