Dealing with growing pains without sacrificing sustainability

Much of the software industry seems to be locked in an endless race against time. The tensions between maintaining what we’ve already built, shipping new work that addresses urgent needs, and keeping an eye on what new opportunities lie just beyond the horizon can leave us feeling overworked and spread thin.

For many tech-centric businesses, this unpleasant way of working is accepted as a way of life. And the default assumption is that a team that cannot easily keep up with the pace of demand is one that needs to grow as soon as possible: that an extra set of hands will help lighten the load, and miraculously cure all problems. This leads many businesses to rush their hiring process, but the expected cure either never comes or is too little, too late.

Fortunately, not everyone accepts this hasty approach towards scaling a development effort. Although we don’t hear their stories often, there are plenty of people and organizations out there who believe that it’s possible to move fast and to meet the ever-changing demands of our industry without sacrificing a sustainable working pace.

So, what are the folks who take a measured approach towards growth doing differently? What can the rest of us learn from them?

To figure that out, I asked my friend Brian V. Hughes to share his story with us. His journey through software development started around the time that the Web itself began, so he is no stranger to rapid expansions in scale and scope. His balanced strategy for growing teams, processes, and technical capabilities alongside one another is well worth digging into, and so I’m happy to share it with you today.

Carve out space for learning by simplifying your daily work

Brian began his career as a database administrator for a small office within Dartmouth College, where he immediately set out to script himself out of a job. Although he didn’t consciously think about it at the time, this bias towards “automating all the things” would prove to be of critical importance throughout the later stages of his career.

The basic pattern that Brian applied is relatively straightforward: identify any repetitive and time consuming work you’re already doing, and use your current technical tooling and skills to streamline and routinize those parts as much as possible. Then, with the time that frees up, spend a good portion of your time learning about and playing with new things that may end up being valuable to you down the line.

In Brian’s case, the existing technology in his first job was a collection of system scripts and tools for database management, and the emerging technology was web-based applications. By the time the first web browser and CGI-enabled web server became widely available, he was already familiar enough with the relevant concepts to quickly wrap his existing tools so that they could be accessed and managed over the Web.

This was a big deal at the time, because it meant that there was finally an easy way to make software available at scale without having to physically manage local installations. As Brian helped various departments throughout Dartmouth build systems to replace tedious paper processes and overly complicated Excel-based workflows with web applications, the demand increased to the point where the university created a dedicated position for him so that he could step away from general IT support work and focus exclusively on web development.

Using some new technology to solve an existing set of problems in a better way is a commonplace story—but whether that goes smoothly or chaotically depends greatly on how it is approached. Many rush into trying the next big thing while still struggling with the strains of their day-to-day responsibilities, and that doesn’t tend to work out well. But if you can clear the decks first, there are lots of opportunities to learn about new technologies before you make the jump.

So that’s the first step in sustainable growth: minimize all the leaks and friction points in the work you’re already doing, so that you can keep an eye on where you’ll be headed tomorrow without getting overwhelmed by today’s responsibilities.

Design efficient processes before trying to grow your team

Fast-forward a couple years to the late 1990s, and now the Web isn’t just some interesting new toy that highly technical people are playing with, but it’s a practical and highly demanded information sharing platform. In the academic setting that Brian worked in, this meant that many departments, organizations, and individuals wanted to have their own websites up and running, and it was his job to help make that happen.

Initially this started as a relatively small responsibility which boiled down to helping manage the various static sites people were building, and sometimes helping them find student contractors that could help with the actual website development. But as demand sharply increased, these administrative chores piled up and distracted Brian away from his more interesting custom application development work.

Seeing that he was spread thin, Dartmouth gave Brian permission to hire someone to help him out with the website management work. Most would have jumped on this opportunity immediately, but instead, he hesitated.

Brian’s concern was that a good portion of the work he was doing was much too one-off, and so what actually seemed on the surface to be many unique problems were just a result of the ad hoc nature of the way things were currently being handled. Recognizing this problem, he decided to hold off on hiring someone to help until he could first put in place a process that would form a solid baseline that he could, as he put it, “optimize the hell out of.”

This is a powerful insight that many organizations seem to miss, or at least fail to take proper advantage of. When you’re hiring new staff members to increase overall capacity, especially in the face of rising demand, successful results depend largely on how efficient your existing process is.

In a disorganized environment where things are not so easy to learn and the people who could teach them are too busy trying to get their own work done, a new hire can eventually help turn things around, but the immediate impact on overall output will be minimal or even negative. And if demand is spiking quickly enough, then a vicious cycle can happen where many new people are joining a team and the complexity of coordinating everyone’s work skyrockets, but the overall efficiency of the team goes down even further month by month.

By contrast, the best work environments are ones where the learning curve is effectively flat, and there are ways for individuals with relatively little specific training can quickly become productive.

So this is what Brian set out to do: he gradually designed and implemented a streamlined process for Dartmouth’s basic website management needs, over the course of about a year. He did this little by little alongside his other work responsibilities, but each small optimization went a long way and helped relieve the immediate pressure of hiring someone new.

When things finally reached a relatively stable crossover point, Brian was able to take the time he freed up to hire and train someone to help take care of the day-to-day website management responsibilities.

Look at the big picture to find global optimizations

With a big chunk of his time freed up, Brian shifted his focus back to custom application development. This work quickly became complex and varied, as more projects started to come from larger departments within the university rather than the small ones he had started out with at first.

Soon enough, the talk of hiring started again, and so Brian once again got to work on trying to optimize things as best as he could before bringing someone new into the mix. This was a more challenging problem, but he eventually got it sorted out, and successfully brought in a new employee to help carry the load on the custom development side of things.

At this point, Brian had essentially “hired himself out of” the bulk of his routine day-to-day responsibilities. The two main areas he had handled (sysadmin work for the school’s various websites and custom application development) were now being taken care of by well-trained staff who were using the highly-optimized processes and tools he had built for those purposes.

This is an interesting transition point, because it is where a lead developer can finally begin to put their full focus on research, optimization, and supporting the needs of their staff.

In his own words, here’s what Brian had to say about the switch from day-to-day development to big picture thinking:

“What I didn’t realize before this point was that of the six or eight core problems that the various departments had, they were all solving them in slightly different ways just because of how they had set up their original processes. But then I was able to finally take a step back and abstract that away… and say ‘Well, this new problem is a version of something we’ve already solved. Let’s figure out what the vocabulary is, let’s figure out what the important differences are, and then let’s reimplement what we need to so that we can use our existing tools to solve it.'”

It’s at this point in the team building process that it becomes clear that it is much easier to be an effective navigator when you have others around that can help with the driving, and when the road you’re traveling on is well paved.

Remember that patience can be a virtue

Before Brian wrapped up at Dartmouth, the two teams he started had grown to support four full time developers each. It’s quite likely that those teams would have needed to grow much bigger and faster if there wasn’t a strong emphasis on process and technology improvements at each critical inflection point along the way.

To take that point a bit further, the main lesson to be learned from this story is that growing a development team is not just about quickly finding the right people and training them well—it’s about the deep interconnections between people, processes, and technology—and how each dimension influences the other over the long haul.

The idea of patiently sanding down the rough edges of a problem space so that others who may join your team later will have a better environment to work in is both compassionate and skillful, and it’s something we all can do if we just put in the effort. And that to me, is the essence of sustainable growth.

AUTHOR’S NOTE: I’d like to thank Brian V. Hughes for letting me share his story in this article. These days, he is taking a similar approach to sustainable team and technology growth as lead developer at HashRabbit, a company that is building monitoring and management systems for massive Bitcoin mining rigs.