While I like to think that all of us at Hinge are perfectly aligned towards the same goals, in reality if you take a mindreading machine and eavesdrop on the internal monologues of my team members, you might overhear some... misalignment:

  • "Oh please for the love of god not another meeting, just leave me alone so I can finish building this feature" -Engineer

  • "We really need to have another meeting to sync on what's left to build this feature" -Engineering manager


  • "We're not moving fast enough, we need to focus more on speed so we can get this out to our users" -Product manager

  • "We're moving too fast, we need to focus more on quality, let me add some more tests" -Engineer


  • "This open plan space is awesome! I can talk with my team all day!" -Engineer A

  • "I can't get any work done because my team won’t stop talking about obscure movie references!" -Engineer B

You can boil each of these issues down to their emotional core: different team members’ needs cause friction and frustration. Together, these issues were compounding to a larger sense of negativity and lack of momentum. Deadlines were slipping, tempers were flaring, engineers were losing sleep and pulling their hair out, and some were resorting to elaborate dance-offs/arm wrestling/fisticuffs in the office to resolve disagreements.

I've seen versions of these misalignments on nearly every engineering team I've been part of. As an engineering leader, my job is to serve my team and help make them as effective as possible.


As I saw these misalignments emerge at Hinge, my first instinct was to act decisively and fix with some heavy-handed top-down management. The team doesn't like long meetings?  I’ll institute shorter meetings. Our product team wants to move faster?  I'll develop a project plan myself in a backroom. The open plan space isn't working?  I'll buy everyone noise-cancelling headphones.

The fallacy with these top-down approaches, are that they make the assumption that I am smarter than my collective team, which is definitely not the case.

Instead, what I've been doing with my team at Hinge is little more than shining a light on these misalignments, and creating safe spaces to discuss the problems and possible solutions. My team are humble, invested, and positive, so all it takes is a bit of focus on a problem for a solution to emerge. We let process be implemented by those who practice it, rather than coming from top-down.

Whereas in 2009 you might have a “quick meeting” to discuss a problem (aka “let’s take this offline”), and in 2012 you might have created a “short Google Doc” to discuss and define a policy, in 2015 we have the glorious utility of Slack.


Slack allows us to quickly and easily spin up and segment discussions, invite the right people to the discussion, and lazily contribute based on our own urgency and workloads.

Some example Slack channels:

  • #ios-style-and-syntax: We expanded from 1 iOS engineer to 4 in a very short amount of time. Code reviews were derailing into larger disagreements over style (“doc notation instead of bracket notation!!!!!11”). Our iOS engineer Steve noticed this, and proposed separating style discussions out of code reviews, into a Slack channel.

  • #android-release-process (when to branch, when to create builds, when to merge back to master, where to upload builds). After gathering feedback from his peers, our Android engineer Jason took the lead on Google Doc, and once all comments and concerns were hammered it out, it then it became doctrine.

  • #office-space: Not a discussion of the hit 1999 Mike Judge film, but rather a discussion of how a growing startup can settle into its office space. After acknowledging that we’re a team of talkers, we established a "Library" in the office which is a quiet area with no-talking allowed.

  • #meetings-suck: Managers need meetings, but makers need time. This Slack channel acknowledged this tension, and resulted in the team coming up with a policy of encouraging folks to walk out of low-value meetings. In addition, we came up with the idea of setting aside Tuesdays and Thursdays as "meeting free" for engineers.

  • #moving-fast: The tension between "moving fast" and "writing perfect code" can not be resolved, and instead it should be acknowledged and celebrated. We have decided, as a fast-paced startup, we actually need this tension. We now celebrate it, and can speak openly about the tradeoffs.


It’s easy for anyone on the team to shine a light on problems we’re facing by spinning up a Slack channel. When spinning up a Slack channel, I usually seed the conversation with some fact-finding. The first topics to discuss in a “problem solving” Slack channel:

  • clarification of the problem (put in the “Purpose” field for the new channel in Slack)

  • how big is the problem?

  • who's feeling it?

  • is this a problem with process, culture, tech, or something else?

  • what best practices, experiences or learnings can we bring in?

To keep your Slack taut, don’t be afraid to carve out a new Slack channel when conversations expand, fork, drift, or fizzle.

I’d love to hear how your team is using Slack!