A resource for software team leads, managers, and executives.
By far the hardest thing you will do as a manager is fire someone. But you will need to do it. There is no way around it. If you want to be a manager, this is just part of the job.
I’ve discovered there are right and wrong ways to execute this. I’m hoping some of the tips below help make the best of this difficult situation.
Like most, I first started in the software industry as an engineer. I was taught growing up that hard work in the end will be rewarded. My strong work ethic as an engineer resulted in me quickly being promoted up from individual contributor to team lead, manager, and then eventually director.
Then I noticed a big change.
When you are an individual contributor, you are often recognized by your peers and management for your contributions. You are asked to complete a specific task or project, and the results are usually demonstrable and easily recognizable.
As you move up into management everything changes.
When you move into management, there are fewer people above you to recognize your contributions. Oftentimes, your manager doesn’t understand the technical contributions you are making to the team, because they are non-technical.
Also, the role of a manager is much fuzzier. How can you quantify if you were successful at motivating or mentoring your team?
When I first moved into a management position, I thought it was most important to focus on managing down. My primary responsibility is to get my team to execute, right?
Well, that is only PART of the role. The other part of the manager’s job is to clearly communicate up (your boss) and across (your peers) your personal accomplishments as well as those of your team.
You have to become a salesman! This is not easy to do, especially for those of us introverted engineers.
You need to get out of your comfort zone! Instead of spending your whole day with the team, force yourself to walk around the office and meet one new person a week. Tell them what you do and what your team is working on. What your challenges are. See if there is any way you can help these people that you run into. Are any of the projects or initiatives that your team is involved in relevant to this person?
When your team hits a big milestone, be sure to communicate it out to the organization. Are the other dev teams aware? How about the rest of the product group? Promote your team to the organization. Be proud of their accomplishments. This is not slimy or devious. This is basic business communication.
You need to do this, there is no choice. If you don’t do it, no one else will. The reputation of your team will suffer for it. Your reputation as a leader will suffer.
And you can’t just promote your team, you need to promote yourself as well. No one else will be an advocate for you, except you!
Some people do the above naturally. I’d bet that most engineering managers don’t. I know I don’t. I’m still not good at doing the above. However, I’ve seen other managers excel at this and reap the benefits.
Check out a book on this entire topic here:
When ramping new hires up, it’s very tempting to quickly throw them into the fire, fix bugs, start building features, etc. After they’ve completed their orientation and filled out their paperwork, what better way for them to learn the system?
Stop!
It’s critically important that your engineers know how the business operates, who the customers are, their needs, and how your product fills that need.
The company I currently work for provides a SaaS offering that is VERY workflow intensive. We have 20+ roles in the system with around 5 major different personas, across 3 different applications. I made the mistake in the first paragraph and am now regretting it. We were under high growth at the time, hiring as fast as we could, and our backlog was growing.
Now, these engineers have been on board for several months and know nothing about the product. When building new features, they don’t have the customer in mind.
Bottom line, when onboarding new employees focus on the product and end users first, THEN have them learn the code. This may take a week or more, depending on your product, but it will pay dividends down the road.
There’s no worse feeling than when your production system goes down. The business relies on your system’s availability. Something happened, a bug, bad code push, a customer inserted crazy data, or whatever.
Now everyone is looking at you to fix it. You are completely dependent upon your team, operations and engineering to come together, diagnose, address root cause, and deploy a fix ASAP.
Your ass is on the line and you are pretty much helpless.
What can you do to help?
Here are my tips:
What other steps do you take?
