📝

How to Optimise Collaboration Between Tech Teams and Wider Business?

QUESTIONS

Some of the questions we’ll touch upon:

  • To what extent (to be most effective) do you feel collaboration between technology teams and the wider business should occur? Can there be a case of too much / too little collaboration?
    • Is there a need for a mediary between tech and the business?
    • How do you develop cross-functional empathy and understanding?
  • How have you fostered greater collaboration between technology teams and the wider business within your business?
    • Operations and tech teams work in different ways - how do you address different communication styles?
  • How have you found achieving alignment / agency to company objectives / values with technology teams?
    • Specifically around setting realistic expectations about tech dev speed and sales teams!
    • Key concepts that should be known across the entire business
    • How to ensure developers / tech teams are brought into the end product / business strategy through strong comms and processes?
  • What traits would you describe as being associated with poor collaboration? What implications have you seen as a result?
  • What have been the key hurdles you've had to overcome to foster greater collaboration?
    • Cross team collaboration while remote is already saturated with meetings. A framework/matrix?
    • Our communication can often fall down with EPD (we group them as engineering, product and design) when they don't feel they need to get the input from Ops teams, especially customer facing such as Support (who know our customers inside out) - anyone managed to turn this around successfully, if so what did you do?
    • What's the most effective way of 'building bridges' between Tech/Product and Operations teams? How do we ensure the Operations voice is heard in a Product led company?
    • As we've gone remote, how are people leaning in to their cross functional meetings and how many do they have? how often? How are people bringing in more junior colleagues into the discussion?
    • How have people found team dynamics changing as the moved from a team of <10 where 70% of the team are engineers to 15-20 when other functions are starting to get build out and organisational complexity increases. What have you done to maintain alignment?
    • Particularly How to balance the wider business culture with a specific and strong Engineering Culture.
  • What methods have you found most effective in driving greater collaboration? What have you found least effective or simply not worked?
    • How can we run teamwide meetings to ensure collaboration?
    • How do we get all tech team members to participate?
  • What are the characteristics of CTOs leading high performing technology teams within startups / scale ups?
  • What ops stack / software combos have you used to foster great collaboration and promote transparency?
    • How can tech help with optimising collaboration?

NOTES

Team Mike, Marie, Stevan, Leo, Thomas, Astrid

  • In smaller teams when the culture is right it doesn’t seem to be an issue, but how do you scale the team and the communication. What are best practices and frameworks
  • Challenge in collaboration when the new hires are only online and you’ve not met them in rea life
  • How can you encourage communication when there’s not natural flow in information exchange
  • The other teams have grown faster than the dev team, so the dev team is having a lot of influx of demands, how can the other teams collaborate so they don’t put too much pressure on the dev team.
  • With scaling in mind, how do you ensure that teams keep communicating?
  • At learnerbly they did a virtual Hackathon, when things are remote people feel forced into interactions rather than feeling like it naturally flows. There’s a reason to be together and to collaborate on. Especially for introverts. It’s also been well received by other teams. It’s great, but it takes a lot of time.
    • Hackathons used to be tech in the past, how do you involved the whole team?
      • Cross team groups and everyone comes from another team so they are encouraged to talk with one another
    • How do you ensure that the benefits from the event sticks two months later still?
      • Donut coffees - but it’s expensive and doesn’t scale well as the team grows. https://yen.fm/tools/
      • Now also, with onboarding, it’s important to have a group chat with people from different teams 4 by 4 to make it feels less awkward
    • There are also working groups, on Friday people can work together on other projects that they’re passionate about.
    • It’s important to do retros on them to show if it’s successful but also productive for the company
    • There’s a lot of pressure on doing work and on top of that social interaction. Leadership should be thinking about using social time as also “productive” this would happen in an office, but online it feels like people are doing things they shouldn’t be doing.
      • Morning standup has 10 minutes of allocated social time
      • It’s difficult to find time in the day, it’s okay to set time aside in the evenings or for formal socials, but it’s difficult to encourage during the day.
      • Giving people vouchers for food and they can eat together - The Zoom rooms are set up so that different teams have been mixed up
  • Encourage your team to set up 1:1s with key stakeholders in other teams, not to find out things, but generally to create a relationship between the two teams and naturally interesting info will flow.
  • Make sure people know that they can stay behind after a meeting for some chatter, encourage to partake in conversation without feeling guilty.
  • Delayed features and performance related issues and how that impacts the teams
    • There’s a lack of visibility by other teams on where the product and engineering teams are and how to anticipate the challenges that this will bring
  • What are the problems that come from poor communications
    • Delayed features
    • Wrong features
    • Have a half hour catch-up with the different dev/engineering teams to see what’s going on and also encourage people to talk to each other to ensure that the right connections are made between team members to build the right features and so everyone fully understands what the problem is.
    • The release time isn’t discussed and then the feature is live before the team is made aware and collaborative polishing could have been useful.
  • Communication styles, ops speak vs dev speak
    • A more sensitive communication vs more straightforward, how do you make your team aware that the styles are different and that there aren’t bad feelings over it?
    • If people don’t have conversations then as a manager you feel like you’re constantly mopping up between people and interactions that went wrong. You have to allow people to go into the wild and make their own experiences, but setting the expectations with your team is also important. What can they expect from a certain person’s communication style? E.g. the founder is blunt but they can take feedback well, so it’s okay to talk back.
    • How do you balance the line between managing expectations vs making it sound gossipy. If you talk about a person with respect and admiration you shouldn’t be afraid of that being an issue.
    • Roll out Slack etiquette every couple of months to ensure people have the best practice. How do you hold people accountable? Manager or peer feedback?
  • Having one key person to talk to about the team, there are many positives, but it creates a risky chain because if that person isn’t in, has a bad day, might have people they don’t get along with … it can create dangerous situations that we might be initially unaware of.
  • Bringing in type 1 and type 2 thinking based off of Thinking fast and slow into conversation. It helps you recognise your instinct, it helps you communicate in terms that everyone understands and it shows that people are trying hard to communicate in the best way.
  • Alignment, how do you ensure that what your devs are working on is what the business needs
    • You look at your team’s aspirations vs company goals and you ensure that you know if the roadmap is respected
    • How do you stop building features to land a client and that more short term visions
    • Depending on where you stand of a company, you will evolve beyond the short term visions. A lot of time it’s tied in with funding rounds.
    • Having company goals 1 or 2, it’s up to you as a manager to enforce those goals, but it’s much easier post acquisition since the runway is less of an issue.
    • How can you hack and mvp a feature and see if with people and process you can bring a client/customer along the ride and see if other customers also benefit the feature

Group 1 - Kirsty, Alva, Katya, Alex, Cameo, Victoria

  • Have everyone in the team to interact with your customers (Alva)
    • CEO, engineers, etc. working on support teams and seeing the issues from the get go
  • Quantifying the impact - positive or negative - is so important to
    • Everyone should see the numbers on Zendesk
    • Try to articulate that it’s great that we can get more customers on board by adding this feature; but we won’t be able to scale if we don’t solve this problem
    • I.e. this is the support cost, this is the dev cost…
    • Bringing up the money cost can be a bit shocking for the first time.
  • Communicate the numbers (e.g. support, etc.) to tech teams on a frequent basis (Slack integration) - Alva
  • Describe an issue from a customer perspective…
    • Write user stories?
  • Have a support engineer on the support team
    • They will pick up the issues and get the insight this way
    • Not always they communicate that problem back to the core engineering team very well
  • Spend a lot of time educating others how to communicate with each other
    • How you teach a group of designers to think like engineers? Embedding people in different teams as representatives…
  • Pair people up so people who don’t know the product very well can turn to someone who does
    • Also get people to speak with each other
    • Having a specific bot to pair people up has worked really well
  • Cross-functional retros to stop something from happening again
    • It should be repeatable to sync in so that it doesn’t become a pointless exercise
  • Make it clear that the impact is on the customer facing teams, NOT the engineers (Kirsty)
  • Differences between sales, customer and product focused organisations (and this might shift over time)

Team James, Nick, Yumika, Marta, Micky and Katie

  • Importance of the product manager who interlinks the team. They can make a difference how the tech team interacts with the rest of the business.
  • Biggest gap between tech and sales - ensuring to build a link between the two with forming closer relationships by way of i.e. social stuff.
  • Show & tell and demos - tech teams proactively showcasing where they’re at, what features they’re launching and why - at a regular intervals
  • Slack etiquette and transparency. Building trust between the teams. All channels being open, everyone able to jump in and out, creating transparency.
  • CTO style / character and how this impacts the dynamics. How can you work around that character?
  • OKRs and goal setting; ability to find alignment around goals and point people to THIS being the goal. Focus on outcome vs output.
  • Solution and problem space - everyone wants problems!

Takeaways / Summary

  • Other teams sitting on support team for a few hours per week
  • Quantifying the impact - can you link it back to revenue, number of tickets, etc...you need to know your audience and who to talk to about the money (i.e. key stakeholders)
  • Having specialist Slack channels, buddy systems, etc.
  • Use agile template such as user stories to communicate to the tech team but have the product manager to teach the ops team how to do that (https://www.agilealliance.org/glossary/user-story-template/)
  • Tech teams want problems, not solutions. On our side we also feel that we can help with the solution and make sure that it’s done in the right way. Involve the tech team from the very beginning.
  • Cross-functional retros (or teams, depending on how big the business is) - solving the problem together with different stakeholders. Making it clear and being honest with relevant stakeholders.
  • If not the right thing is build, the impact is on the customer facing teams, not the engineering teams - we need to make sure that tech sees this more clearly.
  • Using templates and problem statements, utilising categories, etc.
  • --
  • Improving the communication by way of organising virtual hackathons
  • Good to encourage people from your team to have 121s with other stakeholders in other teams
  • Communication styles and managing expectations; i.e. “this is what you can expect from this person”
  • Rolling out Slack etiquette for some basic dos and dont’s
  • Alignment: teams wanting to build things vs business needs. Before you build a feature, ask a client if they’re happy to “hack” the problem with people and process.