Illustrated by Matt Peet

John Jung, Director of Engineering at API workflow infrastructure company Nylas, motivates himself by tackling big, complex problems. “To solve really difficult problems, you need to come up with all kinds of solutions,” he says. “The best ideas win.”

Those ideas can come from anywhere in an organization. More to the point, they can come from anyone. To get those ideas to the forefront, tech leaders need to create psychological safety. 

But psychological safety is not the only necessary component. “You gotta also be a little bit weird,” John says.

Often, being weird means being left out. John felt that way growing up, but along the way he began to realize how to own his weird: “I could just be myself,” he says. “Be a little weird. Accept it. Embrace it. Be nerdy.”

That’s the freedom he wants for everyone on his team. And it makes sense at Nylas, which makes it easy for customers to customize their experience on top of a single centralized API for emails, calendars and contacts. Individual style is the name of the game.

“When they’re allowed to be the best version of themselves and be open about it, then they can really thrive,” John says. “And that sources creativity for these really difficult problems that we’re solving.”

In this interview, John discusses the actionable ways he allows his teams to thrive in their weirdness—and to customize their work to maximize their creativity. Tailoring a system for weird people (or letting the weird people tailor the system) means that it will be weird itself. The results won’t look like the systems in other places. And that’s the point.

Creative workers tend to chafe against systems that constrict their abilities and interests. Uniformity is antithetical to creativity, and it also deprives John’s team of the diverse solutions they’re capable of creating.

So he largely empowers them to control their own environment. 

“If you want to be the best version of yourself,” he says, “use the tools you know.” After all, the value of a tool isn’t defined by its price or even its use in an organization. “A twenty-dollar-a-month tool will increase your productivity by a thousand percent over that really expensive tool, if you know how to use it and use it well,” he says.

But establishing an environment goes beyond having a cherished red stapler on your desk. People are the most significant component of an environment. And while they say you can’t choose your coworkers… well, John’s team does.

“To come up with the best ideas, you need to have a lot of different perspectives,” John says. “At the same time, you also want to make sure that it’s a cohesive environment. That personalities are compatible. So when you’re scaling up a team, you want to have people be a part of the interview process. They might see things that you might not see. And they might not, but you still want to make sure that everyone likes to work with each other on a daily basis.”

John explains that each of his engineering teams is different from one another, and they all have different strengths and gaps. They’ve each cultivated their own personality. So adding people to those micro-ecosystems is a deliberate process. It takes more time than many other company’s hiring processes, because adding new team members alters the environment—and he believes that the best determinants of compatibility are the team members themselves.

“You want to make sure that anyone you’re adding to the team helps it grow organically,” he says.

Even while granting developers control of their environment, John recognizes the benefits of structure to holding a productive, creative space for his teams. Frameworks give engineers a context to work within, a shared language of sorts and they also define each engineer’s individual needs to the rest of the team.

These are John’s strategies for offering structure in ways that maximize creativity for his engineering teams, rather than constricting them.

“You can’t force creativity,” John says. “Engineers will get excited about a problem, especially when it’s difficult. And you want to fan those flames—creating an environment where people thrive.”

And certainly not everyone thrives in a standard 8-to-5 workday. Some engineers do their best work in the early morning; others are night owls. So John asks his developers to block off their best work time. No one can schedule meetings with them during that time. That’s sacred ground.

“That is when you are coding or thinking at your best,” he says. “Ultimately, that’s best for you to be productive, and it’s best for the company.”

Some structure is necessary within an organization—otherwise, it’s not an organization at all. “With alignments, you have to have meetings, you have to have documents, you have to have a single source of truth,” John says. “Otherwise, we're just running around.”

Teams need that alignment toward a single mission. So any process that serves teams as a beneficial tool in reaching their goals has a place. But those processes may look different on each team, if they’re allowed to determine what works best for them and discard what doesn’t—a lot like John’s idea of the $20 tool serving a purpose better than a $2000 one. 

“I try to keep the processes lightweight,” he says. “A lot of different teams have their own way of operating. You don't want to create a process just for the sake of creating a process, or you don't want to create a lot of these documents just for the sake of creating a document.”

In John’s experience, too many imposed processes end up cluttering a creative space. People tend not to remember ideas that are over-burdensome, unnecessary, or just plain excessive. They’ll remember the purpose and the end goal, and the middle becomes mush. “Keep the process lightweight for people to actually remember and use it,” he says.

A more traditional leader’s objections to this lean and individualized approach to structure might come down to deliverables. How can this weird system ensure that teams will produce what needs produced? That’s why rules exist in the first place, after all.

John always emphasizes creativity. Give developers the freedom to create in ways that work best for them, and they will reciprocate by flexing their creative and technical talents further. That said, he acknowledges there are good times for trying new things, and other times when teams need to ship.

“We try to keep a healthy balance on both sides,” he says. “When you’re trying to tackle new problems, you want high iteration cycles. Code a little bit, see what it’s like, because there’s a lot of uncertainty. And as you work through it, you unravel these problems. That is going to take a lot of time, but it isn’t going to take a lot of time.”

At some point, the idea is for the team to choose a solution, double down on it and get it shipped. But that process happens so much more quickly because of the creative freedom and safety supporting it. “The only way you're going to do that is if you have high iteration,” John says. “Fail quickly, fail fast. And you only do that by learning by doing. Whether it's a new framework or a new product, just get your hands dirty and start doing it.”

Structure and process aren’t just for shipping, of course. They’re also key tools for running an engineering team or organization. And John recommends ways of personalizing those tools to maximize leadership potential, as well. Working with developers on their own terms keeps this entire individualized approach true to each of their own weird selves.

John’s developers block out their most productive times. But that doesn’t mean the rest of their work day is subject to whatever systems are demanded of them. Think of all the other necessary components of the job beyond coding. Developers’ needs in these arenas are as diverse as their creative needs.

“We personalize and adapt one-on-ones,” John says. “Some people want more meetings and want to talk since they need support on certain things. Some people just want to get to work again. Every person is different.”

This personalized approach extends beyond work life to recognize personal lives. “You want to create an environment that’s very compatible with their life, as well,” he says. “People with kids at home only have certain windows of time. There are lockdowns [during the COVID-19 pandemic]. You want to adjust for all of that.”

Continuous improvement is also critical—not just in products, but for teams and individual developers, too. John makes sure that his team members are benchmarked against themselves, rather than an outside standard.

“Every week you want to have one thing to improve in the process, or you want to focus on one theme for that week. One thing that you can get done,” he explains. 

He stresses that this is one way to ensure that the creativity stays alive. Engineers are generally a motivated bunch, and while some healthy competition can build camaraderie, they are more like solo athletes looking to improve their performance against themselves.

“You’re personalizing the process for them,” he says. “You want to create this environment where they’re at their best as much as possible.”

John developed his philosophy and approach to personalized experiences through making a lot of mistakes in his own career. He’s worked with several startups, each of which had really talented people doing good work. Yet some of his own mentors offered advice that didn’t work out for him.

“They suggested, ‘You’ve got to show leadership and you’ve got to do it this way,’” he recalls. “Maybe it’s my personality, but it didn’t work for me. I just haven’t gotten the same results that they might have gotten.”

So he developed his own style of leadership. He tried new things, found what worked and what didn’t and iterated on his experiences—just like he expects from his engineers.

Leadership, according to John, isn’t about following a specific set of practices. “Be the best version of yourself,” he says. “Do the thing that’s working best for you. That’s that.”

This tech leadership model for weird people could plausibly run into friction from a company’s C-suite. Because… well… it’s weird. Even “normal” development is a black box of sorts to executives who aren’t from a tech background. The sort of space John allows, with its flexibility in pursuit of creativity, isn’t always in alignment with more standard business practices.

He has to present the value of this model in order to allow his team their freedom. In that regard, data and metrics are his friend.

“We are a very data-driven company, so you can see results,” he says. “This process wouldn’t work if people weren’t coding at a certain velocity. Creating this engineering culture where people can be at their best should produce results that speak for themselves.”

Part of the challenge is framing unquantifiables like “hard work” or “urgency” as metrics. John can spot related trends in statistics such as the number of commits happening in a sprint. Ultimately, though, he points to the results. 

“Everyone has deadlines. Everyone has goals that they need to hit,” he says. “If we're consistently blowing those numbers out of the water, then that is justification.”

The numbers help teams like John’s gain buy-in from other stakeholders, and the performance data informs the directions they take with development. Think of it as a data-driven creativity model, where information helps decide which strategies work and which levers to keep pushing. But he never allows his team of individuals to be reduced to metrics themselves. 

“The data isn’t the full picture,” he says. “People aren’t data points on a map. But it’s enough for people to see that this kind of engineering culture is working. It gives enough of a picture for the justification of this kind of process.”

John might be the first to tell you that his strategy for leading weird teams won’t work for everybody. After all, not every engineer is the same. Not every organization is the same. And certainly not all leaders are the same.

That said, his leadership experiences have helped him develop some strategies whose foundations can prove useful to tech leaders in any situation—because after all, we’re all at least a little bit weird.

• Teams thrive when developers are in charge of their environment. That means giving them latitude to use the tools that work best for them. And since team members are the biggest component of a working environment, John includes them in the hiring process for new additions to their teams.

• Structure should be used to enhance creativity. A one-size-fits-all approach to structure inhibits the diversity of thought and the variety of needs on a team. John’s engineering teams block off their most productive times to preserve them for coding and problem-solving and keep processes lightweight by utilizing the ones that work and avoiding extraneous ones. In the end, their creative freedom bolsters their ability to deliver when it’s go-time.

• Leaders can individualize the developer experience. This point extends those previous ideas from engineering processes to leadership ones. Leaders can personalize approaches to 1:1s and other scheduling requirements to each developer’s needs, benchmarking them against themselves instead of some outside standard. Plus, leaders can individualize their own leadership style instead of going by-the-book with what works for other people.

• A data-driven approach can inform and shape creativity. The right metrics can give an impression of a team’s work ethic and demonstrate the results of its process. These numbers can help with buy-in from company executives and other stakeholders, especially the ones without tech backgrounds. Though people are not data points, creativity cannot be quantified and data serves as an ally to support developers’ efforts.

And as a final takeaway—an idea that threads through every piece of this interview—John stresses the importance of adaptation and iteration. 

“The world is obviously changing quite a bit,” John says. “So we need to adapt. A lot of things that worked in the past have gotten results. But I think now things are shifting.”

Adapting to individual team members, to personal leadership styles, to organizational goals, and to changing times, iterating along the way: Each one is critical to improve, grow and maximize the creative contributions of an engineering organization.