4 ms·

> In seating, we mix engineering teams with non-engineering teams In my experience this is a huge productivity killer for engineering teams. No, sitting us d

by diek 9y ago

> In seating, we mix engineering teams with non-engineering teams In my experience this is a huge productivity killer for engineering teams. No, sitting us down next to the recruiting guy doesn't make the recruiter better at technology or the engineers better at understanding recruiting. It mostly just makes us hate the person who talks on the phone all day while we're trying to work.

c0nfused 9y ago
I think it depends on the industry and needs of the company. As an example, In video games this is used as a way to get a feature shipped. Plop a bunch of artists with a coder or two and a couple of QA guys and roll a feature together. It cuts communications time, keeps everyone focused, and as long as your feature is encapsulated nicely it should merge back cleanly into main in a few days. If you are just applying a blender to the org chart it isn't going to be a great choice. However, something like putting a developer within ear shot of Technical Support isn't always a bad idea.
- sillysaurus3 9y ago
  As an example, In video games this is used as a way to get a feature shipped. Plop a bunch of artists with a coder or two and a couple of QA guys and roll a feature together. It cuts communications time, keeps everyone focused, and as long as your feature is encapsulated nicely it should merge back cleanly into main in a few days. At the studios I worked at, these were called "meetings."
- pseudalopex 9y ago
  Cross-functional feature teams are something entirely different. Having a developer spend a day with the support team every so often is a great idea. Putting them within earshot just leads to the developers wearing headphones all day.
lojack 9y ago
Agreed. I sit next to a manager who is on the phone all day and all I can think is how much I wish he had his own office so I could get actual work done.
- maerF0x0 9y ago
  ear plugs have been the cheapest upgrade to my productivity. Sadly the social stigma means it may also undermine my own career trajectory. yay.
  - adjkant 9y ago
    Have you considered some good headphones with no music playing? Less stigma, same functionality.
    - mctx 9y ago
      I find that even noise cancelling headphones don't help drown out nearby conversations - I listen to Apple's Chill radio and use Noizio when I really need to focus.
      - jessriedel 9y ago
        You might also consider just using brown noise. I find it very useful.
        xcasperx 9y ago
        I throw rain on. If someone's straight yelling it won't help. For just general background convo noise, it works well
      - eshvk 9y ago
        Noise cancelling headphones don't really drown out conversations. You should get in-ear headphones.
        raspasov 9y ago
        Bose QC25 and QC35 really do though at mid level volume. You see people opening their mouths but you hear no voices.
prawn 9y ago
Wouldn't they be implying the non-engineers to be designers or testers rather than staff who need to make a lot of phone calls? I own/tenant a small co-working space and we try to filter out the types of freelancers and small businesses who need to take or make an unreasonable amount of calls that might distract others. Surely Stripe would have considered this sort of basic open office stuff.
- pseudalopex 9y ago
  You'd be surprised how many companies don't consider it.
hibikir 9y ago
In mine, it's been just the opposite: I've been working professionally for 16 years, and extended contact with non developers always helped. It didn't help me code faster, but it helped me code the right things, which is far more important than speed. In my first job, We had separate infrastructure and development. Infrastructure had DBAs, Sys admins and specialists in random tooling, but nobody could code to save their lives. I managed to get myself sitting with infra, and not only I learned things that back then they'd not share with application programmers, but I could use my programming skills to deal with a lot of low hanging fruit. Today nobody in their right mind would train someone to know SQL and DB administration and know no general programming at all, because of how much power you lose by not coding... but there, it was a life saver. At my next job I spent time programming from the back room of a retail store, stints in warehouses, and even with accounting. Then I could not just write code for them that made more sense, but even keep their goals in mind when working at a project with someone else. At another job the company was doing heavy waterfall. The project I landed on had been going on for 2 years, but no developer had EVER talked to anyone in the user's department. It all went through business analysts and project leads. Needles to say, the internals of the system had nothing to do with the user's mental model, and the business analysts, which had no special training, were designing screens and answering questions, while they were badly informed. I used a fortuitous maternity leave by one of the leads to just spend a few days a week in another campus: One that had people that were not my users, but understood them far better than any analyst I had, and broke all protocol, redesigning some pieces of the system. When management came back, I told them that I wanted to show my changes to users, and they were ecstatic, as the changes were right on. A month later, my team was embedded with real business units, and management decided that, since we had better results than anyone else, that we could get away with not doing waterfall. All because I actually cared about what other people in the company were doing. So sure, if you are sitting next to recruiting in an open office, and recruiting doesn't go into any closed booths to take calls, it's probably not so productive, but I have never worked at a place where getting to know what other departments are doing didn't multiply my chances of having more impact.
deleted 9y ago
[deleted]
kaishiro 9y ago
This is a real tough one for me. I'm a developer, and I love development. I'd do it even if I wasn't getting paid. That being said, I'm comfortable saying that I'm probably not a great developer. I try hard, I enjoy working with teams, I love producing, but I've worked with a few actually great developers and I'm pretty sure I'm not them. However, what I think I am great at, is making non-developers understand what it is I'm doing. I think this is a real skill, undervalued on a lot of teams. For this reason I actually enjoy and am more productive sitting next to the sales/AM/PM cohort. I like being tossed questions re: scope/SOWs because I know it'll pay dividends down the line when the team knows that a number was vetted before going out the door. I like it when I can explain why it's not a quick job, and they understand, and more importantly they can make the client understand. But I also understand that this isn't a role a lot of devs are comfortable filling - and they really, really shouldn't be forced to. Now, you could argue none of this would be necessary if the team/agency/company had proper systems in place - and you'd be right. But I've yet to work for an agency that had it all figured out.

by diek 9y ago

c0nfused 9y ago

I think it depends on the industry and needs of the company. As an example, In video games this is used as a way to get a feature shipped. Plop a bunch of artists with a coder or two and a couple of QA guys and roll a feature together. It cuts communications time, keeps everyone focused, and as long as your feature is encapsulated nicely it should merge back cleanly into main in a few days. If you are just applying a blender to the org chart it isn't going to be a great choice. However, something like putting a developer within ear shot of Technical Support isn't always a bad idea.

sillysaurus3 9y ago
As an example, In video games this is used as a way to get a feature shipped. Plop a bunch of artists with a coder or two and a couple of QA guys and roll a feature together. It cuts communications time, keeps everyone focused, and as long as your feature is encapsulated nicely it should merge back cleanly into main in a few days. At the studios I worked at, these were called "meetings."
pseudalopex 9y ago
Cross-functional feature teams are something entirely different. Having a developer spend a day with the support team every so often is a great idea. Putting them within earshot just leads to the developers wearing headphones all day.

lojack 9y ago

Agreed. I sit next to a manager who is on the phone all day and all I can think is how much I wish he had his own office so I could get actual work done.

maerF0x0 9y ago
ear plugs have been the cheapest upgrade to my productivity. Sadly the social stigma means it may also undermine my own career trajectory. yay.
- adjkant 9y ago
  Have you considered some good headphones with no music playing? Less stigma, same functionality.
  - mctx 9y ago
    I find that even noise cancelling headphones don't help drown out nearby conversations - I listen to Apple's Chill radio and use Noizio when I really need to focus.
    - jessriedel 9y ago
      You might also consider just using brown noise. I find it very useful.
      - xcasperx 9y ago
        I throw rain on. If someone's straight yelling it won't help. For just general background convo noise, it works well
    - eshvk 9y ago
      Noise cancelling headphones don't really drown out conversations. You should get in-ear headphones.
      - raspasov 9y ago
        Bose QC25 and QC35 really do though at mid level volume. You see people opening their mouths but you hear no voices.

prawn 9y ago

Wouldn't they be implying the non-engineers to be designers or testers rather than staff who need to make a lot of phone calls? I own/tenant a small co-working space and we try to filter out the types of freelancers and small businesses who need to take or make an unreasonable amount of calls that might distract others. Surely Stripe would have considered this sort of basic open office stuff.

pseudalopex 9y ago
You'd be surprised how many companies don't consider it.

hibikir 9y ago

In mine, it's been just the opposite: I've been working professionally for 16 years, and extended contact with non developers always helped. It didn't help me code faster, but it helped me code the right things, which is far more important than speed. In my first job, We had separate infrastructure and development. Infrastructure had DBAs, Sys admins and specialists in random tooling, but nobody could code to save their lives. I managed to get myself sitting with infra, and not only I learned things that back then they'd not share with application programmers, but I could use my programming skills to deal with a lot of low hanging fruit. Today nobody in their right mind would train someone to know SQL and DB administration and know no general programming at all, because of how much power you lose by not coding... but there, it was a life saver. At my next job I spent time programming from the back room of a retail store, stints in warehouses, and even with accounting. Then I could not just write code for them that made more sense, but even keep their goals in mind when working at a project with someone else. At another job the company was doing heavy waterfall. The project I landed on had been going on for 2 years, but no developer had EVER talked to anyone in the user's department. It all went through business analysts and project leads. Needles to say, the internals of the system had nothing to do with the user's mental model, and the business analysts, which had no special training, were designing screens and answering questions, while they were badly informed. I used a fortuitous maternity leave by one of the leads to just spend a few days a week in another campus: One that had people that were not my users, but understood them far better than any analyst I had, and broke all protocol, redesigning some pieces of the system. When management came back, I told them that I wanted to show my changes to users, and they were ecstatic, as the changes were right on. A month later, my team was embedded with real business units, and management decided that, since we had better results than anyone else, that we could get away with not doing waterfall. All because I actually cared about what other people in the company were doing. So sure, if you are sitting next to recruiting in an open office, and recruiting doesn't go into any closed booths to take calls, it's probably not so productive, but I have never worked at a place where getting to know what other departments are doing didn't multiply my chances of having more impact.

deleted 9y ago

[deleted]

kaishiro 9y ago

This is a real tough one for me. I'm a developer, and I love development. I'd do it even if I wasn't getting paid. That being said, I'm comfortable saying that I'm probably not a great developer. I try hard, I enjoy working with teams, I love producing, but I've worked with a few actually great developers and I'm pretty sure I'm not them. However, what I think I am great at, is making non-developers understand what it is I'm doing. I think this is a real skill, undervalued on a lot of teams. For this reason I actually enjoy and am more productive sitting next to the sales/AM/PM cohort. I like being tossed questions re: scope/SOWs because I know it'll pay dividends down the line when the team knows that a number was vetted before going out the door. I like it when I can explain why it's not a quick job, and they understand, and more importantly they can make the client understand. But I also understand that this isn't a role a lot of devs are comfortable filling - and they really, really shouldn't be forced to. Now, you could argue none of this would be necessary if the team/agency/company had proper systems in place - and you'd be right. But I've yet to work for an agency that had it all figured out.