It seems every workplace defines job titles within their company differently. I wanted to discuss how these job titles relate to the world of web development agencies and how they are defined in differently sized companies.
Each company has a different way of defining technical titles. I used to think titles were not in the least bit important, and there’s some truth to that in small companies. However, they are definitely important when you are thinking about accepting a new position at a company as you want to be sure your new job responsibilities align with your skill set and desired salary expectations.
I’m attempting to define each role as I know them, with a focus on web development agencies. Other verticals may define these roles differently, however since I’m intricately familiar with the roles of this industry, I believe these definitions will hold up 90% of the time. There may be some overlap between positions, or some of these job titles may not even exist within small companies, or companies will amend them for their business. However, it is important to set expectations for new hires and have structure in place with properly defined roles, so you can ensure the candidate you are hiring for is a match to your position. When your business scales, properly defined roles will matter even more.
I’ll start at the bottom and work my way up, but it should be known that not all positions that seem to be a promotion are, and roles that may appear less than advanced are not be a demotion. Each role stands on it’s own or can be on a different track than other roles than you may expect (for example, management versus development). It’s important to know that a higher-level management track is not a promotion from a role in a development track; it is just a different role with different responsibilities.
The junior developer is a programmer that doesn’t yet know the ins-and-outs or tips & tricks of the industry. They may be “green”, meaning they lack years of experience in the industry and they may not yet be efficient at their tasks.
Being a junior developer is awesome, as it involves a whole lot of learning. Every developer in some sense should always be a junior developer, meaning that they should always strive to learn something new. The goal of the junior would be to advance to either a mid- or senior-level developer position. A junior dev who does not want to advance in their career is usually an unmotivated person, and won’t last in an industry of never-ending learning.
While they lack industry knowledge, their “beginner brain” could be a big boon to your agency as they see matters from a different perspective and point of view, and can usually spot inefficiencies with ease. It’s important for junior developers to ask a lot of questions on their quest to become a more advanced programmer. The promotion from junior to mid-level developer should come with a corresponding pay raise to accommodate your more advanced, non-beginner skills that can only be learned from experience.
Not all developers advance to a senior-level position, and that’s completely ok. The mid-level developer is the workhorse developer who gets most of the real, actual work done! They can take a given task, work with project managers on any questions needed to accomplish the task, and work with minimal supervision to get things done.
The mid-level developer should still have a strong desire to learn, which is probably a trait that aligns with all positions on the technical track. Web development, and computing in general, is an industry of constant change. That said, the breadth of knowledge is what separates a mid-level developer from a senior developer.
Just staying at a mid-level developer position does not guarantee a senior-level position after a few years. In fact, most of the promotions I’ve seen over the years of mid-levels to seniors have been unwarranted. It’s ok to stay at a mid-level developer position and to keep a development role at that position, as long as your desired to learn and passion does not vanquish.
When one starts to master their field, becomes highly efficient at their job without any supervision, and starts demonstrating advanced technical know-how with an extreme depth of knowledge, the mid-level developer advances to become a senior developer. This role is not just about programming anymore, but about mentoring and training junior and mid-level developers. Your advanced knowledge of programming and development should be an aura of inspiration to other developers, and the passion for your craft should be seeping through your skin. You’ll most likely be conducting peer code review sessions, as well as running lunch & learn sessions to teach new topics to other developers.
Most senior developers stay seniors for their entire career, and having this position is an honorable one. Your advanced level of learning and honing your craft makes your position as a senior developer highly regarded, and you can become a true leader in your industry at this level. Not wanting to leave or change roles from a senior is a perfectly ok decision, and the correct one in most circumstances. Positions beyond that of a senior-level developer are not necessarily promotions but more so a changing of roles and responsibilities, so if you are a senior and looking towards other opportunities, and love programming, tread carefully. Also, never take a mid-level to senior-level promotion without a raise, as you will definitely have new roles and responsibilities that warrant another payscale.
A lead developer is the most senior of senior developers. When there comes a fork in the road in determining which path to take or which code pattern to use, the lead developer knows the answer.
Lead developers are very knowledgeable about design and architecture patterns. They may eventually create new design patterns, or write boilerplate code for other developers to follow. The lead developer usually has minor management responsibilities, if any. Not all companies have lead developers, and that is ok as long as senior developers can converse and represent a quorum on which direction to take when a problem arises.
If your company doesn’t have a lead developer and there is a senior developer on your team that has been there for many years with intricate knowledge of your business and technical know-how, and you don’t want them to venture elsewhere, …it’s probably be a good idea to give them the promotion already. While just a title, it represents the pinnacle achievement of most developers within an organization, a person with intricate business knowledge who you cannot do business without. And if you are accepting a role of lead developer, make sure it comes with a good pay raise to accommodate your advanced skill set.
Things change when you become a tech or team lead. I grouped both of these positions into one, as they are fairly synonymous with each other and vary only by how a company defines their specific role within a company. Note that I’d consider this position on the “management” track rather than a “technical” track, as it is a step further towards a developer changing paths to a manager and becoming the CTO in the distant future.
The tech (team) lead is responsible for managing a team of developers, keeping morale up, conversing with the developers to uncover impediments with them accomplishing tasks, and perhaps working with project managers in the absence of a solutions architect. The tech lead may have full responsibilities when it comes to hires and fires, and is completely out of day to day development tasks.
The tech lead is primarily a “people person” and a “leader” of the tech team, but doesn’t necessarily make overarching technical decisions, however this could vary from company to company. Developers who want to continue coding should stay far away from this position, and know that becoming a tech lead is not a promotion (although it may come with a pay raise). The tech lead doesn’t necessarily have the best tech chops at the company, but helps facilitate the personnel of the tech team to ensure high morale. Your business usually doesn’t need a tech lead until your company is larger, and should instead place someone in either a lead developer or solutions architect role depending on the company’s needs.
Solutions Architect (SA)
The solutions architect, or SA, is a developer who wears many hats. A saying I heard a while ago is “in the absence of the rest of the team, the solutions architect can run the entire project”. This is mostly true, as the SA can guide daily standups in the absence of a PM in addition to assisting with defining formal business requirements, suggests appropriate code patterns and code libraries to use, creates technical documentation, and occasionally writes code. They’ll usually work with business analysts to ensure requirements are properly defined and help come up with high-level estimates for tasks in the backlog. SA’s will help ensure there are no surprises late in the project, technically or otherwise, and help define the overall architecture of code within a project, along with setting the technical direction for a project to take. They will also manage code review sessions, perhaps with other lead or senior developers, to ensure code quality is top-notch.
Note that I classified this position as a mix of technical and business. The SA’s role is a mix of lead developer, project manager and business analyst, but is not a manager. They are familiar with the entire lifecycle of the software application and usually sit in client research & discovery meetings, flushing out questions and working with business analysts to define the proper project requirements.
A mix of all positions, if the SA isn’t happy at their current position, they can leave and start their own practice as they are familiar with all aspects of running a project and know how to deliver it. They code 20-30% of the time, and don’t mind hopping into fires and putting them out. In the absence of an SA, senior developers and project managers will be mashed together to help fill the roles and responsibilities that would normally be delegated to a solutions architect. The last few years, I’ve mostly identified myself as being a solutions architect.
Project Manager (PM)
The project manager’s primary duty is to ensure the project is delivered on time, and work with clients and developers to clear impediments. They’ll run daily standup calls, have meetings and calls with clients to provide status updates, act as a liaison between client and developer, and are familiar with all aspects of the project at the business level and even technically at a high level.
The PM does not code, run code review sessions, or create random meetings with developers without specific purposes. A good project manager will check in to make sure progress is being made and be around in the event impediments may arise so they can unblock them. They’ll manage resource load to ensure workload is balanced among developers, setup sprints and delivery schedules, and ensure the schedules can be met. In the event of project delays, they must work with developers to establish proper estimates and communicate the updated schedule with the client in a transparent manner.
Project managers should know who to assign tasks based on the developer specialty and availability. They’ll also be responsible for reassigning tasks during developer absence and always ensuring the project is moving forward. Project managers do not manage developers or anyone else on the team, they are managing the project.
Business Analyst (BA)
Business analysts work directly with the client to identify business requirements and write technical documentation for the application being built. BA’s are familiar with the entire workings of the application and run fit/gap analysis to determine what is “out of the box” versus something that needs to be built completely custom.
BA’s typically work directly with solution architects, and to a lesser or greater degree project managers (depending on how the people operate together), to ensure all team members are on the same page and aware of the business requirements to create planned project delivery dates. Formal business requirements documents (BRD’s) are made by the BA for each project, as this is the blueprint and guideline in which a project is defined. They’ll work with solution architects to break down the requirements into actionable tickets that are then put into the backlog. Having a process-oriented nature is very much required to be a great BA, as well as an extreme attention to detail and ability to work with nuances that could arise from the said requirements.
BA’s may also create wireframes and screenshots of actionable processes to be created, or work to create those in coordination with the SA. Project managers should work with BA’s in the event an impediment arises or for a requirement has not been fully flushed out or documented. The solutions architect may also get involved to help identify a solution to the identified problem.
Chief Technical Officer (CTO)
First and foremost, the CTO is responsible for managing the people in their organization. They’ll work with solution architects and tech leads in hires and fires, and ensure the company culture and technical direction of the company is in place.
While the CTO doesn’t code anymore, they should have an in-depth background in programming and architecture and be familiar with and be able to understand the technicalities. CTO’s that are not technical in nature are very ill-fitted to be CTO’s, as they are not intimately familiar with the day-to-day problems at hand or how to solve them.
CTO’s should be setting the technical direction for the company, such as which platforms they should be using, what programming languages should be used (and why), infrastructure & servers, high-level architecture decisions, and be able to establish business processes and procedures. Upcoming platform on the rise? Know about it. Trends within the industry? Yep. New version of PHP coming out next year? Know the benefits it may introduce and also any downsides of upgrading. You’re the visionary of your company for all tech-related problems, so know all about every technical nature possible. You’re also responsible for identifying top technical talent to bring into the company.
While this may not align 100% with your business or company positions, in my experience it very closely aligns with what each position actually entails.
I hope this little guide was helpful to you in either your search for a new position, or trying to define a properly structured role for yourself in your current organization. Some formality is important in properly scaling your business, and helping place people in the positions that best fit your company’s desires and your incoming hires’ skill set.