Office Hours with Charles Garrett
Welcome to Merit Office Hours! This week we’re chatting with Merit mentor and investor Charles Garrett about engineering management, evaluating your first employment offer, and the value of maintaining relationships throughout your career.
Charles Garrett is a New York City-based engineering leader with a background in Computer Science and Human Centered Design and Engineering. Over the past 15 years he's held a variety of roles in software engineering and leadership. He is currently an engineering manager at Pagoda.co.
Want to talk to Charles more about becoming a software engineer, transitioning into management, and growing your career in tech? Book some time with him on Merit.
An edited and condensed transcript of our conversation is below.
Rachel Spurrier: You studied computer science in undergrad and then received a master's in human-centered design and engineering. Do you feel like those degrees helped you in your career first as a software engineer and now as an engineering manager? And if so, how?
Charles Garrett: Absolutely, [those degrees] did for me. One thing that I learned over the years in my career—there are many paths by which one can enter a tech field, whether working directly in tech as a software engineer, programmer, designer, or a role in support of a software product, like in sales, marketing education, and some sort of enablement capacity.
Depending on your interests, your background, and the timeline by which you want to be working in tech, you don’t necessarily have to follow the path of getting a bachelor’s degree in engineering. I have hired and worked with great developers that came from an arts or literature background, that were self-taught, or that went through an accredited bootcamp. On a related note, I highly recommend the book The Civilized Engineer; it speaks to the merits of engineers including liberal arts in their studies and the effect this has on one’s ability to work with solid ethics.
One thing that I learned over the years in my career—there are many paths by which one can enter a tech field.
When I was starting studying computer science, that was the best path that I knew of. That's the path that I felt comfortable with. And in building my confidence that this is something that I could do and in studying computer science, that was when I connected with this type of work—the environment in which I could work, getting into the flow and solving the problems, getting that sense of validation and accomplishment that, “Oh, wow, I can do this.”
But today there are many different paths by which one can get started in computer science, from accredited coding boot camps—there's a wide variety of them— the ones that I've experienced, where I've worked with colleagues from them, hired people from them, seen resumes from them, are the ones that pair with organizations. [These boot camps] have organizations that they work with to get you into entry-level positions after you've completed the coursework. That's a great path to get started because in addition to the foundation of computer science and studying engineering topics, software development is craftsmanship. There's a lot in addition to the scientific process that good software engineers demonstrate, and you learn those things on the job and you build that craft over time. You can get a lot of that without going through a four-year program.
RS: Regarding on-the-job training—some of the big differences between being in a coding bootcamp and actually working at a company is that you're not just solving coding challenges anymore. You're also having to ensure that your code can work in a production-level environment and commit pull requests. What are the big challenges that you see for folks who are in their first engineering job and potentially coming from a bootcamp?
CG: To add on to what you just said on solving coding challenges and submitting PRs, that bridge from working on some isolated problem to software development in the organization is doing that as part of a team and understanding what's the most impactful way that you can contribute to the team’s goals.
But within that context, you're working as a team as well, so you need to be able to grow to understand how to collaborate with people with cross-functional skills, working with design [and product] and get into that rhythm of the back-and-forth of working with people as you make incremental steps towards accomplishing some goal together, as opposed to working completely on your own in a silo.
You need to be able to grow to understand how to collaborate with people with cross-functional skills, working with design [and product] and get into that rhythm of the back-and-forth of working with people.
RS: That's a great point. One of the questions that I had was many early career engineers are learning how to navigate their relationship with their engineering manager, as well as a product manager and a tech lead and fellow software engineers. What would you recommend those folks keep in mind as they're working in a team environment, possibly for the first time?
CG: One big thing to keep in mind, especially as you're starting out in a new role, is that we're all in this together with the same goal of trying to figure things out, to work at our best sustainable capacity to accomplish some goal. Everyone has that same goal, and you are not the one person out who's trying to fit in. If you were brought into a company, whether it's as an intern or in a full-time role, think about the job description that was written for the position that you have.
Once you're there, you need to accept that that job description was written specifically for you. You were brought in for that role. You have to own that and settle into it; it's going to take some time to get over new-person feelings, the thoughts that might be in your head of whether you can do something—that kind of imposter syndrome—and realize that everyone has the same goal here. Your engineering manager and your tech lead are there to support you and understand what your unique interests are, what your professional goals are, and then help you see how to align your skills and your opinions and the diversity of your experience with the needs of the organization to accomplish whatever the business goals are.
One big thing to keep in mind, especially as you're starting out in a new role, is that we're all in this together with the same goal of trying to figure things out, to work at our best sustainable capacity to accomplish some goal.
Questioning your ability to do something is a normal part of the learning process. It can be helpful to think of these moments as checkpoints in your path of evaluating how you’re spending your time. Aim for shorter feedback loops in your learning and development processes, and try to distinguish self-doubt from questioning whether there might be more fruitful ways to go about learning or implementing something.
RS: That's great advice. And you're talking a little bit about some of the unspoken kind of norms of the workplace and that we're all working towards a shared goal, and maybe no one ever says it out loud, but that's the shared understanding. What are some unspoken norms and rules of networking or tech or mentorship that you had to learn and would like others to know?
CG: The first thing that comes to mind is when you're working in an organization: it's similar to working in a group to complete milestone projects at the end of some studies; the relationships that you're forming there can be really valuable. Not only for a more obvious [example] if someone gets a job in a company and they've worked with you, they could create a referral for you, but also having those peers to speak with, as you're working through challenges together. I'm still in contact with friends from my undergrad. We talk to each other about things that are going on in our careers right now and give advice, listen to each other's perspectives as they're looking for jobs or getting into a new role, or understanding the scope of different jobs that people have. Those relationships are important.
One piece of advice that I've grown into is putting the effort into staying in contact with people without any specific agenda, just staying in contact and having conversations occasionally whether in person, like grabbing a coffee, or virtually. So one thing that I've grown to do over these last couple of years is trying to keep a list. Maybe sometimes it's literally: having a list of former colleagues that I want to make sure that I talk to every now and then, or keeping in contact on LinkedIn and reaching out occasionally to try to establish connections with people.
Put the effort into staying in contact with people without any specific agenda.
Sometimes that can grow to be a mentor-mentee relationship, where you can ask people questions, brainstorm, and have that sounding board to work through your thoughts with someone who knows your approach to work and is familiar with your role.
Other times it's just generally collaborative, like conversations and networking to foster that connection and professional community.
RS: I really love that your peers over time become your network and the sounding boards for the different roles that you're in. You also talked about mentorship. Do you think that the role of mentorship has changed at all in the past two to five years? If you do think that, how would you describe that change?
CG: I'm not sure I would say that the role of mentorship has changed, but what I see has changed is the value that I see that mentorship can have. That's for both parties involved. I've experienced growth and gained value from being a mentor and a mentee. That's why I continue to be involved with Merit and look for other opportunities to foster that type of mentor-mentee relationship or to encourage others to do the same on whatever platform.
I don't think that the relationship has changed with respect to mentoring, but maybe I'm projecting my experience that the perception of the value of mentorship is more apparent, not just for the mentee, but also for the mentor and for organizations, because the mentor-mentee relationship is a great way to foster equity and find ways to support equitable practices in an organization. I've seen large organizations take steps to form these mentor-mentee relationships internally in their companies as a way of retaining their talent and growing their talent inside. People can see these opportunities to have a mentor as ways to develop their careers within the organization that they're in, as opposed to potentially taking them to other places.
The mentor-mentee relationship is a great way to foster equity and find ways to support equitable practices in an organization.
RS: You mentioned a little bit about the value to the mentor, helping people. You are now an engineering manager. What was the transition like from software engineer to engineering manager? And what were some of the challenges you faced as you made that transition into management?
CG: One of the biggest challenges that I’ve experienced and something that I see in new engineering managers as well, is the process of recognizing and adapting to the change in what it means to be productive.
It's a different job, and for someone who was previously an engineer, an individual contributor, your bread and butter was the impact of your code and your ability to deliver high-quality code with speed and accuracy. That's the goal of an individual engineer—to implement things with precision that are durable. As an engineering manager, you need to enable other people to do those same things.
You're not spending hours coding like you were before; you’re spending very little if any time [coding], and that's the biggest gap. Whether you're a manager or an individual contributor, we are navigating and constructing a world of abstractions. In the code we're writing, we're abstracting some business rules, trying to adapt this, trying to create abstractions on top of abstractions, to work with other teams that are building different components. And as an engineering manager, the abstraction you have to deal with—or the question you answer to find out how to help people is— ”What's the most impactful thing I need to do to enable my team to deliver on whatever projects we're working on?”
That's the goal of an individual engineer—to implement things with precision that are durable. As an engineering manager, you need to enable other people to do those same things.
For example, if we're building a foundation that allows most of the teams to work together within the same codebase, I'm spending time thinking about “What is my greatest concern with the abstractions that my team is building? What characteristics of the code that we're writing do I need to make sure that we're doubling down on such that we can have durable interfaces that are well encapsulated, that are easy for people to work with outside of our team, that allow us the most flexibility to adapt our code over time?”
We're thinking about those abstractions in a bit of a different way, less on the specific implementation details, but more on the characteristics of the abstractions that we're working with and “What do I need to foster in my team and give them space to discover how to expand upon, to ensure that we're building code that is more durable that allows us to in the best way accomplish whatever our specific objectives are?” Even though you may not be writing production code, an engineering manager needs to maintain enough familiarity with a project's evolving technical architecture in order to anticipate technical issues and make design decisions to avoid them.
I think that the questions that an engineering manager needs to answer to determine what they need to do to be productive and to measure their productivity should be based on your organization’s mission and values statements and should also include focusing on how to identify and remove roadblocks and how to foster high-signal communication within and across teams such that information is shared frequently and bad news or unexpected results are illuminated sooner rather than later. Managers also need to hone an ability to make quick decisions, and recognize signs that indicate when you may need to course correct.
Even though you may not be writing production code, an engineering manager needs to maintain enough familiarity with a project's evolving technical architecture in order to anticipate technical issues and make design decisions to avoid them.
RS: What's changed in your opinion, regarding equity and compensation for software engineers, what should a software engineer keep in mind when evaluating an offer that includes options?
CG: What hasn't changed is offers that include different components. Some of those components come in the form of equity and in bonuses, like variable pay. Variable pay is always a source of confusion, in my opinion, because it can be difficult to determine what’s real, what you can count on, and what are the many variables that contribute to some equity portion actually becoming realized income.
Perhaps one perspective that might be helpful in navigating that is to think about equity as being associated with your own value. In some equity packages, their options are shares. If it's a public company, you get access to the stock after a certain amount of time and you could sell that. If it's a private company, you get access to some equity object that has realized value only if some event happens like an acquisition or going public.
There are all sorts of variables that then determine how much of that equity you actually get, and how much of that object becomes realized value. Detach from all of those variables and consider trying to associate that equity package to you and to the value the organization attributes to your potential.
Reflect on a few questions like, “Does this equity demonstrate that my contributions will be valued?” “How does my role directly contribute to the company's ability to generate revenue?” “What are the timelines of the portions of the variable pay which are more likely to occur, like performance-based bonuses, and does the company foresee the need to change these timelines? Have they changed them in the past?”
Then think about, “If this organization is willing to give this equity to me, let me assume that I could get this equity package at different organizations of a similar size, business model, or revenue stream.” Then perhaps consider what your priorities are. If you're looking to create some sort of definite windfall of money in a couple years, then you may want to consider valuing a company that can help you realize your long-term value sooner rather than later. Maybe that means you would be more interested in a public company that already has a track record of what its stock is worth over time. That removes some variables from that equation for you—you only have to think about your vesting date. Then you can think about what you can do to be most successful in your role to help accomplish whatever goal you've been hired for to increase the chances of that stock staying the same or getting better.
Talking to people with different experiences across different industries is a great way to help you understand what type of questions that you need to ask of yourself, your goals, and the company to help you get a better understanding of what is the most likely value of this equity that you're being offered.
Talking to people with different experiences across different industries is a great way to help you understand what type of questions that you need to ask of yourself, your goals, and the company to help you get a better understanding of what is the most likely value of this equity that you're being offered. Because the thing that is constant that has not changed my perspective is that it's very confusing to determine that on your own.
RS: I could not agree more about how confusing it is, but taking a step back, we're talking about a job offer, and that's the stage where you've gone through the interview process and you've been extended an offer. What we've seen at Merit, and that I've seen in a lot of the communities that I'm in, is that folks who are trying to break into software engineering, particularly if they've been coming from a coding bootcamp are asking, “How do I increase my chances of success at actually receiving that offer? The constant rejection is exhausting.” What can folks looking for their first software engineering job do to increase their chances of receiving that offer?
CG: Dealing with that rejection is very hard. And in addition to building resilience and having a support system to deal with help you deal with scenarios where you don't get the result that you want, it may also be helpful to ask your mentor and your network, “What should I look for? [What are] the questions that I ask in early conversations with the recruiter to help determine whether there is enough alignment between the needs of this role and my capabilities, interests, and experience to justify proceeding with additional interviews for a given role?”
Every position that you see available, whether it's explicitly listed as an entry-level, junior position or not, the hiring manager there always has to do some calculus: “Given our current team dynamics and whatever has changed recently, perhaps since I wrote that job description, how much support can we afford to give to someone in this role? How much autonomy do we need from the person in this role? What balance of technical skills do we need this person to demonstrate? And how much experience do we really need this person to have to work in a team or working on a codebase that is actually live or supporting other individuals?” Those are always questions that a hiring manager needs to ask.
Try to spend some time thinking through what type of questions can you ask of your network, of your mentor, of the recruiter to give you a better idea of what level of support and autonomy [the company] can afford to give to someone coming into this role.
And on the other side of that: what you can do to bolster your experience working in the type of environment that one would have in a large organization. Look at the skills that you have, what are your preferred programming languages, where are your strengths in your toolbox, and then find open source projects that are based on those and contribute to them.
Try to spend some time thinking through what type of questions can you ask of your network, of your mentor, of the recruiter to give you a better idea of what level of support and autonomy [the company] can afford to give to someone coming into this role.
That's a great way to get the experience of working in an organization, working with version control systems, cloud deployments, git branching flows, and moving code from your machine into production in a way that a large organization would—without requiring you to actually be in that organization. Open source projects are a great way to get that similar experience. That's often something that hiring managers will look for when considering a candidate’s experience: “Okay, you're coming straight from a bootcamp or straight from university. You don't have experience at a larger organization, but what projects have you contributed to that are live? What open-source work have you done? How has that added to your experience of working as a team?”
Have more questions for Charles? Grab some time with him by joining Merit today.