Patrick Farnan on Dec 9, 2015 9:36:02 AM

Three Takeaways from The Lead Developer Conference, plus Some Frozen Yoghurt

TheLeadDeveloperBadge.jpgBack in September I was fortunate to attend “The Lead Developer” conference in London alongside my fellow Patrick “The Engineering Manager” Walker. It was a same day trip, but it was well worth an early rise and slightly sleep deprived night. Billed as targeting technical people that lead and motivating teams, it seemed to fit perfectly with my role as Principal Software Engineer leading a small team of four (three Developers and a Senior QA Engineer).  There were several main talks, each around 25-30 minutes, that included the captivating Dan North, as well as a number of 10-minute ‘lightening talks’ that provided a snapshot into an emerging technology. Beyond the talks, The Lead Developer even scheduled time for networking and lunch too!  My personal goal for the day was to learn how other tech lead folks cope with the additional responsibilities bestowed upon them as they move from the developer role into team management. I was also keen to see what new technologies where being picked up by other companies and how others did their job whilst retaining an understanding of technical changes. Fortunately, the conference did provide me with three takeaways.

1.  Reach Beyond Developer

SunriseFlight.jpgTwo of the main talks, one by Patrick Kua, and the other from Dan North, attempted to discuss and address how to adapt as one shifts from a role as a software engineer into one as a technical/team lead. In his session, Patrick talked about the challenges faced during the shift from software engineer to technical or team lead, including how to use your time and how to stay technically aware while enabling and managing your team. As a new tech lead, how should we decide between learning new technologies or trying to introduce innovation and focusing on delivering the product faster through tried and trusted platforms and processes? This is something I have faced since moving into the lead role, but it has helped that NaviNet’s Engineering Managers alleviate some of these issues from our day-to-day responsibilities. Kua also suggested some techniques to consider, such as reaching out to other team leads with in your organization or folks in a similar position. Personally, I’ve been able to use NaviNet’s internal Wiki which provides a standard platform for us to communicate across the company and have leveraged Skype for Business to have more direct communications or meetings.

Likewise, Dan's fascinating talk “Beyond Developer” addressed how to move from simply being a guy or girl with a few years C# experience to take on more responsibilities as a technical Lead. Instead of just picking up a language and writing some code, we technical leads are challenged with embracing the numerous other roles that fall into our laps. To lead a team we need to have a full awareness of the processes used by the organization and understand the various roles that exist in it, especially those roles that will need to collaborate with your team. Understanding other departments and stakeholders with whom you now need to liaise and communicate with on a more regular basis is especially important. Being aware of the platform on which we build is critical, as is knowing the path to production by considering runtime concerns in order to prevent unnecessary problems where possible.

North also made a good point about how and when to leverage automation. Automation can be beneficial but only when it makes sense. It isn’t a solution for everything and works best on a task that is repeatable, well-known and consistent in its execution to the point that it is mundane and boring. This was a good point, one which we often consider when deciding whether automation should be applied to an internal process.

Tech leads also need to consider that our teams are building products to meet business objectives. Knowledge of the domain in which your company works is key to this. Ignoring the industry trends that your company is in will not aide product delivery and more importantly won’t provide you with opportunities to contribute to it.  Fortunately, we have a really good awareness of both the product we’re building and, despite operating under a different healthcare model in the UK, an understanding of the industry. This is achieved by a number of means including onsite visits from our counterparts across the pond and regular (mostly optional!) meetings on a range of topics including Product Development/Direction, Market Changes and where we are heading. As team leads, we are also empowered to contribute to the product going forward during either Architecture Definition drafting, Analysis sessions or during our internal hackathon “Off The Grid” (more on that later!)

2.  Get the Right People

In addition to focusing on the transition from software engineer to a tech lead, “The Lead Developer” also highlighted how tech leads can attract developers and build their teams. One speaker, Sam Barnes, specifically discussed how to manage and make colleagues feel comfortable. According to Barnes, building a great team starts with hiring the right people. This requires being honest with candidates about the company’s good and bad points, and encouraging  them to be honest with you. This allows you to remove any falseness from the beginning and should lead to the right people joining your team for the right reasons.

Once hired, getting a team of great ‘individuals’ to gel and act ‘on the same page’ is a different challenge. Barnes again talked about the concept of a team charter, which is a means of giving identity to the team, communicated to both themselves and to those they interact with. The charter can consist of a team name, logo and core values defining what the team should be and what they believe in. With defined values the team strives to be happy or proud of their work.  Applying best practice can also allow all members, including new ones, to remember what they are striving to achieve and make them feel like part of a unit even within a larger firm.

This concept is not alien to NaviNet, our teams here have names and logo (I am a proud member of Team Meerkat). We also regularly undertake ‘Health Checks’ as well as project Kaizens to examine where we see our strengths and weaknesses. These have proven very useful in determining where we need to improve both as a team and as a company. Barnes has applied this concept further by having teams rate their performance using a spider chart across their values post each project. This graphically demonstrates, over time, where the team is meeting or not their aims. I hope to also try this on our team initially to see if it can aide us.

3.  Stay Ahead of the Curve

The importance of technical leads ‘keeping up’ with the game, as well as being aware of what is trending and what is emerging  is another takeaway from “The Lead Developer.” The lightning talks provided insights into how to stay ahead of the curve and were a nice break between the main segments of the day. Each focused on a new or innovative technology/approach such as Docker, NativeScript and Angular presented by someone with ‘on the ground’ experience. The talks were informative and gave some insight into the issues/lessons other people have encountering expanding beyond their previous technical knowledge.

Staying ahead of the curve is something we aim to be good at. In our Belfast office, we regularly host Brown Bag Sessions where anyone can explore, demonstrate and generate discussion on such areas. I myself recently took folks through a walkthrough of Graph Database, an area emerging as a key one for a lot of data driven companies. As I mentioned earlier, NaviNet also has an annual three-day Off the Grid (OTG) event where we are all empowered to present something new and different that can improve the company. In recent years OTG teams have looked at a number of the technologies discussed at the conference so it is good to see we as a company continue to play in the right space, and sometimes beyond it!

Final Thoughts

RussMilesGuitarSolo.jpgThe day was definitely very fruitful from my point of view (and the other Patrick’s). There were a number of other really interesting talks which I haven’t delved into, including one by Russ Miles on the pitfalls of Microservices that started with a guitar solo and ended with a marriage proposal (congrats again Russ!). Overall though I thought the conference structure and content worked well, with the lightning sessions to helping to break the day up. I would have liked to have attended some more hands on activities or sessions but these mostly took place the day before, which we were not able to make. The conference did help me realize that the issues/struggles I face personally as my role changes and we at NaviNet face, as a technology company in a rapidly changing industry, are not isolated or unique to us.  All companies striving to develop good software and to enjoy their work also face similar challenges and reaching out via blogs/forums will allow me to understand better how to manage a team more effectively, and retain an awareness of what is ‘coming around the corner’. I feel that as a company we are following a number of the practices and approaches discussed, although I tended to pick up a lot of this ‘on the job’ when I moved from Senior Software Engineer to Principal.

London.jpg

What About the Frozen Yoghurt?

As for the frozen yoghurt (or yogurt according our Boston office), I was able to sample this delicacy for the first time during the conference when visiting a Japanese noodle bar (how very cosmopolitan of me, I know). I can highly recommend it, like the conference, and NaviNet for that matter!

Interested in the career growth opportunities NaviNet offers its software engineers? We're hiring:

Apply Now

 

Tags: Innovation, Software Engineer Roles

Subscribe to Blog

NaviNet, part of NantHealth, is America’s largest interactive healthcare network. Our flagship multi-payer provider website is built on deep payer integration and the innovative use of technology to deliver real bottom-line value for both payers and providers.