Portfolio Planning Made Simple

Lessons in Motivating and Mentoring Your Development Team

Posted by Madeline Scott on 8/3/17 11:31 AM

Create an Environment that Thrives on Strategic Innovation

I had the chance to speak with Ryan Gay, our Chief Technology Officer at Decision Lens, and learn about his approach to mentoring, hiring, and leading a successful development team. With over 15 years of software engineering experience, Ryan is a major force in the innovation process at Decision Lens.

Maddie Blog - Ryan Gay.jpg
Q: To give our readers a basic understanding of a development team, what are the types of roles and jobs you might find?

A: At Decision Lens, we have a mix of user interface, back end, test automation, and DevOps engineers of varying levels of seniority. Though most of our team members have specialized in a single technical area, we do have a few full stack developers, and are investing heavily in developing cross-functional skill sets in all team members. We find that the more areas a developer can contribute in, the more efficient and productive our entire team is, and the more opportunity developers have for professional growth.

Regarding seniority, you will find roles such as a standard level developer, somebody who is doing well at executing tasks, maybe they’re not leading huge initiatives by themselves yet. As they gain experience and establish a track record of high performance we give them more responsibilities.

Then we have our senior level developer or engineer, who still may not be directly managing anybody but has shown that they have a very strong level of experience within their area of expertise, they’re a go to person. They are likely also contributing in one or more other areas. Much of their focus is on executing on their tasks but they are also contributing to design and architecture to tackle big picture initiatives. Not only are they doing a lot of coding and testing, they are also constantly looking at tools, processes, and methodologies and asking themselves “How do the pieces of the product development puzzle fit together?”

And then there starts to be a bit of a divergence as individuals decide how they would like to direct their careers further — are you somebody that has the aptitude for mentoring, coaching, and managing others’ careers? Then you may head down the management path. Alternatively, are you an individual that wants to continue on a technical path and be the expert in a specific area, or ideally, multiple cross-functional areas? On our team, we try to create career paths that are appropriate for the strengths and goals of an individual, and not force anyone down predetermined paths as the only way to advance. We also dispel the idea that you must be managing people in order to advance.

Regardless of titles, we try to run our team as flat as possible so all team members have the opportunity to not only execute, but to lead as well. I feel it’s very important to find ways for everyone to lead, not just the most senior developers, so that all team members have a strong sense of ownership and accountability for team results. When everyone on the team feels like their voices are heard and are really bought in to what we’re doing, great things happen.

Q. How do you incorporate and reinforce daily goals and objectives without losing sight of more long-term career development initiatives?

A. The ongoing goal of our development team is to become as effective as possible implementing products that move the needle for our business. It’s a challenge that drives us to look at our technology, processes, individual skill sets and figuring out how we can do things better. In our day-to-day work, we are constantly looking at what we can do to move faster, to write higher quality code, to reduce bottlenecks and churn. We have a strong cultural mindset of constant improvement and our agile methodologies allow us to rapidly introduce positive changes to our development processes.

The career goals for our team members are typically well aligned with how we drive change on a day-to-day basis. Everyone is given the opportunity to lead on our team, to introduce, manage, and execute on changes that drive progress. The more an individual proactively steps up and owns a design challenge, a process improvement, a new core capability, anything that is helpful to the team, the more opportunity they get for advancement.

The managers on the team focus on individual career development in an organic way as part of our development flow. Our teams are small and our pace of development and change is fast, so everyone’s contributions are highly visible and there are many natural opportunities for managers to observe their direct reports and shape career goals. We are sure to use 1:1s with our direct reports to make sure we have regular touch points, and we also do light quarterly reviews, but the day-to-day interactions and observations of leadership and execution are the best indicators of career progression. We value immediate feedback in the flow of development over periodic performance reviews.

Of course, there also has to be the opportunity within the business to make room for career growth and promotions. We don’t promote for the sake of it, but we do everything possible to reward those that have demonstrated the ability to handle responsibilities outside of their current role. When the growth of the company allows for promotions, we look at those individuals who have excelled at their role and also have success at handling next level responsibilities.

Above all, we try to give everyone the opportunity to step up and do more than what they are currently doing and to trust them to do those things and usually when we do that, the team responds very, very well and results in promotions taking place on a regular basis. I think one of the big reasons we enjoy a very low attrition rate is because we allow team members to proactively take on new responsibilities and we are sure to reward them for their efforts as much as possible.

Q: How do you motivate your team?

A: I think most developers are motivated by getting to work on interesting projects with other talented team members. They like to learn new technologies and take on bigger and bigger design challenges. They like to have a voice in how their work is organized and executed, and they want to be trusted. Trust is huge. It doesn’t work to give a person a larger level of responsibility and then micromanage them. When working in an environment that has a high level of trust across the team, I find that most team members will confidently seek out opportunities to lead and take on more responsibilities. It’s contagious – when team members observe others successfully learning new skill sets or taking on additional responsibilities, they are driven to do the same. We use a culture of empowerment and trust, investment in skill sets, and the delegation of bigger responsibilities to incentivize everyone to perform at their highest levels. We’re also able to cultivate a sense of ownership and accountability for results across the team.

Q: During the hiring process how do you identify characteristics that are important in a team member?

A: While we definitely ask plenty of technical questions and often run through development exercises, I tend to ask questions about how that person operates within a team, how they contribute to team improvements, how they respond to change, how they take ownership of their responsibilities. I’m often more concerned about team fit, the ability to learn and adapt, the ability to lead than I am about specific technical skill sets. Whatever skills the candidate has developed in their career, I look for the ability for someone to confidently describe what they do in depth and for understanding of how their contributions fit into the bigger picture. I tend to ask people questions like “Describe the day-to-day process and dynamics of the last team you were on. What worked well? What would you have changed?” I’ll ask them to describe situations where they have been handed assignments outside of their normal responsibilities, and when they proactively took ownership over a team process improvement or managed a difficult personnel situation. The goal is to determine whether the candidate is only comfortable executing tasks, or if they eagerly seek out and respond well to opportunities to learn, to lead, to drive change, to contribute to the bigger picture. These are really important qualities for our team.

Q: During a recent presentation at “Get Your Full Stack On,” you said “No process no matter how well it works, will not work forever.” Are you deliberately trying to break your current processes or looking for a natural trend of what is no longer working?

A: We aren’t deliberately trying to break our processes, nor is it often obvious when established processes are holding your team back. We just make sure that when we establish a process, we do it in a self-organizing way, where everyone on the team has bought in, then the team is getting a process because it works. It’s not a process for sake of process. It’s there because it’s helping the team be more effective and productive. Once team performance starts to plateau, you need to try something different, otherwise it’s very easy to become complacent and you can get blind to inefficiencies. In the technology world, if you’re not innovating, someone is going to out innovate you, but there’s also a lot of thought leadership freely shared in the development community. We try to take advantage of the lessons learned in other organizations to drive how we improve our processes. To avoid being stuck in a rut we like to reflect on how we are doing things and take some time to see if we can improve and become better. Especially at the beginning of a new development epic, we’ll take the time to question everything we’re doing, and then make adjustments on the fly. Things evolve all around you, in your industry, in technology, and if you’re not checking in periodically, you’re missing out on the opportunity to do something better.

Q: What is your favorite team that you have ever been a part of or been a fan of? (Both real and make believe teams are acceptable answers).

A: Besides the Decision Lens team that I am a part of currently, my second favorite team would be my crew team that I was on in high school. It was my JV crew team, and we were a pretty new team, without any rowing pedigree, and we weren’t very large physically.

We ended up winning the Georgia State Championship. We had never won a tournament before but it all came together for the state tournament. That was a memorable team.

What do you think makes a powerful development team? We would love to hear your thoughts.

Do More with Your Data
A blog about strategy execution problems and solutions.

We are passionate about problem solving and bringing your strategy execution to life.

Improve your real-time response to portfolio problems with industry leading innovation and case studies.

Readers of this blog:

  • Better define portfolio outcomes

  • Easily tie business metrics to strategy

  • React with the latest data + analytics