Once in a job you will quickly discover that a broad array of technical career roles exist. At a high level, do you want to be a programmer or manage programmers? If you want to remain in a hands-on role developing software, do you want to go with the architect or engineer track?
In short, many ladders exist for you to climb, and you need to choose the one that aligns best with your interests and strengths. Fortunately, you can often leap from one ladder to another, so you are not stuck forever on one of them if your desires change over time.
The Technical Climb
Most companies offer a technical track for software developers that may branch into sub-tracks as you move along. Typically the levels are engineer, staff engineer, senior engineer, principal, chief, distinguished engineer, and then fellow or CTO. Not all companies have (or need) all these levels, but this categorization is common.
Somewhere up the track, usually at the principal level, the track splits into architect vs. engineer sub-tracks.
Architects excel at high-level design and structure. While they also are often excellent coders and deep in technical knowledge, they are capable of understanding customer needs at a high level and architecting solutions to them. For example, the architect of a large website may be juggling in his or her mind the website design itself, the web backend, the scaling and deployment stories, and even specific technologies used in each part (database types, buses, messaging frameworks, and so on).
Engineers like to deep-dive into specific technical implementations, solve difficult problems, and are willing to get into the low-level details of issues. Their minds are drawn to such problems, and they derive satisfaction from finding and implementing solutions to them. If a skilled developer gets placed in an architect role–which happens oftentimes out of necessity–you will quickly know he is an engineer if he gravitates right back down into the guts of a problem and has a hard time pulling his head back up to look at the big picture.
Typically you will discover early on whether you are more of an architect or an engineer. Some people can do both almost equally well, but most people favor or the other. It’s important to recognize which sub-track you most fit in as that will guide your career decisions later.
Companies may also have other technical tracks, ones like QA engineer, product support engineer, systems engineer, and applications engineer. These roles are usually not straight coding ones but instead involve test suite design and test writing, advanced customer support on technical topics, or creating proof-of-concepts for potential customers.
You want to climb the ladder, but how do you do it? Quite simply, find out how your company defines the responsibilities for the different roles, and then begin to do those responsibilities in your current position. In doing so, you make the decision to promote you a no-brainer. You are already working at the next level.
The Student Becomes the Teacher
I worked with a young guy named Adam when he was fresh out of school. I was the senior engineer on a large backend system, and he joined under me to help implement features and fix bugs. He was quite skilled and did well, but due to misunderstandings at our company, he ended up leaving.
He left as a staff software engineer but joined his next company as a senior engineer–this was due to our company promoting people at an abominably slow rate–and soon he was promoted to principal engineer and was leading the development of a large part of his new company’s flagship application.
I lost touch with Adam for a few years, but I reconnected with him and another mutual friend to find out what he was up to. He had moved to a hit startup company and was the director of software development. Within the year, he was offered a CTO position. Young Adam had strategically defined and refined his goals and worked toward them. In the time I remained at one company as a senior software engineer, he had jumped to several companies and gone from staff engineer to CTO!
Far from being jealous of him, I admired what he had accomplished and reflected on my own stagnation. His example was an important factor in my decision to move to a different company and push my boundaries.
Professional Cat Herder
After gauging your strengths and interests, you may decide to go to the dark side and try management. Hey, someone’s got to manage all the programmers, and you may have the aptitude for it.
Being a manager of programmers is a very different beast than being a programmer. I have seen (and endured) many managers who were once programmers and decided to cross the divide. Some were quite good; others were awful.
Ideally you can find a company that allows you to try out management on a trial basis, with the understanding that if you don’t like it or do well at it, you can go back to being an individual contributor as a programmer without your career being harmed. I have worked at companies like that and seen developers go to management and back again without any problem. Most mature companies recognize that some programmers just don’t make good managers, but you don’t know until you try.
Management has its own track, typically avoiding the “staff” title and moving from group manager to senior manager to section manager and so on up to director and vice-president. Once you reach that big wig status–uh, I mean “senior management level”–you have gone beyond the scope of our help. True story, we used to refer to the big wigs as “the higher ups” and the higher ups took offense and sent out a memo to all employees that the appropriate way to refer to them was “senior management.”
Where Do You Excel?
As you try out different roles or move up in level, seek to identify the conditions under which you work best. For example, after several years I discovered that I am an engineer, not an architect, and more importantly that I do best when working under a strong architect or engineering lead. I naturally tend to find positions where an existing strong technical leader has already blazed the trail.
You may discover that you excel most when you can do the trail-blazing yourself, and chafe at having to follow in another’s footsteps. Or you may realize that you enjoy working closely together with at least one other person, doing pair programming and test-driven development together. These are important markers to take mental note of, as you can deliberately seek out positions and companies where you can thrive.
Of course, you need to balance this out with the need to push yourself beyond your comfort zone. Sometimes you need to take that role that stretches you outside your boundaries. Doing so acts as a forcing function for personal growth. The worst outcome isn’t failure but never trying in the first place.
As you work, be mindful of which track you are on and whether it is the right one. Should you consider jumping to a different ladder? Are you making steady progress up your current ladder? Are you finding fulfillment in the technical track you have chosen? These are the questions to regularly ask yourself as you refine your career goals.
Post Footer automatically generated by Add Post Footer Plugin for wordpress.