Andrew Heffernan

Hello! What's your background and what do you do?

I am currently working at Validity Inc, running the DemandTools product line engineering teams. Prior to my current employer, I worked at Constant Contact in a number of different roles ranging from frontline support directly out of college to Software Engineer.

I had a very unconventional path to Engineering; I went to UMass Lowell for a business degree in my first college stint and then fell into a support role at Constant Contact. At this point in my career, I had never seen a line of code in my life. However, I quickly got exposed to HTML and JavaScript bugs while looking into customer issues and worked to help triage these bugs and eventually began teaching myself how to fix these bugs on my own. I kept learning by trying to tackle new issues and from great mentors and I eventually went back to school for Software IT at UMass Lowell to get a degree in the field I saw myself working in for the long term. While at school part-time, I worked my way up the ladder at Constant Contact to a Technical Support Engineer, then a Quality Assurance Engineer then finally a Software Engineer. All in all, I have been writing code for roughly 7 years - probably a shorter time frame than most in my position.

I started my Engineering career working solely in web applications. I mostly worked on Java SpringBoot applications and occasionally worked on the React side of the stack. Since moving to Validity, I continued developing web applications, but also expanded into various cloud technologies on AWS and Electron Desktop applications.

How was your transition from software development to management like?

My transition to management was a bit unexpected at the time. I was the first engineer hired at Validity and quickly started leading a 4-person team to build out their first new project. I was part of the interview process for all but one person on the team. Validity soon went through a major growth period where we went from a small engineering shop of 8-10 people to an engineering team of about 115. Seemingly overnight, we had to change from a flat organization with everyone reporting to the EVP of Engineering to having layers of management. From there, my responsibilities grew to the point where I had 16 direct reports while continuing to maintain some individual contributor responsibilities.

By all accounts, 16 people is an unconventionally high number of direct reports. I had to manage three separate scrum teams and interact with four product managers. I also had to incorporate 1-on-1’s into my packed schedule with not only my direct reports, but also my peers in engineering and product management. I was definitely drinking from the firehose, but I would not trade this experience for anything. I was very happy being pushed into the deep end and having to sink or swim. Now I’m hooked and I can't see myself doing anything else. It’s the right mix of problem solving and mentoring that I am looking for in my career.

What does your day-to-day work look like, and what motivates you to do it every day?

I still wear a lot of hats so my day to day can vary dramatically but the typical day:

8 am – 10 am: I block off my calendar and dedicate this time for myself. I typically start by taking a chunk out of my task list for the day. I often use a few minutes of this time to sync up with my product manager over slack to make sure there are no outstanding tasks we are waiting on for each other.

11 am – 4 pm: This is typically spent in meetings.  With a 10-person engineering team, a lot of effort goes into making sure there is groomed/groom-able work that is ready to go for the sprint/grooming sessions.  Most of my time is split between grooming, planning, and 1-on-1’s. This also includes monthly syncs with support, other product leaders, and other internal process teams - all of the teams that engineering and product work with throughout the organization.

4 pm – 5 pm: Check back in with the team and make sure I didn’t miss any slack questions or people on my team that need help un-blocking items. Then I typically end the day with re-syncing with my product manager to catch up on anything that either of us missed during the day.

I still try to contribute to the code base, but I learned that I cannot dedicate the time I used to. This was one of the hardest lesson for me to learn early on. I’d say I spend roughly 1-2 hours a day writing code, generally between meetings and in the early part of the day. If we are at risk of missing deadlines, I’ll cancel all non-essential meetings and try to help out the team more than usual. Otherwise, I have to pick and choose pieces of work that are out of the way and don’t block the rest of the team. In addition, I never count my velocity toward the sprint metrics because it fluctuates too much to be reliable. I typically end up picking up bugs or small future unblocking work like an API that the UI will need next sprint.

I spend a little more than half of my time preparing for the next sprint and project planning to make sure we can hit our quarterly goals. This typically includes working with Product to estimate the dev resources needed for a given project and trying to find the right mix of people on the team to work on the project. Trying to get the right mix of existing skills and balancing that with opportunities to give each member of the team interesting new challenges to help them progress as engineers is one of my favorite parts of the job.

With all of the projects happening at once, one of my biggest challenges is getting everyone on the team moving in the same direction and understanding how their project impacts the bigger picture. Unfortunately, with a team of this size, if I tried to bring everyone to every planning/grooming, we would never have time to write code so communicating out how the pieces fit is essential.

My job also requires that I am looking at the holistic view of my product line, this includes working with internal stakeholders to identify and address issues as well as understanding how each ticket fits into the bigger picture. This means that I have to try and keep scope in check from a UX and product design and an engineering architectural design perspective, while still delivering a product/feature that is high quality.

I got into engineering because I love solving problems, this job gives me the chance to solve problems big and small every day, as well give others opportunities to grow and learn.

What are the biggest challenges in management you've faced so far? What did you do to overcome them?

The toughest part is at times you can very much be on an island and it can feel a bit lonely/unsupported. In order to do this job well, your feelings and/or stress needs to get checked at the door. This is easier said than done.

One of the best lines my former EVP of Engineering shared with me when I started in leadership is that my teammates are no longer the individuals that I work with on a daily basis or on the same project as me. My teammates are now the other engineering leaders.

Because of the way Validity’s engineering department was formed, there are a number of product lines that don’t often have to interact with each other. One Director may never cross paths naturally with another. I have to remind myself that when I need a sounding board, they are allies. They may not know my day-to-day, but they have had to deal with similar problems or at the very least can be a rubber ducky on situations.

In addition to this, I noticed that a lot of the stress and indecision comes from second-guessing and waffling on the right approach. I learned that I have to sometimes make tough choices in this role. I had to change my mindset a bit to make sure I take all the feedback available, but also trust my gut.

What has been the biggest surprise so far? Something you didn't expect?

The amount of energy required to lead effectively. My team comes first - without them nothing else matters. I can come up with the best project plan and architecture, but if I don’t have my team on the same page as me nothing will get done.

Putting the team first is not easy. There is a delicate balance between dealing with the current fire, making sure the team has future working coming in, and helping the individuals on the team deal with stress and anxiety. All of this while making sure you keep up your own energy and positive attitude.

What's the best advice you've received about being a manager?

“Feedback is a gift” - This a message one of my old bosses drove into me. I don’t think she meant for it to specifically apply to management but it's great advice.

I truly value an employee that is willing to give clear feedback. I don’t always take action on the feedback, but you need to know what your team is thinking and feeling. There is nothing worse as a leader than finding out you were unknowingly making someone’s job harder, or an employee had a great idea, and you ignored it, or even worse, if someone feels uncomfortable on your team. I try to encourage a culture of bringing up things in the appropriate setting and keeping the balance of listening and keeping an open mind, while knowing you can’t manage by committee.

What do you tell developers who are considering making the switch or new to the role?

I’d suggest shadowing an engineering manager/director in your company. Every engineering leadership role has a different set of requirements and responsibilities. If you are attracted to this position because you want more power, this is probably not the role for you. To do this job well, you have to balance self-growth with your team’s growth - anything else is a losing bet.

Final call to action! Where can we go to learn more about you?

LinkedIn: https://www.linkedin.com/in/andrew-w-heffernan

Medium: https://medium.com/@andrew-heffernan ← Coming soon