Published 02/18/2020
Author: David Crandall
When I first moved to the Silicon Valley 10 years ago, I didn't really know what the hell I was getting myself into, other than I knew I could write code and that the old farm town I lived in prior had zero jobs in tech, and zero jobs with any career growth. I needed more than that.
So, I moved to the Silicon Valley, established myself as a web developer and software engineering manager, but that didn't happen over night. It took years of learning, trial and error, and prepping for things people just don't tell you before getting into tech management.
With this in mind, I thought I'd share what I've learned about being a manager in the tech and software engineering industry.
As an IC (or, individual contributor, aka, a developer), you tend to write code pretty much exclusively. Some of that code-writing is fun - perhaps you're adding a cool feature to an app, or building an API to live stream data; as engineers, we thrive off this kind of problem soliving.
Sometimes, the work is less romantic. Updating international strings, refactoring your code to work with the latest version of react, changing the shade of button color a thousand times because your marketing stakeholders can't decide what's 'on brand'.
Going into a management role, one might thing, oh yeah, I can delegate this work somewhere else -- which is true, but you're also going to be delegating away the fun stuff, too. You need to make yourself available to your team and to your stakeholders when they need you
This means your code contributions may be restricted to peer codig to help your team debug or overcome a challenge, or on an as needed basis. And that's ok.
Being a good manager is less about how many commits you make to your project, and more about how you motivate your team to get business objectives done.
No one likes meetings, but 1:1's don't need to feel like 'just another meeting'. They are critical in understanding your team's needs, painpoints, and successes. Managers who fail are often managers who don't understand their team's needs on a granular level.
In my current role at Malwarebytes, I manage two teams, and two embedded QA engineers. Every two weeks I meet with my managers as a group, as well as 1 on 1. Even further, once per month I do skip-level meetings to talk to their teams.
For me, that's roughly thirty 30-minute to 1-hour meetings in a span of a month -- just talking to my team. But this time is not wasted - it is invaluable. This is the time that allows me to:
a. Get to know any concerns someone on the team might have b. Help clarify anything about technical strategy, business strategy, etc. c. Understand and support each individual's career goals d. Foster innovative ideas e. Get to know my team a bit better on a more personal level f. Offer confidance, and trust, never to be abused
Make no mistake, not every hour of each meeting is spent talking about work. Sometimes, we shoot the shit. We'll talk about anime, film, donuts, Chris Farley movies, our favorite liquors, you name it.
These meetings are critical in both team building and execution of projects. It's less about keeping tabs on your engineers, and more about treating your engineers like people.
This is a concept I find many companies fail in across their organizations structure. Often times, especially as a company gets bigger and there are more cooks in the kitchen, separation between high-level strategy and the IC can get lost.
When a person - engineer or not - doesn't understand the impact of their work, then their work can feel pointless.
I know if MY work feels pointless, or I don't have an understanding of my work'as impact, I'm far less motivated to do it, let alone do it well.
As a manager, you must be able to communicate business strategy down to your team's level
This comes with strong collaboration with your stakeholders, PM's, or anyone else, and converting these into tasks that directly correlate with the end goal. In other words, make the work feel important.
As a manager, you are spending less and less time in your code. That responsibility is for your team. As such, you rely on their expertise to execute on a task efficiently and effectively. That's well and good, however, these engineers are working with this code every. single. day. They know it better than you.
So, once a team understands an end goal in a project and the strategy behind it, you'll be amazed not only at how enthused the team becomes about the work, but how many more unique ideas bubble up in communication.
As a manager, it is your responsibility to listen to these ideas, and foster good ideas up to your stakeholders as you provide technical solutions for their projects.
Not only does this make the work more personal for the engineer - because it was their idea - but it puts you in an excellent position to rally the business behind your team's ideas.
This is probably the most difficult task of all, in my opinion, simply because one's idea of the perfect career may not fit within the direction of the business you work for, or the apps you build.
However, if your engineer tells you what they want to do with their career, you should be doing all you can to guide them down that path.
For example, if you have a frontend engineer with a long term goal of working in DevOps or SRE, as a manager, you should be:
There are many things you can do that require little effort that will not only help your employee further their career, but make them excited to be working with you, and for their future.
One thing people tend to ignore in any management training is conflict resolution
It's a tough position to be in when two people on your team aren't getting along. Many questions may run through your mind.. What do you do? How do you remedy the friction? Who's really at fault? Am I doing something wrong?!
First understand that every situation will be different. Sometimes conflict arises when two people overstep eachothers responsibilities. Other times, it could be two people disagreeing on who takes responsibility for something. Or, perhaps, two personalities just don't work well together. At the end of the day, you'll need to alter your approach from situation to situation.
Second be open minded. It's easy to side with the person who's been on your team longer, or who you feel a closer personal connection with, or who gets more stories closed by the end of the sprint.
But it is not your job to take sides, it is your job to resolve the conflict. Stay calm, listen, evaluate, and then act.
Thirdly understand all sides -- the truth is usually somewhere in the middle, and often times a compromise can be found. Most people have good intentions and simply misunderstad each other. Find where that disconnect is and mend the connection.
Lastly do not overreact. Worse than having to deal with conflict in the first place is reacting too dramatically and/or too quickly. Take the time to be objective and fair to all parties before you chew someone out, alienate someone, or terminate a position.
Remember, these are people.
As a senior level person in any job, you immediately feel the weight of having to be "the expert" about everything. Guess what, you don't.
Yes, you need technical and interpersonal saavy, but you need to be able to lead your team first and foremost. Once you step into management, it's not your job to be the coding expert per se, but to entrust and hire the experts in your team to have that knowledge.
Nothing great ever survives at the hands of just one person. Companies grow, and the complexity of problems, needs, decisions, etc., grows along with it. It is always a team effort; trust in your team.
One thing I wish more managers, directors, and executives understood is that we're all just people working toward the same goals.
Often times, we silo our teams in our businesses so much that our teams lose connection to the business as a whole. I've also seen cross-functional teams literally compete to somehow do or look better than another.
As managers, IC's, directors, executives, whatevers...it's important we understand that we are all striving toward the success as a business. The only way that can happen if everyone works together, and talks to each other.
Communicating isn't hard. Really, all you need to do is treat the people you work with like people, respect one another, and constantly collaborate.
There are many other things I've learned along the way as a software engineering manager in the Silicon Valley. These items don't cover everything one should know when entering this field of work, but I've found keeping these principals in mind to be key to my success, and ultimately, my team's sucess.
If you enjoyed this post, click the button below to read more from my blog!
See more posts
Leave a comment