{"id":55954,"date":"2019-07-19T12:00:42","date_gmt":"2019-07-19T16:00:42","guid":{"rendered":"https:\/\/www.wework.com\/ideas\/?p=55954"},"modified":"2020-09-03T05:53:01","modified_gmt":"2020-09-03T09:53:01","slug":"six-ways-to-collaborate-effectively-across-tech-teams","status":"publish","type":"post","link":"https:\/\/www.wework.com\/ideas\/professional-development\/creativity-culture\/six-ways-to-collaborate-effectively-across-tech-teams","title":{"rendered":"Six ways to collaborate effectively across tech teams"},"content":{"rendered":"\n

As roles in technology expand, how do companies make sure their teams are communicating clearly\u2014especially when job functions are seemingly more and more disparate? That was the question of the evening at Flatiron\u2019s inaugural \u201cMany Roles in Tech\u201d panel at WeWork Westview<\/a> in Austin.<\/p>\n\n\n\n

Nadav Cornberg, VP of software engineering at The Guild, an online travel-concierge service, moderated the lively discussion between a front-end developer, software engineer, IT manager, designer, and security analyst\/data scientist from various leading technology companies. They shared the best ways they\u2019ve found to facilitate great work across their fields.<\/p>\n\n\n\n

Stop \u201cthrowing things over walls\u201d<\/strong><\/h2>\n\n\n\n

Cornberg stressed the importance of getting as many people involved from as many different disciplines together as early as possible. \u201cSometimes you\u2019ll see engineers giving great ideas to design and vice versa,\u201d he said. \u201cOrganizations that do that are the ones [that] have the best user experience.\u201d<\/p>\n\n\n\n

As recently as a few years ago, \u201cdesigners would [typically] sit in a room, build something, and throw it over a wall,” said Alex Simmon, a senior designer at software company Pivotal. These days, Simmon talks daily to product managers, external and internal stakeholders, and the client developer. \u201cWe\u2019ll decide what problem we want to solve, and then every day we\u2019ll kind of see what tiny little things we can do to test that,\u201d she explained. \u201cWe\u2019re trying to make sure we don\u2019t sit in a room for six months and build the wrong thing.\u201d  <\/p>\n\n\n\n

Andrea Cardona, a front-end developer at IBM, emphasized that it\u2019s on every team member to make sure that happens. \u201cIf you\u2019re working to design something and you\u2019re purely on a developer team, say, \u2018Hey, where are my UX designers? Where are the project managers?\u2019\u201d<\/p>\n\n\n\n\n\n

Fix things as you go<\/strong><\/h2>\n\n\n\n

It may not be his natural instinct, but Bill Fienberg, a senior software engineer at Kazoo, fixes code incrementally to keep things running smoothly. \u201cI often want to fix everything before I do anything,\u201d he said. \u201cBut if I can develop that habit of fixing things as I go, it will at least be trending in the right direction.\u201d His technique not only improves the product but helps keep track of changes. \u201cIf \u2026 one person fixes everything in one request, then when people are reviewing that code, it\u2019s this monstrosity of a request; it\u2019s 100 lines long and we don\u2019t know what changed and why. If we can split that up, we can still \u2026 make the code better, but at the same time we relieve some of that burden on the code reviewer.\u201d<\/p>\n\n\n\n

Respect one another\u2019s process<\/strong><\/h2>\n\n\n\n

On any long-term project, priorities can change. But having an understanding of the demands of coworkers\u2019 unique roles can create more efficient work. \u201cSwitching context comes with cost,\u201d Fienberg said. \u201cReading code is like reading a chapter of a really weird book. If you get interrupted, you can\u2019t just pick up on where you left off.\u201d <\/p>\n\n\n\n

Fienberg, who recently moved into a team-lead position, explained that his schedule as a manager looks very different from his schedule as a maker or individual contributor. As a manager, he\u2019s able to divide his day into 15-, 30- or 45-minute increments to talk about things, and that\u2019s considered progress. But as a maker, he explained, \u201cit might take me two to four hours to really make any progress. I can\u2019t piecemeal that into 30- to 45-minute chunks.\u201d<\/p>\n\n\n\n

Use the right communication for the moment<\/strong><\/h2>\n\n\n\n

\u201cJust because you sit next to someone, it doesn\u2019t mean tapping them on the shoulder is the best way to communicate with them,\u201d said Fienberg, \u201cIf they have their headphones on it may be their way of saying, \u2018Hey, Slack me, I\u2019m in the middle of something.\u2019\u201d <\/p>\n\n\n\n

In other situations, Fienberg and Sam Oyeleye, a data scientist and security analyst at WeWork enterprise member Box, agree that asking questions publicly can often save a whole lot of time. \u201cIf there\u2019s a problem that everyone runs into in their first week, and it gets solved in a direct message, that\u2019s lost to everyone,\u201d said Fienberg. \u201cIf it\u2019s something that can be public and it goes in a public channel, then it creates a service.\u201d<\/p>\n\n\n\n

Use as much data as possible<\/strong><\/h2>\n\n\n\n

Often, the easiest way to resolve conflict is to just test it, Simmon said. When her team is at odds with stakeholders on next steps, they might say: \u201c\u2018Cool, this feature is going to take us three weeks to build, or this many dollars\u2014are we all willing to place this bet?\u2019 Or we can talk to a user in an hour-and-a-half and see what they say.\u201d<\/p>\n\n\n\n

Speak multiple languages<\/strong><\/h2>\n\n\n\n

Knowing the language of other teams can help you communicate better. \u201cPut yourself in their shoes: \u2018What would they ask me? What would they want?\u2019\u201d said LaDeitra Lee, a senior IT manager at Charles Schwab. Fienberg offered an example: \u201cIf I\u2019m trying to communicate to a decision-maker why we should prioritize something, their language may not be, \u2018This code isn\u2019t dry,\u2019\u201d he explained. \u201cBut if you say, \u2018We\u2019re using a library with a security vulnerability,\u2019 or if we say, \u2018This isn\u2019t accessible,\u2019 they might get it.\u201d<\/p>\n\n\n\n

Interested in changing your career, or learning new tech skills? Check out <\/em>Flatiron School<\/em><\/a> to learn more about our online and on-campus courses, as well as our scholarship opportunities. <\/em><\/p>\n\n\n