The Manager’s Path …… As a Software Engineer

The Manager's Path

Review

This is the last post for a while for this book club. I started by expressing software engineering these days requires a lot of reading and writing, even ironically it is the same industry that changed how people communicate. Nevertheless, conscious of different communication medium key to the success of what we do.

I then expressed how software development is a craftsmanship but also a team sport. Only by working as a team, we could achieve a lot more.

In the last post, I expressed there are much more than “writing code” as a software engineer, that software is a service that you provide to your customer. In this post, I will be discussing a similar topic but it is more personal.

This happened to myself early in my career, and many software engineers that I have met over the years too, that after few years of working, we all at a lost the career path of a software engineer.

There are more companies nowadays, such as Dropbox, have a very clear definition¹. However, there are much more companies have just simple 2-levels structure, one level for the out of collage, and became a “Senior Software Engineer” for those that have few years under their belt. The senior positions often are not well defined, mostly driven by time in the job or technical knowledge in your specific domains.

Moreover, I was also horrified by the sea of non-technical managers, who knows little about project management nor software engineering. They came up with unrealistic schedules and cared little about the team, or the project. To those managers, software engineer seems to be a cog in a massive factory.

On the other hand, I have also saw our former peers, who was a good developer, promoted to management level only to witness she is fully occupied by endless meaningless meetings and project status reports.

Being a Manager Leader Can Be Fun

Developing a sense of ownership and authority for your own experiences at work, and not relying on your manager to set the entire tone for your relationship, is an important step in owning your career and workplace happiness.

I am not trying to argue management is more fun than being an individual contributor writing code and everyone should be a manager, but I do see certain aspects of it when properly utilized could help everyone in the team be much more effective in building the right product, and overall more enjoyable work everyday.

It is about taking extra steps to start looking at a new feature from a product perspective, and questioning how the proposed feature fits into the short and medium term product strategies. I found this holistic way of thinking can help answer a lot of day to day questions.

For example, if customer discovered an issue, how and when to resolve the issue became really clear. A mistake was found in the core parts of a program should be fixed with much more care and attention. A wrong architectural decision should be reviewed and addressed.

In other words, the experience of a software engineer, in my opinion is determined by how she can look at an issue at a higher level. Being a manager or team lead is not necessary means having more responsibilities, but rather different kind of responsibilities.

Don’t Forget What You Do Best

If you don’t stay in the code, you risk making yourself technically obsolete too early in your career. You may be on a management career path, but that doesn’t mean that you should wash your hands of technical responsibilities. In fact, I mention specifically in my engineering lead job description that I expect managers at this level to implement small features and bug fixes.

After promoted to manager or tech lead because of this new gain perspective. In my opinion, it is very important to stay close to your roots, even few years in the management role.

While it is true being a tech lead and above are involved in some “abstraction tasks”². Those tasks can help your team focus on one thing - deliver values to user. It could be seemingly trivial tasks, from getting office chairs and removing the inverse bus factor³. However, it does not mean departure to your technical skills and stop writing code altogether.

First of all, the ability to contribute to the project occasionally will help understand the day to day frustrations, such as tools reliability, or workflow setup. For example, if a simple 1 hour change takes 3 months to get to the customer hands, or impossible to incorporate into a release at all. This information will help you determine how you could help. Technique such as Trunk based development and continuous delivery mindsets play hand in hand with this management style.

Secondly, the quality of the code for the project will improve a lot because of the limited contributions as well. It is because in order for any occupational or new contributors to work effectively, it is particular important everything has to be easy to understand and well documented.

Pay It Forward

I do not pretend to give such a deed; I only lend it to you. When you […] meet with another honest Man in similar distress, you must pay me by lending this sum to him; enjoining him to discharge the debt by a like operation, when he shall be able, and shall meet with another opportunity. I hope it may thus go thro’ many hands, before it meets with a knave that will stop its progress. This is a trick of mine for doing a deal of good with a little money. - Benjamin Franklin

Another aspects of taking a software engineer career to the next level is helping your peers, sometimes even managers, to see the lights at the end of the tunnel. It could in the form of having a warm welcome⁴. It could be having constructive purposeful 1-1 meetings, or start mentoring your team members who are struggling at work.

This is in my view much harder than engineering a software solution, because it requires a lot of patient and time. However, this will defines your team’s culture, and your team effectiveness.

Reference

Dropbox Engineering Career Framework ↩
The Development Abstraction Layer ↩
the inverse bus factor: how many people must be hit by a bus for the project to make progress ↩
Patterns of Effective Teams • Dan North • GOTO 2017 ↩