ENGINEERING MANAGERS INTERVIEWS

#7 You Have To Slow Down To Speed Up by Brandon Parrott, Team Lead at Fyllo

Brandon Parrott is my fellow co-worker at Fyllo. Fyllo provides marketing and regulatory solutions for highly regulated businesses. And it is the second time we work at the same company, as previously we were both working at Outsystems.

The variety of topics we cover

Brandon and I talk a lot of topics related with the transition from a developer to a leader and also the motivation and avoidance of Developer burnout. We talk about leading a fully remote team — the team members in Fyllo never met each other face to face.

We talk about the importance of slowing down, so then we can speed up. How we can leverage the OCD of some developers into helping them avoid burnout. Why a design phase is important, talking about writing in development and the RFCs (Request For Comments). And last but not least, leading people by supporting them, a trait Brandon learned from our mentor, Robert Hucik, the EVP of Engineering in Fyllo.

Interview with Brandon Parrott, Team Lead at Fyllo

Full-stack Developer and a Product Developer

With Brandon we start by tackling the topic of a Full-stack Developer given what Luis Eduardo Castro said in the #1 interview about the Full-stack Developer being a true Product Developer:

“To me, a full stack developer is a true product developer. Someone that can understand what are the design needs, what are the business model needs and what are the product needs and how to deliver fast from the back end to the front end. So they can manage all the tools in the toolset and that also includes tools that are for Product Owners, tools that are for Designers, etc. So you can make decisions and judgment calls on things that aren’t your area of expertise but that you still have knowledge on that area.”

Luis Castro, Tech Lead, Cameo

Fisrt interview with Luis Castro, tech Lead at Cameo where we speak about the Product Developer

Brandon’s opinion in the matter differs a bit, and I think goes more into the universal understanding of the role. Nonetheless, he underscores that there is really no such thing as a real Full-stack Developer and it is more a requirement from the company than a real thing:

Truthfully in my opinion no there’s no such thing as a full stack engineer.

Meaning, it is very rare to find someone who masterefd all the different technologies in each of the domains like backend, frontend, infrastructure, etc. Although, when we talk about the concept, Brandon elaborates that it basically means that an engineers understands the full software life cycle and how all the components and technologies piece together:

One of the major things about a full stack engineer is understanding of course the deliverables of the whole product. From the design sessions with PMs all the way to the implementation and deployment of it. In my point of view, Full-stack Engineer is not just understanding what the product is, it’s more along the lines of how can I touch every layer of the engineering stack to deliver a feature or a product to the customers.

A full stack engineer understands at least at some level the whole pipeline from the design step all the way to the deployments step.

Brandon Parrott, Team Lead, Fyllo

Transition to a Team Lead

When one transitions from a Developer to a Leader the first thing that one notices is the number of 1:1 meetings with all the team members. Brandon explains that a big surprise for him how suddenly one gets more personal with the colleagues. Becasue until then, even if you collaborate closely, apart from work you just hang and have a small talk, but once you become a manager you start looking at other aspects of their lives:

Understanding their work life balance and their concerns or the difficulties that they’re having within the team or within the organization.

Lead by supporting

Brandon found a balance of 30% management work and 70% of software or developer work in his role. All this by giving a lot of autonomy to the team members. He considers that by letting the team members make some implementation decisions, you empower them and motivate them to do their best. There is really no need to micro manage anyone:

“I do feel that if you give your engineers autonomy, not hand holding them but empowering them, making sure that they have the competence to make certain decisions, especially with their stories, and pushing them to take ownership of their own work. You really don’t need to be managing them too much.”

Support is a word Brandon uses a lot when he characterises his role

Take a step back provide support when needed. Make sure that the Engineers have everything that they need. At the end of the day, they are seniors, they are Engineers who are capable of making those decisions so allow them to make them and just be there to support them.”

Leading a fully remote team

An interesting thing to mention is that neither Brandon and I, nor Brandon and any Engineer from his team have ever met face to face. We are working in a very distributed environment and most people have never met each other. This adds to the complexity of creating a team spirit and a cohesive collaborative team out of a group of people “assigned” to a team.

Brandon goes for 20-mins 1:1 meetings with all the team members on a weekly basis. And then, the strategy is to trust the developers they will do their best with what they have.

One of the things that I really enjoy about engineering is that we’re on a three-week Sprint cycle. At the end of the day, as long as your commitments get done (at the start of Sprint we commit to certain amount of deliverables), so as long as we deliver what we commit to for that Sprint it doesn’t really matter how or when you complete those individual tasks as long as we are delivering on our commitment each Sprint and I feel ike the last two sprints we actually have been delivering almost our full commitment.

Slowing down to speed up

I always associated this saying mostly with planning. We slow down, we plan what to do, so then we can speed up and do it better. Brandon finds another angle, that is basically leveraging the intrinsic motivation of the developers and preventing them from a burnout. He proposes the devs to learn what motivates them, so that the work can excite them. Of course, when they are learning the new technology they will slow down but after they get better at it, they will speed up and increase the overall velocity of the team. As an example he brings up one Developer’s experience:

I’ve been saying this in my one-on-ones lately, you gotta slow down to speed up. I’ve been really trying to make sure that the team is working on stuff that they find interesting. E.g. one Developer, he’s pushing to become a Senior Engineer and he understands that he lacks front-end knowledge and the really in-depth react experience. So one of the things that I noticed is that by having him take on more front-end things it slows him down in in the sense of what he can commit to during the whole Sprint but in the end it speeds him up because he’s getting more knowledge about the other domains of the product. And second, he actually finds it intriguing and he’s motivated to make sure that he doesn’t fail.

Keep people motivated is in company’s best interest:

If someone’s doing something that they are not enjoying they’re going to get burnt out. They’re not going to deliver high quality code there it’s just going to be mundane and in the end it’s not going to be good for the company. We’re gonna have a burnt out engineer who’s potentially going to start looking to leave and they’re not going to be doing their best work because it doesn’t interest them anymore.

The interview is full of great insights, real-life experiences and tips. If you want to listen to it as a podcast go here:

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Maria Chec

Maria Chec

2K Followers

Agile Coach and Content Creator at Agile State of Mind https://www.youtube.com/c/AgileStateofMind and Head of Agile Practice in Fyllo