This week Sean Newham (@SeanNewham) and I are visiting a company called Farm Credit Services of America. Last night a bunch of them, including John Morehouse (@SqlrUs), their production DBA, took us out to dinner and we were discussing how DBAs and developers should be better at working together. They play different but important roles and both are necessary in order to deliver a good data service to the business. Developers and DBAs have different but complimentary skills and they should be better at learning from each other, however, it can be hard to find an efficient way to transfer data between human brains.

In this post I’m going to discuss a way of solving this problem that is currently working well for us at Red Gate. I hope you find it useful and would love to know if you have any  experience or lessons from trying something similar.

*

Wednesday 16^th of July 2014 – we are en route to SQL Bits. I’m in the passenger seat and my colleague, Kat Codlin (@Katarinazoe), is driving. She’s a sales person who has worked at Red Gate longer than I have and I like to think that we are friends.

Once upon a time we sat next to each other and competed each month to make the most sales. The competition was friendly but our tactics were very different. According to most sales manuals Kat has many of the components of a great sales person. She is a charming character and one of those rare individuals that people just love to talk to and do business with. She was also a well-oiled machine, spending the minimum of time with each customer to get the deal done: dial, [some magic], close the deal, hang up, dial again. It sounds cold but she has the perfect balance between a friendly way of dealing with people and efficient business acumen. Customers like the fact that she is both lovely to work with and efficient with their orders.

I, on the other hand, do not have a natural gift for getting on with people. I sometimes find social situations a little awkward. I’m a geek. In many ways I am a software developer who chose the wrong profession. My approach was to spend hours on the phone with a single customer, really get to the nub of a technical problem and help a customer to solve it. Then I would put together a quote for them and probably never call them again. I knew if I’d sold it right the first time the customer would get back to me and place the order. That’s sacrilege to most sales professionals, but it worked for me. I brought in half the number of invoices but they were for twice as much money and as a result I gained the nick-name ‘Big Deal Yates’ because the other sales guys rarely saw me ‘selling’ but customers would call me out of the blue and place large orders. One of the other sales guys even bought me ‘Big Deal Yates’ stamp.

It was a close run thing each month as to which of us would make the most money.

Fast-forward a few years and our careers have moved on. I’m doing what I do now and Kat is one of our most senior and respected sales people. A lot of the newer sales people look up to her and respect her. Now we are sat together in her car en route to work the Red Gate booth at the UK’s largest SQL Server event.

These are the circumstances under which tech coffee was born.

Rule one: Transfer data in an informal and safe setting

Kat and I have an enormous amount of respect for the skills each other have. In many ways this is because the skills are not mutual. I’ll never be able to deal with people the way Kat does, and she admires my technical ability. We don’t sit together any more but Kat said that she loves to take every opportunity to spend time with myself and some of the developers and product managers at Red Gate because she wants to learn what we know as it will help her to be a better sales person.

Out technical training, at the time, consisted mostly of a one or two hour class-room style session on an irregular basis with one of our pre-sales engineers. Classroom learning works well for some people but not for everyone. Different brains process bits of information differently so our single form of technical training worked better for some people than it did for others.

For Kat learning in large groups was hard because she (like many of us) feels nervous about getting stuff wrong in front of other people. She also finds that an hour discussing software languages that she doesn’t understand is too much to take in.

Rule two: Transfer data often, in small packets

That is why I suggested that we should have coffee together each morning at a regular time for fifteen minutes. It would be an opportunity to have an informal and open discussion about any technical topic  that either she or I wanted to discuss. We might discuss the history of continuous integration, or take a chance to practice a software demo. One of us might bring a blog post we read or a question that a customer has asked us. We might simply try to fix a problem with one of our laptops or learn how to use a VM on our machine so we can re-set our demo to a reliable starting state. Really, the goal of the coffee break was pretty vague, and intentionally so. This was intended from the outset to be different from a formal one hour training session.

Rule three: Find the right people

So a few days later came the time for our first ‘tech coffee’. I sat down at a two person table with a laptop in Café Porto Rossa (our coffee area in the atrium of our office). I proceeded to boot up a VM on which I had installed TeamCity. (In today’s session I wanted to talk, at a high level, about what a build server actually does and why developers use them.) To my surprise a couple of minutes later I was greeted not by one person but by two. Mitch Fordham is Kat’s current desk neighbour. She had told him about tech coffee and it seemed to him like a good idea. He also felt that he would be able to do his job better if he had a better technical understanding and tech coffee sounded like a fun way of improving his knowledge.

The session went really well. We ran over, but since the session was so short we were still done in twenty minutes and in that time both Mitch and Kat were able to discuss concepts and ask questions. They probably left with a better understanding of the role of a CI server than either would have achieved in a one hour classroom session. It doesn’t take a mathematician to work out that this protocol has some potential when considering the relative data transfer speed.

We planned to meet again the next day with a loose plan that Mitch and Kat would remind me what we discussed today before we went on to discuss the different CI servers that are available and I promised to show them Jenkins.

But the next day Mitch and Kat were joined by Christian and James. Within a week the word had caught on and I was joined by Sean, a developer who was able to give a different perspective to myself, and Kat was joined by a total of about five sales reps.

It turns out that by starting with the people in a group who are respected by their peers and growing something that works in an organic fashion, the word spreads.

Rule four: Find your own route

One of the things that kept maintaining the momentum of tech coffee is that the sales guys were able to choose the content. More brains come up with more fun ideas so we have done lots of different things. We’ve had guest speakers come along from dev and test functions, we’ve had our own DBA come and talk to the sales guys about what they do, we’ve stung several coffee sessions together to run a larger project where we configured Jenkins together, after classroom style sessions (which certainly still have a place) we have run a post-class Q and A debrief, we’ve even run quick pop quiz sessions. Sometimes, we even cancel the meeting at short notice and that’s fine – we fit tech coffee in around our day jobs and sometimes, well, something is on fire. I’m very keen that tech coffee is entirely optional and that it  never becomes a compulsory meeting for meetings sake.

Considerations

So, for us, tech coffee has been a big success. It provides a safe, informal setting where people with different skills can discuss some relevant topics that they should find useful. I’ve also found that it has been useful for forging friendships with people that I don’t work with every day, so perhaps some of Kat’s skills are rubbing off on me too.

This, however, has posed new questions. Tech coffee worked because it came about organically and kind of by accident, the result of getting some passionate people together with goals to learn and teach. It works not just because of the format but also because of the people. How do you roll something like that out?

Various managers around the company have asked me how I/they could set up something similar in our US office or with our customer support team. How could we have cross-functional tech coffees so that designers, tech authors, sales people and our receptionist can all benefit? How do you scale human beings?

Frankly, I don’t have all the answers. I’m wrestling with some of these questions myself. All I know is Kat and I tried something and it worked really well for a particular small group of people. I hope you find this story has relevance to your own teams – John Morehouse thought it might be something he could try to help developers and DBAs share their knowledge so I’m keen to find out if anything comes of that.

If you have found a protocol for data transfer between brains that works for you please leave a note – I would really love to read about approaches that other people have taken and any lessons they have learned from experience.