organizing a speakerconf

About 5 years ago I expressed an idea to Josh Graham.

Let's take the parts of traditional conferences that the presenters like the most, and make that an entire conference. Specifically, we should have plenty of discussion time with drinks available & we should have group dinners every night.

I'd expressed this idea to a few different people, and never done anything with it. Luckily, by the time I'd woken up the following morning, Josh had already set up the speakerconf website. Organizing speakerconf has been an interesting and enlightening journey. The past few blog posts have been about what speakerconf is, what presenters are responsible for, & logistics - this post is about how we got started and the organization and participation lessons I learned.

The Beginning
Once Josh created the website I knew it was time to see if we could actually make the event happen. I started by emailing my network to see who liked the idea and would attend. I always knew that 15 was the minimum number of presenters that I would want for a speakerconf, so I sent the emails and waited to see if we had enough interest or not - luckily we did. I also knew I wanted to have a group dinner every night, and the only way to convince 15 people to attend the same restaurant was to pay the bill - so I set out to find sponsors. The management at DRW is incredibly supportive and they quickly offered to sponsor. I also had a great relationship with Forward and they immediately offered to sponsor as well. With both of those sponsors committed, we had the minimum amount of money required to pay for the conference room and cover the cost of the group dinners. At that point there was no looking back, and we began building the hype via Twitter.

Quality, not Quantity
I believed that getting a commitment from a few high-profile speakers would cause plenty of other speakers to jump on board, but the speakerconf idea didn't really generate much buzz the first year (from my point of view). Once the idea became a reality, things changed drastically. The first event was a huge success. We had over 30 people sign up for speakerconf 2010 (in those days, if anyone you knew was going you could go as well). The second event was also a success, but we all agreed that 30+ was too many people. Following 2010, speakerconf became an invite only event and was limited to 25 people.

We were happy with 25 people at each speakerconf, but we ended up learning that less is an even better situation. speakerconf Aruba 2012 had 12 people cancel, which left us in a terrible place. Replacing a speakerconf presenter is extremely hard. The net result was that only 18 people attended, and it worked out perfectly. The collaboration, quality, and enjoyment all seemed to go up significantly. I believe it became a case of addition by subtraction, due to the interactions becoming much richer. After the success of Aruba 2012 Josh and I decided that future speakerconfs will have between 18-20 presenters.

Another Point of View
At speakerconf, your participation in discussion is just as important as your presentation. At the first few speakerconfs I had unreal expectations about people spending every waking minute participating. It was the center of attention for Josh and I, but for the presenters it was just a great event that they needed to responsibly balance with their other commitments. After the first 2 speakerconfs I learned that we needed to set aside time for everyone to take care of work and personal business. At this point, Josh and I allocate 2 hours before dinner each night where presenters can take care of non-speakerconf related issues.

You do not talk about speakerconf
As programmers, we like to optimize. Sadly, I've wasted countless hours and other people's time at speakerconf by discussing how to tweak speakerconf. My intentions were good, I wanted to improve the event. Unfortunately, there's two issues with this: We could be talking about technology instead, and it brings attention to any issues I'm noticing. I believe the old advice that the party takes on the mood of the host - and I don't want to bring speakerconf presenters into my perfectionist world that constantly focuses on otherwise unseen flaws. Plus, if I'm hanging out with some of the best from our industry, it's much more beneficial to hear about what they're working on these days.

I'm not going to lie, it's not easy to stop myself for asking for feedback while the event is running, but I do believe it's the right choice. I'm more than happy to discuss tweaks if someone else brings it up, and I definitely solicit feedback once the event is over; however, speakerconf time is for discussing technology, and the conference benefits when I remember that simple suggestion.

The Best, Last
The last 2 lessons are unquestionably the most important: be flexible and get a co-founder. Brian Goetz mentioned to me many times - get smart people together and let them figure out how to have a good time. Whenever people suggest we tweak something, Josh and I do our best to accomodate and see where it takes us. Above all else, we remove distractions and get out of the way, so presentations or ideas can reach their full potential. Occasionally that means letting a presentation run long, switching the presentation order, taking a quick break, or moving to open discussion ahead of schedule. The schedule always suffers, but the experience always benefits. At this point, Josh and I have learned to roll with whatever comes our way, as long as it enhances speakerconf.

speakerconf requires Josh. I hear it's true that start-ups need a co-founder, and I couldn't have done speakerconf without Josh. I tell him I'm quitting at least once a year. Josh seemed like he might quit last year. However, we carry each other when we need to, and I'm very proud of what we put out each year.

trust at speakerconf

Trust plays a very important role at speakerconf. speakerconf is known as a place where you can be honest without fear of repercussions. Every year we have several presentations that are confidential, and those are often some of the most interesting presentations. Josh and I have made several decisions that encourage a high level of trust, and this blog entry describes those choices.

... it's who you know
Josh and I don't tend to keep people we can't trust within our networks. Therefore, when we began inviting people to speakerconf we already knew we were assembling a group of people that could be honest with each other. I believe the speakers had mutual trust with Josh and I, and that trust was easily extended to other people that Josh and I trusted.

After the first year we started inviting people using a simple rule: 75% of all invites will go to alumni. speakerconf alumni will already have existing relationships with other alumni, and they'll be more willing to share - due to their previous experiences at speakerconf. We always want new people and fresh ideas at speakerconf, but we don't want to lower the trust level by throwing in a larger group of people who haven't yet built strong relationships. We've experimented with inviting less alumni and never been happy with the results. For speakerconf 75% seems to be the magic number.

These days, Josh and I only invite new people to speakerconf based on alumni recommendations. Alumni recommendations are often for people from various backgrounds; which is perfect, as Josh and I prefer to have presenters with diverse experiences. I believe the key to embracing diversity while not compromising on trust is to focus on presenters that have mutual respect for each other despite their backgrounds.

Encourage relationship building
Every speakerconf begins with a meet & greet networking session. This session is usually at a hotel lounge area, and it's only purpose is for each of the speakers to get a chance to meet each other. Following the meet & greet, everyone is invited to an "unoffical" dinner. It's not required or covered by the conference, but it allows people to continue to get to know each other, if they like. Very rarely do any presenters skip this opening dinner.

During both the dinners and the open discussions we provide conference sponsored drinks - to get the honest discussions flowing. I'll be honest, when I'm stone cold sober I can be a bit shy. I get the impression that other speakers sometimes share this personality trait. The open discussions do often begin a bit timidly; however, after a round or two we quickly move to pulling no punches and diving head first into whatever interests us the most.

Off the record
At speakerconf, we don't even provide the option to record your talks. It would be great if we had some material that we could put on line for the rest of the community to benefit from, but we're not willing to sacrifice any level of honesty for the sake of information sharing. We've surveyed the presenters and they've unanimously agreed that they do not want their presentations to be recorded, and they would likely change what they said simply if a camera were present in the meeting room.

It's obvious, but we also remind everyone that if their presentation contains any sensitive information then they should begin by asking the audience not to repeat anything from the presentation. Also, at the beginning of every speakerconf we ask all the speakers to refrain from repeating (e.g. tweeting) any information without first consulting the source of the information.

Network
We don't wear nametags at speakerconf, and we don't go around the room and introduce ourselves. I personally hate nametags, and we found the introduction-go-around to be a bit dry and awkward. Instead, before every presenter speaks, Josh stands up and provides several facts about a person, and a single lie. It's up to the audience to decide which statements are which, though it's generally obvious due to the lie being the statement that caused everyone to laugh. It's fun, and turns the traditional awkward introduction into something you look forward to at the beginning of each presentation.

We don't officially organize seating for lunch or dinner at speakerconf, but we do encourage people to rotate who they sit with while they're dining. We found that the level of trust goes up greatly after you've taken the time to break bread with someone, and we want to encourage that trust building in anyway possible. Like I said, we don't organize anything specific here, we just lead by example; we try to pick our company for our next meal based on who we've spent the least amount of time with.

That's about all we do. There's nothing revolutionary about our methods; however, the result is an environment where trust goes a long way towards helping a presentation reach it's full potential.

scheduling, travelling to, and dining at speakerconf

Convincing 20 industry leaders to set aside 4-5 weekdays to come to a conference is not an easy thing, especially when said conference is also very hard to describe to the person (or people) who are approving the time off, travel, & expenses. With this in mind, Josh and I designed speakerconf to appeal to programmers who work very hard, and are often on the road.

Weekdays. I strongly hold the opinion that conferences should not be on weekends [more info]. Most of the people who attend speakerconf work very hard on an average week, and I don't want take a weekend away from them, their friends, or their family. I'm a very firm believer in work / life balance, and I don't want to be part of tipping the scales even farther in the 'work' direction. Additionally, it makes sense as a conference organizer. I want people showing up to speakerconf rested, refreshed, and ready for several days of intense collaboration. It's not enough to give a great presentation at speakerconf, you need to be on your game for 10-12 hours a day and you need to be able to do it for 3-5 straight days.

My opinion is not universally held - some people can't or don't want to be away from the office for that many days. While I see their point of view and note the benefits of switching to starting on Sunday, I simply don't believe that the trade-offs are a net win for speakerconf. Therefore, the best thing that Josh and I can do is ensure that speakerconf is such a "don't miss" event that people believe it is unquestionably worth being out of the office for a week.

Select an easily accessible location. Easily accessible has always been a requirement of mine for speakerconf. Like I mentioned, speakerconf presenters are often on the road - the last thing I want to do is require an additional connection or an extended drive. Aruba is a direct flight from many cities in the US, and the speakerconf hotel is a 15 minute drive from the airport. Aruba was great for the first few speakerconf events; however, when Josh and I created speakerconf we never anticipated that we would draw so much interest from people in Europe as well. Sticking with our ideals about easy accessibility, speakerconf now rotates between a location that is a direct flight from most US airport hubs and a location that is a direct flight from most EU airports.

Select an isolated location. Running a speakerconf in Rome really drove this point home - last February I asked if 2013 should be in Austin, SF, NYC, or Aruba. The majority preferred Aruba, and, more importantly, those that preferred Aruba were also the ones who were most excited about returning in 2013. Many presenters pointed out that if we were in an actual city they would be more likely to be distracted. The final dinner in Aruba proved their point. In Rome in 2011, 1/3 of the presenters went out to dinner* on the final night. Conversely, in Aruba 17/18 presenters went to dinner and all 17 continued their discussions at the hotel bar for many hours following dinner. The isolated location provided fewer distractions, and seemed to facilitate much deeper interactions.

Select a location with a concentration of restaurants. speakerconf takes a very different approach to dining. Josh and I aim to not only host an amazingly educational event, but to also provide the best dining experience of any conference. We don't provide conference center food for breakfast or lunch, instead we select hotels that are near great local restaurants that serve reasonably priced breakfast and lunch options. Dinners are done at some of the highest rated local restaurants - and we require the ability to select from several different options.

Dine well. Josh and I love food & wine, and our preferences definitely show in our dinner selections. The conference sponsored dinners at speakerconf are generally at restaurants that I prefer to take my wife to when we visit those cities on vacation. The dinner wine selections are usually done based on what Josh has loved drinking in the past. As an example, the conference dinners in Munich are at Boettners & Vue Maximilian, the number 1 & number 3 rated restaurants in Munich according to zagat.com. I could go on and on about the type meals that we aim to provide at speakerconf, but sometimes a picture truly is worth a thousand words - here are the 1,000 that describe a dinner at speakerconf.

Group dinners are better if you split to tables of 3-5. Many people loved being part of a large, group dinner table, but the conversations did suffer a bit. In 2011 we began making dinner reservations for "a party of 20, but we would like 5 tables of 4", and the conversations became longer, deeper, and more productive. As a side benefit, the restaurant staff seems to find this easier to manage as well - which means less issues with 19 people having their food, and awkwardly waiting for the 1 meal that didn't come out right.

On the surface it may look like speakerconf is a week off work, in a vacation location, dining like a king; however, if you look closely, each of those choices is based on a practical choice. The scheduling is a net win for everyone involved. The location facilitates distraction free, deep collaboration. The dining enhances the event by allowing the attendees to focus on collaboration while Josh and I worry about location selection, providing food that meets all dietary restrictions, and ensuring that the cost of dinner doesn't deter attendance. The result (or sum) is also greater than the parts - we provide an easily accessible, deeply educational, & enjoyable experience, which encourages some of the best of the industry leaders to attend, who's attendance encourages more of the industries leaders to attend.

* The final dinner is neither required, nor sponsored - thus it's completely fine for people to opt-out.

speaking at speakerconf

Speaking at speakerconf is nothing like speaking at a traditional conference. It took us a few years to tweak our ideas around presentations - and this blog post is about what we've come to consider 'the speakerconf way' (with respect to speaking)

There are no abstracts or pre-announced talks. From the beginning Josh and I have believed that we want people to be able to speak about whatever is most interesting to them. Too many times in my career I have had a talk accepted to a conference, and by the time the conference comes around I'm on to something new. I honor my commitment and give a talk on the accepted abstract, but I always feel a bit guilty for presenting information that's already somewhat dated. speakerconf completely avoids this issue by neither requesting nor accepting abstracts. In fact, many presenters prepare a few different presentations and just-in-time choose whichever presentation they believe will be better received.

Prepare only 10 minutes of content. speakerconf began with 20 minute time-slots exclusively. Over the following few years we toyed with 5, 15, & 30 minute talks. In general, the 5 minute talks turned out very well, the 15 minute talks turned out well most of the time, and the 30 minute talks always seemed to stretch far too long. Each year Dave Thomas recommended that we give each presenter 10 minutes. We finally made the 10 minutes of content rule change in 2011 and have never looked back. 10 minute talks are perfect for speakerconf. If people are into a topic then the questions end up stretching the session out to 30 (deeply engaged) minutes, if people aren't into a topic then you're off stage before people get bored. Since we've made this rule change, people have been generally happy with the presentations as a whole, and we've yet to have a presenter give a presentation that wasn't enjoyed by the majority of the audience.

Presentations go on as long as they have to. John Hughes inspired this one. Like I mentioned in the last paragraph, we give everyone 10 minutes for content, but let the audience drive the actual length of the presentation with their questions. The speakerconf audiences are inquisitive, so we still need to put an upper bound of 30 minutes on a talk. Still, most talks manage to create plenty of deep discussion in their 30 minute windows.

Presentations first, unstructured conversation second. A few years ago we switched things up by splitting up the presentations, and it didn't work well - people couldn't get back in the mood for presentations. Now, each day starts with presentations that spark ideas and then goes to unstructured conversation about those ideas.

Alumni speak first. Originally, we allowed speakers to request their speaking slots. In the 2nd year Matt Deiters requested and spoke in the 2nd speaking spot, and quickly regretted it. Speaking at speakerconf requires a bit of calibration. The audience at speakerconf isn't like the vast majority of conferences, and you do need to alter your presentation style a bit - go faster, take out filler or elementary slides, expect frequent interruptions. After a few days of speakerconf it's easy to fall in the groove; however, Matt didn't get that luxury. Based on his suggestion, each speakerconf since then has scheduled all alumni ahead of new-comer presentations.

Dynamic speaking order. Each speakerconf does have a suggested schedule; however, we also offer the opportunity to 'get next' at any time. At speakerconf Rome 2011, Francesco Cesarini noticed that his presentation would go very well if it followed Scott Farquhar's. Unbeknownst to the presenters and organizers, some people end up presenting on very similar ideas. Once the audience gets into a subject, it makes sense to allow presentations with complementary ideas topics to be grouped together. Therefore, at speakerconf any presenter that believes their presentation will nicely expand on the current presentation can simply let the organizers know that they've 'got next' and they'll be moved into the next speaking time-slot.

Everyone speaks. For the first few years we had attendees and presenters; however, we found that there were a few issues with non-speaking audience members. First of all, when you speak everyone knows a bit about who you are and what you do; conversely, the non-speaking attendees were always a mystery. Additionally, speaking audience members always participated significantly more, as they had given people a topic to approach them about. Lastly, we often had non-speaking attendees who the other speakers actually wanted to hear from. In the end it just didn't make sense to invite very talented people who were only participating in the open discussions. Now, and in the future, there are no attendees, if you attend speakerconf, you present.

The speakerconf way is very nimble. We don't know what people are going to talk about, how long they're going to talk, or when they're going to give their presentation. In fact, the only thing we do know is that you are eventually going to speak about something. Obviously this isn't something that every conference could adopt, but we've found that it greatly enriches the speakerconf experience. The speakerconf way provides a quick exit for anyone who's idea isn't going over quite as smoothly as they'd anticipated, but, more importantly, it allows the good presentations to reach their full potential.

a typical day at speakerconf

At this point, speakerconf has run 5 times in 4 years - in Aruba and Italy. Josh and I are happy with what we've created, and a few follow up entires will list the attributes of speakerconf that make it a unique and successful event. This post, however, should serve as a quick view into what a typical day is like at speakerconf.

the morning
Each day begins unofficially at breakfast. There's no assigned meeting time, but people generally start appearing around 9:00am. There are no assigned tables, and people usually just break off into small, ad hoc groups of 3 or 4. It's rare to find one of these tables not talking about what interested them from the day before, or what they're looking forward to discussing that day. Following breakfast, people begin filling into the conference room, and presentations begin at 10:00am sharp. Each presentation generally takes between 10 and 30 minutes. There's usually a ton of questions that go with each presentation, thus the variable talk time-slot. We attempt to get 4 presentations done each morning, and usually end up leaving 'late' for lunch.

the afternoon
Lunch generally lasts an hour, and is done at one of the local restaurants (not in the conference room). Attendees break into small groups and go to different restaurants. Most often, people go to lunch with someone they want to discuss a specific idea with, or someone they haven't previously dined with. After lunch everyone makes their way back to the conference room for 4 more presentations. On a good day, we'll be done with presentations by 3pm; however, (due to the q&a for each presentation) we're usually done with presentations between 3:30pm and 4:00pm.

Once the presentations end we move out of the conference room and into a space that allows us to have many smaller discussions. The split is ad hoc once again, and, just like lunch, is often based on digging further into a presented topic or meeting a new person. These discussions often begin with most of the presenters in attendance, and people only seem to leave if they have personal or business matters to attend to. These smaller discussions end (or rather, are put on hold) at 6:45pm at the latest.

the evening
Dinner is always at a local restaurant (outside of the hotel), and usually begins around 7:00pm. Just like every other meal, attendees break up into unassigned, smaller groups of 3-6 people. Dinners are usually at least 3 courses, and offer plenty of time to dig deep into whatever subject drove you to select your dinner companions. Once dinner is complete everyone heads back to the hotel, and those that still have the energy to have further discussions generally make their way to the hotel bar. It's not uncommon for those that have already completed their presentations to stay out past 2am - and still get themselves to the 9:00am breakfast the following morning.

That's a pretty typical day at speakerconf. If it doesn't sound exhausting, then I haven't done a very good job of describing it. However, it's equally exhausting as it is inspiring, and the days at speakerconf are some of my favorite days of the year.

Follow-up Thoughts on Aligning Business & Programmer Goals

My recent entry on Aligning Business & Programmer Goals led to an email conversation that I thought might be worth sharing.

From A. Nonymous:

I have an issue with tying bonuses to performance due to, basically, performance being out of the programmer's hands. Where I'm working right now developers are treated as code monkeys: We're there to implement features the business people dream up, and nothing more. How could I provide more value when I work in an environment where

• The visual design phase has already happened (no pushback on any design elements taken seriously)
• The business development phase has already happened (i.e. the business decides to create a new service tells it's code monkeys: "we need feature x, y, and z")
• The individual projects we're working on is out of our control.

I can't figure out how to tie what I do to business value in the short term (or even in the year-long-term), because I don't have the autonomy to work on things that I think would benefit the business. I'm forced to do the work that someone else assigns me. Are the new features/bug fixes creating value? Definitely. How much value? Not a clue. How can the value I bring be measured? The only metric I'm seeing is "ease of implementing the next new feature", but the next feature that touches the code I wrote probably won't be developed for months, if not years.

So, it doesn't seem justified to assign me a bonus based on the value that features create, when I have no control over the features.

My response:

Given your context, I wouldn't want a bonus either. I imagine that many people are in the same situation... probably most people.

2 notes-

• The blog entry isn't solely about bonuses, the ending is all about a visible P&L and nothing about a bonus. I hope people don't completely miss that point.
• While your position is status quo, I think we should strive to do better as an industry. I don't think it's healthy that we (programmers in general, not necessarily you or me) work for organizations where we know little about the business, don't trust our business counterparts, and are not trusted by our business counterparts. Programmers are often ruthless about measurement and improvement, and wasting that effort on resume driven development or process tweaks is bad for our businesses and our reputations.

It's easy for me to say that the good programmers should quit companies that don't expose a P&L and don't empower their programmers, but I know that personal situations can limit people's choices. At the same time, I feel good about continuing to write about the path that I take, which includes quitting companies that I don't feel are aligned. Even if my ideas can't help you at this point; hopefully, something will come of them in the future.

A. Nonymous followed up with:

I totally get the visible P&L part and agree with you on it. Having more visibility into the inner workings of the business can only help focus effort where it's important. Not every business leader feels that way, unfortunately. I'm currently fighting with my boss about a similar issue. I alluded to it before, but he wants to follow what many consultancies are now calling "Agile":

• analyst meets with business team
• analyst comes up with features
• qa writes acceptance test for features
• developer receives/estimates/completes features

At no point in this process does the developer have any contact with the business team.

Do you have any idea how I'd go about convincing upper management that sharing the P&L would be a good idea?

And, my final response:

I've never seen studies on the impact of sharing the P&L. Most of the discussion around this stuff is still in it's infancy as far as I can tell. Brian Goetz has been talking about 'language & framework introduction' for awhile, but I've never heard it combined with P&L.

I would attack your situation in one of the two following ways-

• Fully support your boss' plan, but request to be put on a 'research' or 'experimental' team where you interact directly with the business on a new product (assuming that's possible). I've done this successfully. The rest of IT followed the traditional approach that your boss is proposing, but I broke off with 1 PM and we worked directly with the business on technology for new business lines. I never got to see P&L (though, I never asked), but I would get requirements and deliver features on demand and we ended up constantly impressing the business. e.g. "business: How quickly can you deliver this? (I start thinking of my estimate) business: August? me: (shocked, it was March) I was thinking in the next 2 weeks. -- that conversation actually happened, I'll never forget it. If you get this approved, your boss still gets to do what he wants, and you get to try to do better. If you succeed, he can take the credit for approving the experiment - win/win.
• Assuming you cannot find a way to interact with the business, focus all your efforts on reducing the delivery cycle. If he's going to force the team to be basically skilled labor, you need to deliver at a rapid enough pace that you fail quickly and pivot toward profitable business goals. You build, they point you in a better direction, you build, they point you in a better direction, on and on. Your 'interaction' with the business is delivering them software, and you will benefit from doing that as often as possible. So, focus on things like choosing the best tools for the job, getting the build time down, reducing the test running time, etc, etc. Anything that's slowing you down from delivering faster, it's in your best interest to remove that, so you can get the business feedback as fast as possible. Even if your boss forced you to only do a roll-out monthly (or worse), the more you have to roll-out, the more feedback you'll get - so removing any thing that takes your time and isn't contributing to feature delivery. Dan Bodart is doing interesting stuff with build times and you should be able to find plenty of advice on speeding up tests - attack that stuff so you deliver as much to the business as possible.

While A. Nonymous may never get to see the P&L, and may never be in a situation where we would want a bonus - there are steps that can be taken to align the business & the programmers.

Aligning Business & Programmer Goals

A theme emerged, last week at speakerconf, around the idea that programmers and businesses still don't seem to be on the same page. I'm not sure if it came up even earlier, but for me it began after I gave a presentation on Lessons Learned Adopting Clojure. The talk is similar to Lessons Learned while Introducing a New Programming Language, but focuses more on the technical aspects of selecting Clojure. Upon talk completion the first question I got was from Brian Goetz, something along the lines of:

(Brian) So, you wanted to use another language and simply introduced it into production?
(me) More or less.
(Brian) Do you think that's the most effective way for organizations to select languages or frameworks?

The first response to the question was the obvious and appropriate one:

That sounds better than a CTO making a decision while drunk and on a golf-course with a vendor. -- Josh Graham

Of course, I agree with that response, but that doesn't mean that my choice was the best answer either. The question is actually something I've been struggling with for awhile. At speakerconf Aruba 2011, Lyle (DRW CTO) gave a presentation on how we do things at DRW. One of Lyle's slides listed each language that we use in production at DRW. There were a lot of languages, probably around 25, and Dave Thomas questioned whether it was a positive or a maintenance nightmare. The answer today is the same as it was then, so far the ROI is positive - but, I couldn't help feeling uneasy about the situation.

I answered somewhat noncommittally, along the lines of: While selecting a language, I chose one that I felt anyone in DRW could easily learn and use. Additionally, I selected a language that aligned with our business goals of developing software quickly and delivering applications that performed at the speeds required by the traders. And, if not the man on the ground, who is better suited for selecting languages to introduce into production?

Brian followed up with:

The point I was trying to get at was: how does this scale? If every developer chooses what is best for them, is that necessarily best for the organization? How do we balance between the business value of increasing individual productivity and the business value of reducing maintenance costs or development risk? If we have to make compromises to achieve better scale, who should make these decisions, and how?

The usual developer argument -- "this is more productive for me, and increasing my productivity is good for the company" is good as far as it goes, but most developers incorrectly assume these interests are 100% aligned when they are in reality probably only merely overlapping.

These are truly great questions, and no one had a great response. The discussion basically died off as we pondered the tough answers to these questions.

At lunch the next day I asked Brian how he thought companies should go about selecting languages, and I think his response was spot-on (again, going from memory, so likely misquoting): I'm not sure, but I sure do see a lot of developers introducing whatever language or framework they want, leaving within a year, and sticking their employer with a big maintenance problem. The same can be said for consultants. They often show up advocating a sexy new language, mostly deliver a new application and then leave the company with an application that can't be maintained by the existing full-time staff.

Someone quickly spoke up, stating that Resume Driven Development has been going on for years. I can't argue with that, but I did have a different perspective.

A few years ago I joined DRW, and a substantial portion of my salary became bonus money. I had previously worked in places where getting bonus money was about as likely as meeting your future wife at a JavaOne, so I was obviously skeptical. Luckily, I had a friend who already worked for DRW; he reassured me that, in finance, having a bonus as part of your compensation was common, and so was it actually getting paid. I took the job, and instantly my performance at work was more directly tied to my income. I'm sure this reality influenced my decision making, and I witnessed the difference in the decisions my colleagues were making. When people spoke about using/upgrading frameworks/libraries, we didn't talk about what was cool, we discussed the risks of breaking things, the outstanding bugs with the framework/lib, and the immediate value that the inclusion would provide.

Given this experience, I advocated to the other speakerconf presenters that bonuses are a potential solution to combatting Resume Driven Development. The other speakerconf presenters gave me the same response I generally get when advocating bonuses for programmers: That works for you and your trading firm, but most people can't directly tie what they do to how the business makes money. I'm always skeptical of this response for 2 reasons: The business must be able to track whether or not their new idea is making them money, or, if the new software isn't targeted to an external customer, then it should be able to be rated by internal customers. Also, shouldn't the CTO or the Director of Software be able to make an informed bonus decision by either directly interacting with the teams, or trusting the feedback of the managers of those teams?

I guess, if you can't tie what you are doing to the value it's providing the company, and you don't trust your managers to give an accurate assessment, building your resume is probably the best use of your time... and the results aren't very surprising... but, I digress.

I gave the same response I've given a few dozen times: I just don't buy it. You should be able to see how many new customers your new website generated, or less cancellations, new reservations, policy efficiency, auction traffic, add-on sales purchased, etc. Each of the projects I've worked on for the past 8 years could generate metrics that I would have been happy to tie to a bonus. In our back-office, it's harder to tie the value of a back office system to an individual trade; however, we can capture metrics on uptime, latency, and any other attribute that we deem important to the internal systems that are customers of the back office systems.

If you want to measure your value and you trust your management, receiving part of your salary as a bonus is completely viable.

Aligning the goals of the business and the programmers came up again when the afternoon presentations began. Joshua Kerievsky is looking to tackle this same issue at Industrial Logic. Joshua's presentation discussed bridging the gap between managers and programmers, which is a more general version of the same conversation we'd been having about language adoption. Bridging this gap is something he's begun focusing on at Industrial Logic. The benefits are obvious for customers, they should receive higher quality and more relevant software. However, it's not just about customers, the programmers will be more effective and should also have higher job satisfaction rates. No one likes being stuck on yet another, doomed to fail, misguided project using outdated technology. Both parties should benefit by unifying the goals of the programmer and the business.

Josh knew my opinion on using bonuses to help align both parties; however, he and I both incorrectly assumed that the developers at Forward also received business performance based bonuses. I believe that they have some things in the works and situations can vary, but Fred George made it clear that in general a bonus is not tied to business focus. That's fairly standard, but what makes Forward unique is that the business works very, very closely with the programmers. I think Fred nicely summed up the situation: Our programmers are gamers, and we show them the P&L. They want to see that number grow, even if it doesn't directly deposit in their account.

Fred's statement rang very true to me. I've had jobs in the past where I didn't even have a bonus, but the ones that I felt most dedicated to were the ones where I was given visibility into the business. If I can't see the outcome of my programming choices to the business, I'll have a much harder time iterating towards success - worse, I won't even know at what level we are failing and I'll lack the motivation that the failure would provide me.

At the end of the day, programmers like to measure and improve. If you give them a P&L and let them know that it's the most important thing, they'll do whatever they can to help. If you don't give them a P&L they'll focus on making other metrics more efficient. This may include using new technologies to inspire more blog entires, spending hours unnecessarily tweaking the development process, or any other way of measuring their "success." The answer is obvious, let the programmers measure success the same way the business does, using the bottom line. What's not always obvious is how to properly share that information; however, all the discussion at speakerconf definitely convinced me that it's worth solving this issue even if it requires a bit of extra effort.

How To Get Invited To speakerconf

Every year it seems that someone is disappointed (or even insulted) that they didn't receive an invite to speakerconf. If you haven't gotten an invite at this point, contrary to popular belief, it's not because Josh and I hate you. There's actually very little magic that goes into receiving a speakerconf invite, so it probably makes sense to put the formula out there.

I'm not a big fan of receiving spam, and while I consider speakerconf to be a great event, I'm sure some people will consider speakerconf related email to be spam. With that in mind, I generally don't like to email people I don't know out of the blue. Along the same lines, some people are going to politely decline every invite I send their way. The less I know you, the less likely I am to continue inviting you, simply because I don't want to bother you. If you say to me "please keep me in mind in the future," I will. If you don't, I'll likely default on the safe side of not bothering you until you show some interest.

So, if you haven't gotten an invite lately (or ever) it's likely only because I don't want to bother you.

With that out of the way, here's roughly how we select who to invite to speakerconf:
speakerconf needs sponsors to run in the way that Josh and I want to run it. If you've previously attended a speakerconf you can guarantee yourself an invite if your company is willing to become a sponsor. If you've never attended a speakerconf you can also guarantee yourself an invite by getting your company to become a sponsor and getting an endorsement from any one of the speakerconf alumni (list available at http://speakerconf.com/speakers). If you are interested in discussing specifics, drop me an email (jay@jayfields.com).

If you're not interested in sponsoring, your invite depends on space or endorsements. If you've previously attended a speakerconf and you'd like to return, all you need to do is let me know. If we have space at the next event, I'll gladly extend you an invite. If we don't have space, I'll extend you an invite to the following event.

Future speakerconf events will likely have a maximum number of 20 attendees. Approximately 15 spots will be reserved for alumni, and the remaining ~5 spots will be available to anyone who has never attended a speakerconf. If you would like to grab one of those spots, all you need to do is get as many alumni as you can to email me and endorse you. They don't need to send a long email, something as simple as "you should invite Josh Graham to the next speakerconf" will do. Then, approximately 6 months before an upcoming speakerconf I will invite the 5 most alumni endorsed new comers.

That's it. If you want to join us all you need to do is to utilize your network or become a sponsor. Hopefully this view into the invitation process will help avoid any disappointment in the future.