On the benefits of speaking

I enjoy speaking in front of an audience.  This doesn’t mean I don’t get nervous. Oh, I get nervous enough that I really do need that drink of water. I still love it – the challenge of reacting to the audience, the desire to impart what I know into something meaningful for them.

The greatest feeling I can get from a talk is someone coming up afterwards to thank me for saying what I said. For someone quoting me to me. Hell, for rephrasing what I said more eloquently. But really, it’s about connecting.

But beyond that joy, what real benefits does it give me as the speaker? And, at the same time, what benefits could it provide you?

I want to share my recent revelation with you, something I truly discovered after my most recent talk at Atlassian Summit 13. I had submitted the talk proposal four months earlier. I proposed to talk about a project I was currently on, and about the lessons we had learned in trying to do all that we would try to do. It was a lessons-learned talk, a retrospective. At the time, I had no clue as to what I would end up talking about. I just knew that between the time I proposed the talk and the time it came upon me, I would have learned a few things along the way.


It was because of accepting this talk that I forced myself to really explore what was going on in the project. What I mean is that while I knew there were problems, I couldn’t just point to the problems and say, “See! Don’t do that!” I had to understand why the problems existed, and more importantly, I had to offer up solutions.

I also started going around to certain individuals to try and understand their point of view. That means discussing matters with members of QA, and the other programmers on the team. From them, I not only gained better insight, but also uncovered wonderful metaphors I could use to describe the problems we were facing.

My initial slide deck was structured in the same what that a refactoring recipe is often presented: a smell, followed by why these are problems, followed by solutions. It seemed simple enough. But this was really just the first step. When I started practicing the talk, I came to the realization that while the presentation was factual, it was also fairly negative, and focused too much on the problems. I had very specific points I wanted to make, and most of these points were small bullet points in the third slide of each Smell/Problem/Solution set. I was burying my lead at every point!

The process of practicing my speech, of doing the research to put it together, of talking to individuals drove me to the point of understanding not only the problems, but also how I could properly present the solutions.

But that’s the point. By accepting my role as a speaker, by agreeing to get in front of people to speak on a topic, I need to make sure I know what I’m talking about. So that means I’m going to research the heck out of my topic of choice. That might seem backwards, but it’s not. You see, you’ll want to speak on a topic you’re already familiar with, but once you realize you need to speak on that topic, you’ll force yourself to work extra hard, understanding the additional nuts and bolts.

In the same way that teaching something requires you to learn about it, speaking on a topic means you’ll spend that extra time. And it’s also a great way to learn something. Normally, we are trying to learn something so we understand it. However, when you have to speak about a topic, you have to learn how to describe it easily. You have to impart that knowledge onto others. That means not only understanding it, but understanding it well enough that you can share that information with your audience.

Basically, giving a talk forces you to learn more than you normally would.


Since as far back as I could remember, I’ve never had an issue being in front of people. That’s not to say I don’t get nervous, but rather that I overcome that nervousness. I’ve been in plays, I’ve given talks on topics at local events, I’ve stood alone in front of hundreds, I’ve been a member of a panel; but a talk at a national event is distinctly different. Unlike most other cases, a talk at a conference is one where you are very much aware money was involved (usually a significant amount) and people are choosing to use some of their limited time at that conference to listen to you. You are keenly aware that they did not pay to listen to you, but rather, paid the conference in the hopes that they chose correctly when allowing you to speak.

It wasn’t until I got to Atlassian Summit that I fully realized the gravity of my decision to speak. It was far larger than I’d anticipated, and the audiences in each of the tracks easily went beyond 200 people. And not only were there a lot of people, but the caliber of these people were intimidating. Lockheed Martin, NASA, Disney and LG just to name a few. I’m pretty sure I’m forgetting even larger ones. The point for me was learning this, and knowing that I had to give a talk in front of these people Thursday morning. It’s not that I didn’t think I could give the talk. Rather, it was worry that my talk might not be worth their time. Will my talk make them feel as if that hour had been a waste?

Basically, I wasn’t confident my talk was of any value to the audience I was presenting in front of. I shouldn’t have been worried. A large company is still made up of small teams, and those small teams still have the same problems other small teams have. It wasn’t until after the talk that I truly understood that. In the end, the confidence I gained from giving that talk would help me reach higher and farther than I would normally.

I’m talking about the confidence you get after a talk. That feeling you get when you finish, several people come up to you, thanking you personally and wanting to talk further about what you just spent thirty-minutes to an hour talking about already. The thrills of having someone come up and quote you to you. Reaching people.

That confidence can’t be found any other way. You can only earn that confidence after speaking. And that confidence will stay with you far longer than other kinds. And in the end, it will help you drive yourself farther along, to push yourself further.


The opportunities to speak can also help bring new friends. I’m not speaking about the act of speaking. But speaking in front of new people means you are meeting new people. You are visiting new places. And that brings you new opportunities to make new friends that you would not have made otherwise.

And beyond just making new friends, you can also learn from other people. I’ve been lucky enough to hear interesting stories from people sharing what they’ve done. Even when what they do has nothing to do with what I’m going to talk about, I’m still learning, and making new friends.

The desire to share my knowledge, the desire to speak, gave me the opportunity to make new friends. Meeting up at local user groups and offering to share my knowledge put me in the spotlight. When I moved back to the US, the first friends outside of work that I made were those I made at user groups. Being active in the user group with talks presented me with opportunities to work with them, and in the end, become friends.

You should speak

You really should. You won’t start out in front of a large crowd. You’ll do it first in front of people you know such as coworkers at your company. You’ll branch out into local meet up groups, speaking on carefully selected topics. And maybe that’s as far as you’ll ever want to go. That’s fine. But maybe you’ll want to go farther. And you’ll love it.

You really should try. It can be scary. It is a challenge. It does take work. But it can be worth it. And it can take you places you would have never gone otherwise.

MeetMe’s 90s Tech Flashback

One of the things about working in the tech industry is that we’ve collectively embraced our inner geeks to the point that our profession has become cool. We’ve always known it, but the outside world hasn’t always been as in touch, inadvertently portraying us as socially inept nerds. (To be fair, Bill Gates’s hair style probably set us back a few years on its own.) With software development as prevalent and dominant as it is, there is no longer as much of a negative connotation toward our industry. We wanted to revisit these times before the rest of the world started paying attention, when the tech world was still a little bit awkward.

If this interests you, consider applying to work at MeetMe.

Node 2012 Belated notes

Third year running we have had our developer offsite.  Three days to share knowledge, learn something new and some team building. It generally happens to coincide with a natural disaster. This year was no exception – Sandy.  We made some changes this year to involve the community outside with some knowledge sharing and internally team building with a larger part of the organization.
Pre-event.  We encouraged members of our team to attend the Lehigh Valley Startup Weekend to support efforts to build up tech in this region. The outcome? Our team, with members of the Lehigh Valley Community, placed First and Third (Lehigh Valley Startup Weekend Winners).

Day one. We did something completely new, something that most of the team does not work with currently.  This year, full on Hadoop. Much appreciation to the Chariot Solutions team (they were the only company we talked to that understood what we were trying to do!) for pulling together a one day hackers express for a team that is less than 50% of java developers. Everyone got something out of it.
Day Two and Three. We ran a wide range of internal sessions, almost all hands on, writing code. Writing PHP Extensions, Building on Node.js, and Redis basics to name a few. Our Android and iOS teams led 101 training, getting everyone ramped on writing mobile apps.
Day Three. We concluded with a trip over to Lehigh University where Jonah gave a public presentation, which I have renamed “Algorithms and Anecdotes”.  Jonah, I and others from the MeetMe team talked to some problems and solutions that a growing social network faces.
This year’s experience expanded with our QA team running their own internal event with a focus on cross training and improving skills. A first for our QA team and a great experience to build on for next year.
Normally we integrate team building within our developer offsite, but this year we expanded to incorporate all of engineering, and did it when the developer team returned. Finding the right company and program to work for our team was not simple.  I would suggest three steps to finding the right company to work with : (a) research and identify at least 4-5 (b) have multiple calls with them and make sure they are asking you good, detailed questions and (c) check references. This helped weed out a few companies immediately. Special thanks to Alan Lowis from Professional Team Building for bringing together some knowledge and special moments.
Ending the developers offsite week with our own internal HACKD was terrific and culminated in some great projects in both software and hardware!

Always Be Creating

A team of individuals passionate about their craft, committed to product from concept through deployment and level of individual respect that makes a work environment one can be proud of.

Today we started our HACKD – two days of working on ideas that could be products for our users, art work for the office or something we just want to get done to help the team or the site.  My choice was to launch a public face for our engineering teams: Product, Design, Project Management, Data, Operations, Engineering and QA.

At MeetMe we have built a platform for Social Discovery and look forward to contributing our lessons learned from developing scalable location based services, to launching a global product on web, iOS and Android, and  building scalable teams and process while maintaining a dynamic team culture.