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.
