Software team structures
/A common question we get asked by new companies in our field is:
What’s the best team structure in a software company?
Our answer to this question had been an easy one: “as flat as possible” meaning a structure where there are that many levels - ideally no middle managers just the software developers or other technical roles reporting directly to the team lead who barely ever needs to report to anyone above.
This is a great answer. It takes away the biggest problems in software development companies and introduces creativity, ownership and most importantly collaboration. But this answer is by itself not good enough. As a company grows, as it takes in more and more projects requiring larger number of teams which then collaborates with each other the flatness that gave all the flexibilities in a smaller organization starts to introduce confusion and chaos. So some more structure is needed. What that ideal structure might be is a question that’s very specific to the nature of the company in question and the culture that it embraces. For us at Kaz it’s been moving towards more independently operating teams that operate under groups or wings of technology. We call them companies under companies under companies. This may not work for everyone. Today let’s go over some common software roles we hear about and try coming up with generalized views about what those roles are supposed to do. This might give us some ideas about what roles our own companies might require and where to fit them.
Common Software Roles
Some of the common software roles we see in the industry worldwide are as follows:
Chief Technical Officer (CTO)
CTO is a confusing role, it’s a role that requires purely technical skills most of the time but sometimes it needs to be as non-technical as can be. At startups, the CTO is often a technical cofounder and that role is all about jumping into coding and jumping out to join a marketing meeting. But the same CTO role is a large organizations is very different. A CTO at such an organization is mostly outward facing - looking at clients, product and marketing teams and giving a voice to technical angle on all business conversations. Rarely does a CTO at large organization ever dive into the code or even participates in technical architecture. They participate in business development meetings, frequently helping to land large partnerships or sales. Many spend a lot of time evangelizing the development activities of the organization to the wider world: sharing the company’s innovations and discovering opportunities in the market which match up well with the company’s core competencies.
VP of Engineering or Director of Engineering
The Director of engineering’s role is what most people usually think of CTO’s role. This role is frequently responsible for building the engineering team, creating work process of the technical team and establishing the engineering culture and operations. While CTOs often face outwards - towards business and clients, the Director of Engineering faces inward - towards the technical workforce, their daily needs.
The best directors of Engineering constantly monitor the team’s progress, process and culture. She encourages the technical staff to use the right tools, the right platforms, even the right programming libraries. She may have strong views about how the teams should operation, how the meetings should be run, hold specific kinds of meetings at specific times in order to foster better collaboration with fewer interruptions.
In smaller organization it doesn’t makes sense to increase hierarchy by having separate CTO and director of technology. These two roles can easily be fused together in such organizations but as soon as business starts to expand this is one role that needs to split first.
Chief Architect & Software Architect
The architects in a software organization are usually the uber geeks. They are the super star programmers who never wants to be in any kind of management role and want to stay as close to coding as possible. In small organizations, the chief architect is sometimes the technical co-founder who knows that she never wants the responsibilities of a CTO as the company grows. They are just not interested to take all the hassles of customer facing, project facing, investor facing and team management facing responsibilities that comes with the CTO or even the director of engineering roles.
The architect is the person responsible for selecting technology stacks, planning technical solutions, designing collaborations and interfaces between systems, etc. As the company matures, the chief architect may also need to work closely with the CTO and at many companies, the CTO also serves as the chief architect.
Project Manager
This is the big difficult role. Sometimes this is the role that everyone in company is looking at. In most companies this is the role where a technical staff decides the future of her career - does she want to stay in development and aim for architect roles or does she want to go more towards management roles.
A project manger is in charge of managing the workflow of an engineering team. She interfaces with both product leaders and an engineering leader such as director of Engineering or the CTO to manage the work backlogs, monitor the progress of tasks, create detailed progress reports, track milestone, manage burn down charts, etc. In smaller companies the project manager is the multi-hatted role of a director of technology and team lead.
Technical Lead/Team Lead
The Team Lead is the leader of a small number of technical staff that forms a particular team in the project’s workflow. Typically a team lead is a senior engineer who takes on the role of mentors and guides for the rest of the team. Usually, developers report to a team lead who then reports to the project manager to give a summary of what his team is doing. The team lead is usually coding all the time and the team lead role is a more a part-time role she has to take up when the time comes. In some companies she may be responsible for the team’s code quality, code reviews and managing the team’s output standards.
Various software engineering roles
At the team level are the real workers in a software company - the people who really make it all happen. Based on different levels of experience you have some of the following roles.
Principal Software Engineer
Senior Software Engineer
Software Engineer/Developer
Junior Software Engineer/Developer
Trainee Software Engineer/Developer
These are the people who gets things done, who write the code according to spec, fix bugs and creates solutions to problems.
So these are some of the basic roles. But what happens when we look at the giants like MS or Google? With technical teams that are size of small towns obviously having just few levels in the roles isn’t enough. So for Software Development Engineering (SDE) roles there are hierarchies and more levels and structure. Just to get a glimpse, I’ll close it up today with a comparison of the software roles at our 3 giant friend’s.
