Tag: sentry data systems

The Non-Technical Tech Talk

johnjpeeblesLeave a comment

Two weeks ago (was it three?) I spoke at an ACM sponsored Tech Talk at Purdue University.  My mission was to give perspective on what it takes to run a large and quickly growing software team.  Many startups (including some I’ve been affiliated with in the past) will grow from very small teams to departments of over a hundred in a short time.  That kind of growth is explosive so as I thought about what to say during the presentation, I was struck that very rarely do I hear much about the human element of running a software organization.  I never heard about it in school. Focus on the people side of software construction has been one of my major recurring management themes because, as I told the group of students at Purdue, software development is one of the most human-intensive, human-dependent disciplines/arts/crafts/industries that exist.

To many, this might exemplify a supreme irony, but this has always been a core belief of mine: you can’t build great software without great people.  You can’t build great software without great teams.  Hardware and tools are easy to come by now, and the end result is that in today’s software industry, people are the only variable that means anything.  That’s why software companies should be psychotic about keeping turnover low.  Everywhere I’ve been I try to minimize bureaucracy.   I encourage telecommuting and spend money on great tools.  I like to setup team building, fun activities that appeal to technology workers like playing video games together once a week.  These are all downstream things that I focus on to maintain my upstream asset: people.

What does working on a great team with great people look like?  For students still in school, this is hard to visualize.  Group projects are almost universally hated.  Internships generally involve working as someone’s grunt on some meaningless or semi-solo system or task.  But I got all heads nodding when I asked if while they were doing their horrible group projects with their horrible group members if they remembered that one group who got up in front to present that was clearly happy to be working together, who had enthusiasm for their work product, and had spent an inordinate amount of time on their project.  Did they seem tired or annoyed?  No.  Was their project the best in the class?  Yes.  That is what a well-gelled software team feels like, looks like, and that’s the kind of product it produces. I talked a little more about great teams and how to recruit them and run them as we all munched on pizza.   Afterwards the organizer walked up and stated that I had given the most non-technical tech talk ever, but that he felt it was important and something that often gets missed.  

I definitely agree about the missing piece, and we got invited back for more pizza and another tech talk so we’re grateful for another opportunity.  I’d say that was mission accomplished.

Distributed Software Teams

johnjpeeblesLeave a comment

At Sentry Data Systems, we have a very distributed technology organization.  The majority of our technical staff does not work from our Deerfield Beach headquarters.  Instead, we have our developers, implementation staff, tech support, and infrastructure personnel spread out across the country, and even a satellite office located in the midwest.  Everyone is an employee, and we don’t do any offshoring, but we are most certainly not geographically close to each other.If you’d asked me five years ago if I thought this would be a good approach to take, I would have rather emphatically told you no.  In fact, I resisted it pretty strenuously for quite a while.  You had to be a senior developer, having spent significant time on site (at least a year), and working remote was a reserved privilege.  While we had a few guys working remotely, it wasn’t the majority you see, so Bad Things couldn’t happen, but we still had folks dialing in right from the beginning.  And yet, in hindsight, it may be one of the factors that helps us squeeze more productivity out of our staff, helps them produce higher quality code, and allows us to get the leg up on competition.For starters, it forced us extremely early on to invest in systems, processes, and a way of working that brought everything we did online.  Project management, change control, bug tracking, issue tracking, source control, testing, collaboration, documentation, document management, communication, all of these things needed to be ubiquitous and consistently used by the entire staff.  If things weren’t accessible online, that meant Bob in Utah wasn’t going to be able to contribute, learn, participate, or even know about it.The second major factor that a distributed team gives us is a national recruiting footprint.  We’re not just going up against Acme Software in our back yard down here in Fort Lauderdale (South Florida has its own disadvantages for hiring technology workers), we’re getting to compete for the top talent across the US in every job market.  Our pool of potential applicants increases by an order of magnitude or more, which really amps up the talent level and allows us to be super picky.Third, I recently came across this article recently which was discussing some research from Microsoft, exploring traditional myths about Software Development, and they touched on the fact that distributed teams in their experience don’t have a negative impact on team performance.  They rightly point out that this flies in the face of a “one of the most cherished beliefs of software development” but they also illustrate how any worker would much rather talk to someone knowledgeable on their team 4,000 miles away than a less knowledgeable guy next door.  Makes sense, and it jives with our experience as well, but I can’t say I expected this outcome at first.Are there drawbacks?  Sure.  It’s nice to have everyone over for a barbeque on a long weekend, and that can’t happen.  It’s fun to walk by and joke with everyone while making the rounds in the morning, and that’s harder to do, but we still manage to interact a good deal as a team.  The flip side is it’s nice for the remote guys to be able to live where they want,  stay in touch with family and friends, and yet still have a great job at a fun company.  This really contributes to retention – we’ve had several guys move several times in the last few years, which I count as a “save” on losing an employee each time.If you’re considering running your organization’s software teams in a distributed fashion, here’s some things you’ll want to make sure you’ve got covered:

  • Excellent communication methods: cell phones, VoIP phones for extension dialing off the corporate network, private instant messaging network, email, and more.
  • Organizational Discipline: People in the organization need to understand that they will often be interacting with remote individuals, and that they can’t cherry pick projects to those who are in the office.  Yes, a phone call is not as nice as face-to-face, but often it’s more productive.
  • Team-Based Activities are Still Key: This is an easy one for us.  We play video games every Friday afternoon/evening.  Combination of shooters (Team Fortress 2) and other games (DoTA and HoN) and the games are part of the employee start up paperwork.
  • Everything Must be Online: Bug tracking, brainstorming, documentation, everything.  A major advantage this gives you is it’s a head start on preparing for audits or other certifications (SAS70, etc.) you might need to complete as an organization as everything will be easily accessible.
  • You Still Need to Be Involved: If you like to walk around and say hi to everyone each day like I do in the office, you still need to do it “online” via instant messenger or phone call.
  • Figure out if a Satellite Office Makes Sense: We found that we had roughly 5 people clustered in one city, so we sprung for a satellite office.  It’s a cheap thing to do and helps our recruiting in that area.
  • One Timezone: We work on US Eastern time.  You can live where you want, but you’re going to work that timezone.  This is critical, in my opinion and while it does mean the guys in California are up at 5AM, it’s not the end of the world and really helps keep things simple from a scheduling and planning perspective, and maintains the ability for quick communication.

It probably isn’t for every organization, but it’s really worked out for us, and it’s definitely something we’ve grown organically and will continue to improve.