Suggestions
Jack Hannah
Making remote pair programming personal
Jack Hannah is the Head of Sales at Tuple, a company that specializes in pair programming tools.15 He is based in Boston, Massachusetts, and brings a wealth of experience to his role at Tuple.4
Professional Background
Jack Hannah has been described as a master seller who exudes entrepreneurial hustle.2 His diverse experience includes:
- Previous roles: Before joining Tuple, Jack worked at companies such as HourWork, LinkSquares, and Salesforce.234
- Skills: Through his various roles, Jack has demonstrated strong intuition on a wide range of business challenges.2
Current Role at Tuple
As the Head of Sales at Tuple, Jack Hannah is responsible for leading the company's sales efforts. He is part of the management team alongside other key executives such as:
- Spencer Dixon (Co-Founder, CTO)
- Joel Sutherland (Co-Founder, COO)5
Jack's role is crucial in driving Tuple's growth and success in the pair programming tools market.
Professional Network
Jack Hannah maintains an active presence on professional networking platforms. His LinkedIn profile can be found under the username jack-hannah-62403754, where he shares insights and updates about his work in the sales and business development field.3
Highlights
Introducing pairing can be a lot easier than most will lead you to believe.
How?
By picking a company or team that’s more receptive to this sort of thing in the first place.
Is that a cop out? Maybe.
But having spoken to 60+ developers who love to pair, it's clear that introducing pairing is much easier in some places than it is in others.
Here are 3 things to ask while interviewing to assess the situation, crowdsourced from XP developers who’ve been there and done that:
- Does the team pair or mob program at all? If not, how do folks typically work together?
This one is hopefully obvious and is the right place to start. Interviewers’ reactions to the question, regardless of what they say, will tell you a lot.
- How are promotions made and performance assessed at this company?
Incentives matter a great deal. If the company heavily rewards individual achievement, you’ll face much more resistance to collaborative working styles.
- What’s the typical feedback loop look like for work in progress?
Teams that value short feedback loops will be much easier to convince that pairing is worth it because it’s ostensibly the shortest feedback loop there is.
BONUS: don’t stop after asking the hiring manager.
Request to speak to a handful of engineers on the team to better understand their experience.
Ask these same questions and look for inconsistencies. If you hear radically different things from different people, that should give you pause.
Spoke to a Principal Engineer at Thoughtworks with 20 years of software experience.
What’s the number 1 challenge he sees remote dev teams struggling with?
The belief that async communication is better than synchronous.
Let’s be clear, there’s a time and a place for each.
But he consistently sees teams and companies over-index on async simply because they’re remote.
Why is that a problem?
The likelihood is so much higher of misunderstanding, or straight up never seeing, asynchronous communication compared to synchronous.
It’s kind of hard to ignore someone when you’re speaking face to face.
It’s also a lot easier to get on the same page.
Folks are bombarded with more emails and Slack messages than ever.
Communicate live if it’s important. You can always follow-up in writing.
