One of my proudest accomplishments during my 5+ years at Medium was a technical project, but it wasn't the technical portion of it that I was most proud of. In fact, there wasn't anything particularly technically challenging about the project at all. In this post, I'll share with you a behind-the-scenes look into this project — what non-technical work went into making it successful and the leadership lessons I took away from the whole experience.

It was a tedious chip-away-at-it project to standardize our backend. Over the years, there had been several standardization attempts, but the furthest anyone had gotten was perhaps a 10-15% conversion — just enough to plant a temporary stake in the ground to show other engineers what was the “right way” to do things. Unfortunately, the ground was littered with temporary stakes, and the result of several 10-15% efforts piled up was that it was ever more difficult to figure out how to build anything the “right” way.

In fact, if you had been trying to build an end-to-end feature and had consulted with three different senior engineers on the team, you would probably have gotten three different strong recommendations on how to build it.

The goal of the project I undertook was to create a high enough level of code consistency so that anyone working in the codebase would immediately know the best practices of how to work in each layer.

What I was most proud of was not the technical undertaking, but the alignment and communication required to amplify the importance of such a project, as well as the creative ways to get engineers onboard with arguably dull and tedious tasks.

Here are a few key lessons I want to share with you.

Communicate strategically with executives

A few months into this project, I walked past the CEO in the hallway.

“Hey Jean, it's been awhile. What are you working on these days?”

Rather than responding that I was working on an extended refactoring project, I replied: “I'm working on a large project to make product development a lot faster for existing engineers, and to make onboarding the 5 new hires starting in the next two weeks a lot faster.”

“That sounds great — I'm so glad you're working on that,” he replied before continuing on his way.

By framing what I was doing in language that he cared about, I built trust in the engineering team from executives.

I share more about this type of communication in How to Get Buy-in for Reducing Technical Debt.

When you're communicating with executives, consider:
What's the impact of your project, in terms that they care about?

Explain the project in non-technical terms

I really wanted the rest of the company to understand how important this work was — that it wasn't “just refactoring.” I spent some time thinking through ways to adequately convey the impact of the project, and then I published an internal post describing this scenario:

Imagine that you ask a librarian for help finding a specific book. The librarian shares that for a long time, all books were sorted alphabetically by title. But a few years back, to facilitate research by topic or genre, someone had re-organized some books by genre. And then recently, another librarian decided to start categorizing by author. So there are a few different places to check for the book. It takes you and the librarian three hours to find the book!

The library is like our codebase that is under active development. Of course, there are chunks that are rarely touched, but most areas of the codebase are constantly changing. Bugs need to get fixed, new features are added—and the overhead of figuring out what’s going on (and then how to do make changes) in the aggregation of 3–4 inconsistent systems is painfully slow.

After setting up that context, I further extended the analogy to explain what it was the project set out to accomplish:

This project is doing the work of recognizing that the speed of fulfilling requests (or in our case, building features) is so high because the layers of different half-baked systems makes it nearly impossible to find books quickly. The project is the equivalent of choosing a simple standard to adhere to — perhaps sorting all books alphabetically within the categories of fiction, non-fiction, reference, etc. Once that’s done, it will become more clear what to do within each of those buckets (if anything). Maybe we’ll find that reference books will only take up a shelf so we’ll leave them be. But if they take up 2 floors, we’ll have to consider how to sort them in a way that makes sense. And maybe, if it makes sense resource-wise and ROI-wise, we can even set up more tooling like a computerized system.

I mitigated concerns that “refactoring” was impractical or unnecessary by explicitly sharing that the goal was not 100% consistent code. We all agreed that we needed to move the product forward quickly. But moving the product forward by yelling “Faster! Faster!” to the librarians running through the stacks was not going to solve the problem. Your librarians could run 4-minute miles, but they still wouldn’t be able to consistently find a book in under 10 minutes because the layers of categorization systems were too inconsistent and complex.

With this analogy, I was able to bring others into my passion for this work and successfully share context and importance of a very technical project.

So when communicating with the company, consider:
How can you successfully convey the impact of your work to non-technical colleagues?

Gracefully navigate being pulled in different directions

When I took on the project, I was apprehensive — I felt like there were several other engineers more opinionated (which I took to mean more qualified) than myself about how everything should work. My manager reassured me that it was exactly because I was not very opinionated about it that he knew he could trust me with the project. When it was announced that I would be taking it on, I fielded several extended white-boarding sessions with enthusiastic engineers who wanted to tell me the latest and greatest about graphQL.

When I had absorbed all there was to absorb about graphQL, it was clear to me that without first creating some level of consistency in the current codebase, moving in that direction would be yet another temporary stake in the ground — a well-intentioned effort that ultimately created more confusion.

So I wrote up a technical design document with my proposed changes. Before publishing it widely, I explained in-person to the graphQL enthusiasts why we weren't going in the direction they had pushed for. I expected pushback, but what I experienced was overwhelming support and gratitude that I had taken the time to hear them out before making an informed decision.

When you're being pulled in many different directions, consider:
What's a starting proposal you can put out there? What key stakeholders or interested parties do you want to share it with first? Who just wants to have their perspectives acknowledged and heard?

Get engineers onboard

The project was quite tedious, and unfortunately, not quite as glamorous as, say, building a new feature that would be presented at a company all-hands. To make the backend consistent, we wanted to convert and remove 400 graph nodes —  essentially labeled functions used for asynchronous dependency injection. I didn't expect most engineers to want to work on this, but I figured if I sharded the tasks appropriately, I could convince a few people to pitch in. I took on the administrative work of creating a spreadsheet with all 400 tasks and asked people to put their name next to any they were actively working on. When they marked it “complete,” the entire row would turn green. Over time, the spreadsheet became a satisfying green hue.

Every few weeks I organized a “one-dayer,” a one-day effort to knock off a chunk from the ever-decreasing total. In the meantime, my coworker and I chipped away at it daily. The one-dayers were as fun as a tedious task could be. We would all get in a room, have some snacks, and for that day, feel like part of a makeshift team working toward a shared goal. It's simple, but these types of groupings can be very powerful to break through the mundane nature of this sort of work.

When trying to get engineers to work on tedious or less glamorous work, consider:
What are some ways to group the work into short sprints to make it more interesting?

Foster a healthy engineering culture

So I personally love refactoring and code deletion, but I've found not all engineers have the same passion. And while I loved working on this project, I didn't want the codebase to be in this state regularly. I realized that if I always did this type of work myself, I would be constantly refactoring, and the rest of the team would take away the lesson that I'd clean up after them. Though I did enjoy it myself, I really wanted to foster a long-term culture where engineers felt pride and ownership over this type of work.

I wrote an internal post called “The Life-Changing Magic of Deleting Code” — back in 2014, long before Marie Kondo's Netflix show started airing and people started joking about whether or not code sparked joy on Twitter.

I started a slack channel and started posting github screenshots that had high ratio of lines of code deleted to those added, with celebratory emoji. Soon, more people started deleting code and posting their own screenshots. To this day, people still will screenshot code deletion pull requests and text them to me, or tag me on twitter.

When trying to shift the culture of your engineering organization, consider:
What are some ways to make the desired behavior more fun and enjoyable?

Know when to stop

I love reducing technical debt. I love it! But I also know that it's possible to get carried away. To never ship the thing because there's always one more thing to refactor. To aim for perfection in a codebase that is always changing. It was important for the project to have an end.

So I also knew when to put the last bits in a file labeled “legacyGraphNodes.js” and call it a day. They were the rarely changed graph nodes that were so entangled that it would require immense effort to convert them. The return on investment for converting them was low. Over the years, we would sometimes convert a few of them in our spare time, but for the most part, working on them didn't contribute to the aim of the project — for there to be enough consistency for engineers to have clarity on how to work on each layer of the codebase.

When you're taking on engineering projects, consider:
What are the goals and non-goals? Where might you need to resist temptation?

This is the behind-the-scenes work of tech leadership — the cat-herding, the managing up, the motivating, the organizational admin work.

There were plenty of times in my transition to leadership that the projects I worked on weren't successful in this way. Perhaps the team's execution was good, but I didn't communicate to the rest of the company about the team's impact. Or I didn't align the team successfully towards the shared goal, so it felt like we were all in a boat rowing vaguely in the same direction.

This type of behind-the-scenes work is a huge shift from individual contributor work, where perhaps most of this alignment-building is being done by your tech lead or manager. And almost none of it is technical. It's about knowing what motivates people, what they care about, what their concerns are — and then building alignment — within your team, with the company, with execs, and with other engineers.

In our Co Leadership courses, we find that variations of this situation show up when we ask participants what they most struggle with at work — at a certain point in our careers, it's not so much the technical challenges that are most challenging, but rather the communication and alignment issues. This may show up as:

• getting buy-in from product or leadership for maintenance work or reducing technical debt
• getting buy-in from their manager to invest in a new technology
• getting another team to build something your team needs (that's not clearly a priority for them)

One recent participant reflected on his experiences: “I had always looked at leadership in particular and soft skills in general as an art or just plain natural-born talent. After attending this course, however, I am convinced that there can be an element of structure for soft skills as a whole and that there are efficient tools to be an effective technical leader.”

What about you? What are some of the non-technical aspects of your proudest accomplishments at work?