Dear new developer,
The title of this post is true. I’ve seen it done and done it myself.
However, when I first started out, I saw the managers who hired me and thought “wow, they are the ones in charge; I want that!”
Spoiler: I didn’t.
Common software development roles
Let’s define some common terms. In software teams, I almost always see the following roles:
- Developers or software engineers: people writing code and delivering functionality. There are many other people involved, of course, but these are people coding in a programming language.
- Technical leads: people writing code, but also interacting with others (customers, other departments, etc) to figure out what to write, how to ship, and when the software can be delivered. They may also be mentoring other developers and interacting with other technical leads.
- Engineering managers: people hiring developers and technical leads, fostering their growth, and interacting with other departments for budget and job requisitions. They also have the unpleasant task, if needed, of laying off or firing people.
If you walk into any software producing organization, you’ll have people in each of these roles. It may be the same exact person if the company is a startup. There may be many levels and gradations, if it is a big company.
There may be different names or titles.
But no matter the name, there will be people doing the work, people coordinating the work and people hiring people to do both.
The value in trying engineering management
As I mentioned above, when I was a new developer, I thought the normal track was start as a developer, become a technical lead, and then an engineering manager. I would get more money and have more influence as I moved up the ladder.
I was right and I was wrong. That is one path, but not the only one. And it wasn’t the right path for me.
I have tried engineering management two different times, for a product company and a consulting company. In addition, I was a CTO at a small startup and managed contractors. So I’ve tried this a few times. I think it was absolutely the right move for me at the time.
Being an engineering manager will teach you:
- How complicated people are
- How hard management is
- How to be a better employee
- What managers care about
For all those reasons, do a stint as a hiring manager if you have the opportunity. Both of min e came when people left my employer and there was a need for technical leadership. This is a great way to try such a change because you have credibility and therefore time to learn the engineering management ropes. However, both of these were small companies and there was no formal training. If you are in this situation , seek advice from others. My favorite two forums are the CTO lunches email list and the Rands Leadership Slack; I recommend these all the time.
If you have the chance to manage people, do so! You might love it. Engineering management is its own discipline, which requires its own study, just as software development does. Engineering management has as much in common with software development as American football does with soccer/football. There are shared terms, you work in a team environment, and there’s a way to achieve success, but the means and the day-to-day action is entirely different.
But if you don’t enjoy managing people, you can still progress in your career. You’ll need to interact with people and take on some aspects of the technical lead role I mention above, but you won’t need to hire, develop or fire team members.
Here are a few ways to progress without managing people.
Specialize
If you can specialize in a technology or area, you can be a valuable team member. I have had co-workers who focused on databases, for example. They were experts in writing stored procedures, optimizing queries and operating a database. I’ve worked with other folks who were cloud experts or devops gurus. I’ve also worked with people who were deep into the adtech industry and knew the key players and nomenclature.
This path leads to consulting opportunities if you pick a technology that is widespread, or becoming deeply enmeshed in a company if you understand critical proprietary technology.
You also can focus on helping grow the organization technically; this often involves strategy, working across departments and building consensus for achieving a large technical goal (“we’re moving to the cloud!”). This position is often called a staff or principal engineer and is more common at a large company. Here’s a website entirely devoted to the staff/principal path.
With specialization, you won’t have to manage people. However, look for points of leverage to increase your impact, as that is critical to increasing your value and your paycheck. That could include teaching the domain, improving the technology, or helping implement some useful tool across your organization to make the organization more money or save it some.
Show leadership
You can show leadership without managing a soul. The more leadership and initiative you show, the more your career will progress, at least in a healthy organization. Leadership doesn’t mean having a team of people following your every command. It means picking a goal, building consensus around that goal, and then working towards it.
If you do this, part of success is making sure that other people are aware of your goal and help you achieve it. You’ll need help from others, which means you need to communicate to them why they should help you. The best way to do that is to tie it into their goals and the organization’s goals.
I written more here, but here’s an example from that post:
I worked at a consulting company in the early 2000s and we wrote a lot of perl. If you’ve heard of perl, you might know it is often called a “write-only” language because there’s more than one way to express anything. I noticed that we were not standardizing our perl code across projects, and a lot of knowledge wasn’t being shared.
I mentioned this issue to my manager and said I wanted to write some coding standards. While I was a junior engineer, I worked with my manager and perl engineers. I wrote a preliminary draft, then shopped it around and got feedback from other team members. At the end of the day, I had a working document that all teams could live with and that would help us avoid silos of perl coding idioms.
https://www.mooreds.com/wordpress/archives/3516
Find an adjacent field
You can absolutely move to a different, adjacent field. I wrote more about that in this post, but as a software developer, you have many useful skills that apply to product management, investing, teaching and more.
In each of these scenarios, you can make more money, get more influence, and have more autonomy. You won’t have the joy and the pain of hiring, but you can still absolutely help your team members improve and grow.
Sincerely,
Dan
Letters To A New Developer 