Category Archives: Management

5 Lessons I Learned as a Software Engineering Manager

For 2 years I was a manager of 3 engineering teams, each working on complex and highly involved projects in Silicon Valley. Over that time, I’ve learned a great deal about myself, my relationships, and the role of a software engineering manager.

The following are things I wished I’d known when I started this role. While each of these may not apply to you, I challenge you to think about how you can best influence your employees and enable them to do their best work. I’m not talking about just staying out of their way or having fun, I’m talking about making them better engineers, preparing them to move on to bigger and more complex projects.

You Can’t Be a Friend and a Boss

can-you-be-friends-with-your-boss-300x286By far the biggest mistake I made was thinking I could maintain close personal relationships with my employees, while also being great manager. (And this was especially hard since they were my peers at one time. )

The problem is, the manager role requires you to push your employees. A good manager stretches, grows and challenges his employees to do great things. To do this well, your employees may not like you sometimes, but you owe it to them. It’s why the company put you in this position and it will be why your employees respect you as their manager. Because you challenged and enabled them to do their best work. Anything less is a disservice to them and to the company.

Now this doesn’t give you free reign to be a tyrant over your employees. We’ll get to that a bit later on. And of course you want to be friendly with your employees to encourage openness and good rapport.  But there is a line, and if you don’t know where that line is, your employees may be missing out on their full potential.

99% Inspiration

driving_visionA great manager enables people to do their best work not by handing them tasks, but inspiring and setting a vision for the project.

The old adage goes something like, “mediocrity in, mediocrity out.” In short, if you hand an employee a dull list of tasks to accomplish, with no room or call to their creativity, that’s all you’ll get back. A boring, dull piece of software.

If on the other hand, you set a vision for what the project is attempting accomplish or how the end user is empowered by the software or how it impacts the bottom line and grows the company, you’ve given a set of goals for the employee to accomplish that can pay off ten fold. By giving them a vision and creative ownership over the project they can contribute brand new ideas to the final project. I’ve seen this result in making the design/interface more intuitive and even pushing back on ideas/features that simply wouldn’t have paid off. (Think feature creep.)

While this may not work for every employee, I have seen the effort it takes on my part pay off countless times to produce simply stunning results.

Accountability Leads to Independence

goals-day-9Even with free reign, employees need to be held accountable for their decisions and when appropriate, their mistakes. A great engineer will own up to their mistakes, collect information on what were contributing factors, and finally take steps to mitigate those mistakes in the future. You’re role as a manager is to help facilitate process, but more importantly, to know when the engineer is out of their depth.

If an engineer is more junior, they may need you to help the first few times they make a mistake or a bad decision. But the moment it becomes apparent the engineer is lost or can’t handle the task given, step in. You want to stretch them to grow, be accountable and independent, but not put them in a position to fail.

Right Person For the Job

square-pegTo tie in nicely with the point above, if a person is not working out, make sure they are the right person for the job. Don’t accept the resources given are all you have to work with. This is not a pee-wee hockey team, this is a business and getting things done right requires the right resources. Forcing an engineer into a role, project or environment they aren’t thriving in, will simply make you both frustrated. Get the right people on the project and, if they are a good engineer, get them on something they can be passionate about.

In addition, bringing up these resourcing concerns clearly and concisely with your superior shows him or her:

  • You are thinking deeply about the project and what will be required to complete it successfully
  • You are thinking more broadly than your own team
  • You have a deep understanding of your employees strengths and weaknesses
  • You care about the success of the project and your employees

Brave New Worlds

Great engineers get bored very quickly and the fastest way to lose them is to keep them confined to a single, legacy project. Great engineers thrive on change and challenge, so give them plenty of opportunities to explore new areas. This may not always be related to what your team is actively working on, and that’s OK. You want your employees to be continually growing, finding new passions, and testing their limits. This enables them to grow personally and see problems from fresh vantage points. When they return to your mainstream projects, they will bring new ideas and perspectives, ultimately creating stronger final results.

Final Thoughts

While my time as a manager was stressful and the growing pains were difficult, the lessons and insights I gained were invaluable. As a manager, I was given a fresh new perspective on what happens at the executive level within a company. Why decisions are made, how they were executed and what was the expected result. From an individual contributor perspective, it enabled me to communicate more clearly with my future managers about timelines and project needs, ask the right questions about a project, know how hard to push on people/dependencies, and think about success/metrics.

However being a manager to gain these insights isn’t for everyone.  If you are thinking of becoming a manager, these are the hard questions you should ask yourself to see if you’re ready.

  • Is managing timeline, people and process something you are passionate about?
  • Are you willing to have your success solely dependent on the work of others?
  • What is your 5 or 10 year goal?  To become a Director? VP? Just to make more money? What are you working towards?
  • Are you willing to take full responsibility for the shortcomings of your team?
  • Do you enjoy building into people and pushing them to grow?
  • Are you willing to understand and dig deep into multiple projects at the same time?
  • Can you balance setting context and vision for your team, while also stepping back so they can do their best work?
  • Are you willing to see when people are not the right fit for the job and know when its time to part ways?
  • Do you enjoy interviewing candidates and working with HR through the hiring process?
  • Are you willing to give up solid blocks of time in exchange for a day split up into half hour blocks?

I consider my time as a manager a worthwhile growing opportunity which stretched me in ways I could have never imagined. In addition I discovered managing people and processes was not something I was ultimately passionate about. And that’s totally fine. You know why? I’m much more happy and productive as an individual contributor, which ultimately makes me a better asset to my company and the projects I’m truly passionate about.

The Marks of a Great Engineer

Over the last 4 years, 2 of which as a manager, I collected notes about what I and others thought were the marks of a great engineer.  I’ve compiled this list to inspire other engineers and also give solid examples of each trait.   I’m sure there are many more things that can be added to this list, but its a start.

Finds problems, makes good decisions and escalates if unsure of correct path.

“This was broken, so I fixed it”
“This is broken. I see 3 possible solutions…”

Communicates clearly on technical topics to peers and managers. Asks good technical questions.

“Here are the 3 things we are working on and how they fit in the larger picture”
“Why is X the correct solution? What are other options?”

Shares what they learn via blog, tech talks, etc. (Helps you become more articulate and grow by getting challenging feedback)

“Lately I’ve been reading about…”
“Have you ever wondered why…”
“This is amazing and I had to share …”

Writes clean, modular, testable code, paying attention to detail.

“I’ve thought through these different solutions, but chose X because…”

Brings focus and vision to projects, taking into account the bigger picture and knowing what to trade off.

“We can start with X and iterate till Y.”
“Z is interesting, but not neccessary.”
“I think there is a bigger opportunity here if we do X as well”

Successfully delivers task/bug/projects to completion and cleanly hands off. Doesn’t let things drop!

“I wanted to check back in with you on X.”
“Do you have everything you need to move Y forward?”

Able to lead a project, create a roadmap and inspire team members.

“Based on the ask here, we need another experienced person to help with X.”
“Here is the plan for the next few sprints of this project. Thoughts?”
“I think this can be better by …”

Prototypes to get real data and answers when unknowns arise.

“I wasn’t sure about X, so I did an initial prototype and found…”
“I prototyped two possible options with this resulting data. Based on the data, I think option A is the best choice.”

Takes initiative, steps up.

“I’d like to learn more about X”
“I’d like to drive/lead X”
“Y has been bothering me and I’d like to make it better”
“I think there is a huge opportunity here if we spend time doing Z”

Is a standard bearer of the culture (collaborative, helpful, driven, insightful, friendly).

“What can I help you with?”
“Was that clearly explained?”
“Anything else I can do to help?”
“I noticed X and think Y could really save some time.”