Three Legs of GSD

Recruitics has a culture that celebrates exceptional results. The expression "get shit done" or more commonly "GSD" has become something of a mantra around our office. We have GSD stickers and t-shirts. We even have a #gsd message channel where we call out peers who go above and beyond. 

When I first heard the phrase, my reaction was not positive. To me it seemed to encourage indiscriminate action and low-quality work. But as I have learned since then, there is a lot of nuance behind the concept - and it goes to the core of what makes Recruitics a unique workplace.

In this post, I want to use GSD as a lens to explain a little about our engineering culture. Of course, within Recruitics different disciplines and teams manifest GSD in different ways:

• A salesperson who calls a prospect on a Saturday afternoon with a carefully-crafted value proposition. 
• An account manager who obtains an industry certification that helps her better serve clients.
• An executive who researches a new market and relocates across the world to grow our business there.

But what does GSD mean in the more specific context of software engineering?

Contextual Awareness

It's not enough to just do technical work: it has to produce results that matter to the business and align with our mission. Context matters.

The company values are a good starting point for this: entrepreneurial thinking, doing things the right way, working as a team to provide great customer experiences, making data-driven decisions. As an aside, it's easy to play favorites on the values. Engineers always remember "data-driven" but some of the best work is really an extension of combinations of multiple values. For example, an engineer that takes extra time to fix a JavaScript bug she noticed on a client's career website would be both doing things the right way and providing great customer service.

I try to help build contextual awareness through both structured and unstructured conversations. For example, I hold a monthly all-engineering meeting that covers broad company topics from an engineering perspective. The engineering department also uses weekly one-to-one meetings for two-way information flow. I go beyond those basic structures to have one-to-one and small group conversations about emerging trends and our values. I sincerely want every engineer to know what's going on through meaningful two-way communication.

Professional Curiosity

It's easy to get in a rut and only do the things we already know. This can produce modest improvements, but when we want to change things by an order of magnitude, we usually have to think outside our personal comfort zone. Professional curiosity is the inclination to expand our horizons. Here are some common ways to build on this natural curiosity:

1. Reading technology blogs and books is a great way to gain a general awareness of additional technical domains.  Learning about how other people solve problems is a shortcut that helps us avoid common mistakes and take advantage of novel problem-solving techniques. Reading helps banish "not invented here" thinking and exposes us to great solutions to common problems.
2. Tinkering is another key aspect of professional curiosity. Great engineers often poke around in dusty source code, refactor unclear test cases and build experimental programs. We're driven to do this because we want to know how things work and make them better.
   
3. Our teammates can help too. Pairing an experienced engineer with an inexperienced engineer can lead to rapid learning, and not just when it comes to coding. I love to hire people who have more experience than I do in key areas, because I then get to learn from them and watch them work out those problems in ways I wouldn't have considered on my own.

Professional curiosity opens us up to new possibilities we wouldn't otherwise encounter. I try to encourage curiosity by giving special projects, bringing engineers to conferences and discussing new technologies. Providing the right frequency of changes in team assignments and project work is another key element to fostering curiosity in the engineering department.

Drive

Contextual awareness and personal curiosity provide a foundation of knowledge. We can't make any meaningful impact without this knowledge, but merely possessing it is insufficient. Knowledge must lead to action. This is where drive, or more simply initiating change, comes into the picture.

Previously I mentioned tinkering as a means towards learning, but it can also lead to a new tool or approach. Experimentation grows into initiative as assumptions are proven and mistaken thinking is purged through contact with the real world.

At some point, initiative requires overcoming the fear of failure. The key way to do this is to mitigate the negative consequences of failure. For example, if we move clients onto a platform that falls over under their load, that's not a great way to fail at scaling up that technology. Instead, we would want to look at scaling up in a way that doesn't impact the business in case of failure, such as running non-production systems in parallel with production ones or building prototypes with clients tolerant of the inevitable failures that come with experimental learning.

Building certain kinds of decoupled systems makes it easier to try new ideas out:

• Publish/subscribe architectures allow us to add additional consumers without impacting existing systems. Decoupled systems can be expanded and contracted with relative ease.
• API's allow rapid innovation on user experience. With a great client library for an API, new application interfaces can be built or changed in a matter of hours. It's important to have a well-defined data model, as it's harder to change the model than the user interface.

Beyond software architecture, I try to create an environment where thoughtful failure is okay. I'm far more interested in learning from mistakes than in assigning blame for them. I push the team to frame experiments in a way where we don't invest too much before testing ideas in meaningful ways.

Conclusion

If basic technical proficiency is the floor, we might think of GSD at Recruitics as a stool with three legs: awareness, curiosity and drive. I view each of these as necessary and complementary. Taken as a whole, they support not only for the company overall, but also individuals as we grow together.