software roles

Here is a brief description of software development roles based on how I like to run teams. It is usually the case that some people take on more than one of these roles.

• CTO: software vision and strategy. This person is often both internally and externally focused. Sometimes this person helps with recruiting and fundraising.
• Product manager: requirements gathering, and publisher of official plans (signed off by engineering and marketing etc). This person is ideally strategic/visionary, so their research can be efficiently guided by instinct vs only dry slow research. (Sometimes this person also does some UI design, but best only when the high level product management function is then provided by someone else.)
• VP Engineering / Engineering Manager: decides who does what and manages them on a daily basis. In charge of entire technology budget and of all engineering hiring. This leader should be very plugged into the business metrics and plan.
• Software architect: takes short and long term input from product manager, CTO, VP Engineering, CEO etc, and then writes up a scalable architecture plan which will support the long term evolution of a software platform. This person should guide and review any architecture work by other engineers on the team. The software architect should be a prolific coder to make sure their guidance is not theoretical.
• QA Manager: responsible for building customer-focused quality standards and measurements, and drives application and system-level testing. Manages the bugsbase. Works with engineering manager to make sure programmers are not allowed to develop new features until there are no confusions with existing features. (99% of organizations fail at this important task, which is why most software sucks.) Usually includes some autotest. Should also work with engineering manager to make sure programmers build and use unit testing. Makes sure that QA engineers are involved at the earliest stages, working hand-in-hand with development.
• Release engineering: builds and manages the tools for efficient building of the product, ideally which happens at each code check-in, and which then runs automated testing to quickly report when someone breaks the build. This function also manages software branches, with the "trunk" being the main active area for new development. Note: my bias is that one of the strongest and most prolific software engineers take a very active role in setting and managing the release engineering process and tools. I'm amazed at the slow pace of most organizations (doing monthly releases instead of weekly, or quarterly instead of monthly) due to bad release engineering practices.
• Optional. Product designer: decides what features should be done when and how. This is different from a UI designer who usually does not decide which features to do when. It is extremely difficult to find talented product designers, so usually this role is played (often poorly) by others, resulting in the team developing some features less important/used than others.
• Optional. Program manager: helps engineering manager with cross-functional project management, particularly focused on how engineering interfaces with sales, marketing, partners and other organizations. This person often becomes the official publisher of high level schedule for non-engineering parties. (Often this role is played by the engineering manager.)
• User Interface Designer: designs the user interface :) This role is often played by the product manager or by the UI engineer. It is usually impossible to find good UI Designers, and even when found, it is usually impossible to setup the perfect team around them.
• Graphic designer: makes it look pretty. This role is often (unfortunately) played by the UI designer, product manager, or (god help us) engineer.
• UI Software Engineer: implements design, but also providing ideas and feedback. In many cases, a talented UI Software Engineer does the UI Design. Although, in the vast majority of cases, such engineers are bad and they and their management does not realize it, and their product does not then grow by word of mouth, but instead requires expensive sales and marketing.
• Usability test engineer. Do task-based validation of features and UI design. This person must have excellent, unbiased listening skills, and be able to quickly and accurately record problems. (Unfortunately, many usability engineers mistake themselves for UI designers. This is bad since most usability engineers suck at design, and also, if they think they are doing design, by definition it means that they usually then suck at listening.) Note also that having great usability testing with bad user interface design is like driving a train from the rear. See also usability testing.