This post is co-authored with Max Mamis, Senior iOS Engineers at Prolific Interactive.

At Prolific, we’re big on learning new skills. Usually we take that to mean technical skills but in February, myself and fellow engineer Max Mamis, attended the The Lead Developer Conference in Manhattan to improve our leadership skills. We learned a lot over the course of the daylong event, and we’d like to share some of our key takeaways.

Learnings

What is a Lead Dev?

Being a lead dev can mean a lot of different things if you ask around. Before going to this conference, we weren’t sure how to best describe what a lead dev is and what are the associated roles of the position. After hearing from talented leaders in the industry, we were able to identify some trends that can help answer this question.

Be the Facilitator

The first idea that came out of this talk is is the concept of facilitator. A lead dev should facilitate teammates work and make their life easier. There are always problems affecting a project, and we should be the one caring about those and facilitating their resolution without having the team affected. Eryn O’Neil in her talk “You’re the Tech Lead! Now What?” uses the metaphor of a lead dev as a wall protecting the team from a wave, and keeping them dry of all the project issues that could come up. This is a very interesting way to see how a lead dev can protect the team from all the noise around a project to keep everybody focused on what they do best.

Know the Answer… Or Where to Find It

One of the lead dev goals is to keep the team able to produce their best work in the best conditions possible. During project development, we will have to answer many questions, and it is our role to have the answers to keep the team working without uncertainties. If the answer is unknown at the time, we are responsible for knowing where to find it as soon as possible.

Perceive the Need

Finding out the answer when a question arises is crucial in order to keep a smooth development process; but, if you know of questions that will come in the future, a lead dev should not wait to find the answers. Instead, we should try to anticipate all the potential blockers the team might experience and document everything for them in advance, especially because some blockers might take time to get resolved. Doing so will give us a buffer and mitigate the risk of delaying development.

Be Thoughtful and Deliberate

Kevin Goldsmith explains in his talk “Finding the Right Ingredients for Your Perfect Team” that one of the most important things that a lead dev should do is to be thoughtful and deliberate. We should have good answers to every decisions we make. We should be able to very clearly talk about what we are doing. Finally, we should be strategic in our decisions, because every decision we make can have a huge impact on the project, the team, even the company. Being thoughtful will drastically reduce the chances of making the wrong decision; it will give us the opportunity to really think before making any decision.

Diversity

One theme that kept coming up during the day was diversity, in many forms. The organizers embedded their attention to diversity in the lineup itself. In a still male-dominated industry, over half of the speakers were women, and there were speakers from many underrepresented groups. It went un-remarked-upon during the day, but the positive example the organizers set for us as tech leads was unmistakeable.

Lend Privilege

For tech leads focussed on fostering diversity on their teams, ensuring adequate representation isn’t enough. It’s essential for those of us with privilege to recognize it, and to understand its ramifications for those who don’t benefit from it. Anjuan Simmons talked about the idea of “Lending Privilege”, retelling a story where Leonard Nimoy used his clout to win equal pay for an actress on the show who had been under compensated for years. Simmons made the point that commitment to diversity alone is not enough, and that, as managers, we need to commit to the idea of inclusion. This means not only making sure that all sorts of people are represented on our teams, but also that we have empathy for them and create an environment where their input is welcomed. By doing so, not only will we be doing right by our employees, but by encouraging more voices to be heard we’ll actually build better products.

Build a Diverse Team

Kevin Goldsmith took the idea of diversity further than what we normally talk about (which he referred to as “human diversity”). In his talk “Finding the Right Ingredients for a Perfect Team”, he stressed the need to build a team out of people with a diversity of personality and experience level. Bringing together engineers with contrasting approaches to problem solving creates a healthy balance, and can eliminate the blind spots you’d have in a totally like-minded team.

Team Building

A lead developer isn’t just responsible for managing individuals and technologies. A team is its own organism, and the choices we make as lead developers make the difference between a healthy and a sick one.

Balance your Team

Kevin Goldsmith gave us lots of ways to think about a team to ensure it’s well-balanced, and that members have complementary skill sets, outside of the technical arena. I have a tendency to think of personality tests as pseudoscience, as I’m sure do many engineers. But Kevin made a great case for using them as a barometer for your team members’ various strengths — so that a lead engineer can balance introverts vs. extroverts as easily as balancing experience with Swift vs. Java.

Look Back

A great team has to be self-reflective, or else they’ll never improve — which is why we conduct retros. But too often our teams just go through the motions without really digging deep into what’s holding us back. We’ve all been through retros where there’s tension hanging in the air, and everyone knows there’s a problem, yet when it comes time to list the positives and negatives, somehow everything is hunky-dory.

In her talk, “Look Back, Move Forward”, Jessie Link presented a few alternative retro formats, ranging from the mostly-familiar “Four L’s” — where team members list what they “liked, lacked, longed for, and learned” over the past sprint — to the awesomely left-field “draw the sprint.” In the latter, everyone on the team is handed a blank sheet of paper, and given the open ended prompt to draw how the sprint went. Though intentionally silly, the freeform nature of the exercise can let the team’s deeper feelings shine through. It’s basically art therapy for your development team.

Facilitate Teammates, Everywhere.

At Prolific, we’re big on being on-site. While individuals can work from home as needed, we’re decidedly not a remote company and even go so far as co-locating with partners on a regular basis. That being said, I learned a lot about the how to handle remote work from Maria Gutierrez and Glenn Vanderburg’s talk about distributed teams. They had some great suggestions for making remote employees feel included — for one, using the term “distributed team” rather than “remote employee” to avoid thinking of local employees as the default. They also emphasized the importance of communication — and doing a whole lot of it, over the best tools available.

Advocate for the Team

We, as lead devs, have a huge responsibility in a team. People will look at us whenever a problem shows up, whenever a hard decision has to be made, and the team will make us accountable. We don’t want a team where everybody is afraid of us, where nobody feels psychologically safe to speak up and share ideas. We should lead by example and advocate for their team.

Build a Culture of Trust

As a lead dev working with a team of talented engineers, you want everybody to feel comfortable in their work environment. You want everybody to open up when they feel the need. You want everybody to know they can count on you if something happens. You want the team to trust you. We are responsible for building the culture that we believe will make the team perform the most and make people go above and beyond for the product. By building a culture of trust, we have the ability to empower our colleagues and make them grow as a professional and as a person. Trust is the key to make a team performant because trust will make everybody move forward, not backward.

Influence the Change

By building this culture of trust, a lead dev will gather the team in an environment where everybody is shooting in the same direction to make the product better. This is where we can introduce change inside the team more easily. By having a culture where people feel included and responsible, we can have the team accept meaningful change, as long as it’s for the best for them and the product. If a process takes too long, if some part of the application isn’t optimized, if tests are missing – you’ve influenced people to be engaged in their work, you’ve empowered them, and if a change is required they will feel more apt to respond.

Show by Example

A lead dev can inspire people in a positive but also in a negative way. A lead dev always has to show by example regarding work ethics. Rafael Lopez Diez in his talk “Let’s Go Home and Take Your Reports with You” shares his experience as a workaholic, and how damaging it can be for someone to be in this situation. We should not work extra hours, because this is not only unhealthy for us, it is unhealthy for the team that will feel forced to work the same amount of hours. We should also be able to detect when someone works too much and provide the appropriate help to not only help them, but also demonstrate to the team that we will be there to support them if they go through a challenging time.

Time to Apply

What perhaps amazed us most about the conference was the sheer passion these people have for their jobs. It’s comparatively easy to talk about a tech stack — put some sample code up on the screen — but to break down a more amorphous people-focused role is a much trickier proposition, and these speakers all pulled it off with aplomb. It was a valuable, eye-opening learning experience for both of us, and we look forward to putting the knowledge to good use in the coming months. And, of course, to seeing what they have planned for next year.