{"id":206,"date":"2017-05-02T22:12:30","date_gmt":"2017-05-02T22:12:30","guid":{"rendered":"http:\/\/thibaultklein.com\/ios\/?p=206"},"modified":"2017-05-08T02:09:12","modified_gmt":"2017-05-08T02:09:12","slug":"learnings-form-leaddev-2017","status":"publish","type":"post","link":"https:\/\/thibaultklein.com\/ios\/learnings-form-leaddev-2017\/","title":{"rendered":"Learnings from #LeadDev 2017"},"content":{"rendered":"

This post is co-authored with Max Mamis, Senior iOS Engineers at Prolific Interactive.<\/em><\/p>\n

At Prolific, we\u2019re 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<\/a> in Manhattan to improve our leadership skills. We learned a lot over the course of the daylong event, and we\u2019d like to share some of our key takeaways.<\/p>\n

Learnings<\/h2>\n

What is a Lead Dev?<\/h3>\n

Being a lead dev can mean a lot of different things if you ask around. Before going to this conference, we weren\u2019t 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.<\/p>\n

Be the Facilitator<\/h3>\n

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\u2019Neil in her talk \u201cYou\u2019re the Tech Lead! Now What?\u201d<\/a> 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.<\/p>\n

Know the Answer\u2026 Or Where to Find It<\/h3>\n

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.<\/p>\n

Perceive the Need<\/h3>\n

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.<\/p>\n

Be Thoughtful and Deliberate<\/h3>\n

Kevin Goldsmith explains in his talk \u201cFinding the Right Ingredients for Your Perfect Team\u201d<\/a> 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.<\/p>\n

Diversity<\/h2>\n

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.<\/p>\n

Lend Privilege<\/h3>\n

For tech leads focussed on fostering diversity on their teams, ensuring adequate representation isn\u2019t enough. It\u2019s essential for those of us with privilege to recognize it, and to understand its ramifications for those who don\u2019t benefit from it. Anjuan Simmons talked about the idea of \u201cLending Privilege\u201d<\/a>, 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\u2019ll actually build better products.<\/p>\n

Build a Diverse Team<\/h3>\n

Kevin Goldsmith took the idea of diversity further than what we normally talk about (which he referred to as \u201chuman diversity\u201d). In his talk \u201cFinding the Right Ingredients for a Perfect Team\u201d<\/a>, 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\u2019d have in a totally like-minded team.<\/p>\n

Team Building<\/h2>\n

A lead developer isn\u2019t 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.<\/p>\n

Balance your Team<\/h3>\n

Kevin Goldsmith gave us lots of ways to think about a team to ensure it\u2019s 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\u2019m sure do many engineers. But Kevin made a great case for using them as a barometer for your team members\u2019 various strengths \u2014 so that a lead engineer can balance introverts vs. extroverts as easily as balancing experience with Swift vs. Java.<\/p>\n

Look Back<\/h3>\n

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

In her talk, \u201cLook Back, Move Forward\u201d<\/a>, Jessie Link presented a few alternative retro formats, ranging from the mostly-familiar \u201cFour L\u2019s\u201d \u2014 where team members list what they \u201cliked, lacked, longed for, and learned\u201d over the past sprint \u2014 to the awesomely left-field \u201cdraw the sprint.\u201d 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\u2019s deeper feelings shine through. It\u2019s basically art therapy for your development team.<\/p>\n

Facilitate Teammates, Everywhere.<\/h3>\n

At Prolific, we\u2019re big on being on-site. While individuals can work from home as needed, we\u2019re 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\u2019s talk about distributed teams<\/a>. They had some great suggestions for making remote employees feel included \u2014 for one, using the term \u201cdistributed team\u201d rather than \u201cremote employee\u201d to avoid thinking of local employees as the default. They also emphasized the importance of communication \u2014 and doing a whole lot of it, over the best tools available.<\/p>\n

Advocate for the Team<\/h2>\n

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\u2019t want a team where everybody is afraid of us, where nobody feels psychologically safe<\/a> to speak up and share ideas. We should lead by example and advocate for their team.<\/p>\n

Build a Culture of Trust<\/h3>\n

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.<\/p>\n

Influence the Change<\/h3>\n

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\u2019s for the best for them and the product. If a process takes too long, if some part of the application isn\u2019t optimized, if tests are missing \u2013 you\u2019ve influenced people to be engaged in their work, you\u2019ve empowered them, and if a change is required they will feel more apt to respond.<\/p>\n

Show by Example<\/h3>\n

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 \u201cLet\u2019s Go Home and Take Your Reports with You\u201d<\/a> 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.<\/p>\n

Time to Apply<\/h2>\n

What perhaps amazed us most about the conference was the sheer passion these people have for their jobs. It\u2019s comparatively easy to talk about a tech stack \u2014 put some sample code up on the screen \u2014 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.<\/p>\n","protected":false},"excerpt":{"rendered":"

This post is co-authored with Max Mamis, Senior iOS Engineers at Prolific Interactive. At Prolific, we\u2019re 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… Continue reading Learnings from #LeadDev 2017<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[3],"tags":[8],"class_list":["post-206","post","type-post","status-publish","format-standard","hentry","category-ios","tag-meetup","entry"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p6mZvu-3k","jetpack-related-posts":[],"_links":{"self":[{"href":"https:\/\/thibaultklein.com\/ios\/wp-json\/wp\/v2\/posts\/206","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/thibaultklein.com\/ios\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/thibaultklein.com\/ios\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/thibaultklein.com\/ios\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/thibaultklein.com\/ios\/wp-json\/wp\/v2\/comments?post=206"}],"version-history":[{"count":1,"href":"https:\/\/thibaultklein.com\/ios\/wp-json\/wp\/v2\/posts\/206\/revisions"}],"predecessor-version":[{"id":211,"href":"https:\/\/thibaultklein.com\/ios\/wp-json\/wp\/v2\/posts\/206\/revisions\/211"}],"wp:attachment":[{"href":"https:\/\/thibaultklein.com\/ios\/wp-json\/wp\/v2\/media?parent=206"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/thibaultklein.com\/ios\/wp-json\/wp\/v2\/categories?post=206"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/thibaultklein.com\/ios\/wp-json\/wp\/v2\/tags?post=206"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}