Developers, Designers, and PMs, Oh My! Understanding the different kinds of Nerds.

Breaking down the different technical roles present in a new software project.

Planning Nerds

From the outside, the process of Planning our development project may not seem like much of a Nerd role. But technical projects require technical processes, and understanding these processes is a discipline in its own right. If you’re looking for someone who can understand the needs of the business, translate those needs into process, and communicate that process to both designers and developers, you’re looking for a Nerd.

There are two primary goals during the Planning process:

1. Ensure that the design and development teams are executing on the business’s current priorities.
2. Ensure that the design and development teams have everything they need to execute efficiently.

These goals map to our two Planning Nerds: the Product Owner and the Project Manager.

Product Owner/Product Manager

The Product Owner (or Product Manager, depending on the team) is arguably one of the most important roles on an Agile team. They act as the liaison between the Business and the Nerds, and are ultimately responsible for the success of the company’s product. Their primary responsibility is two-fold:

1. Build the Right Product: Ensure that the current priorities of the execution team map to both the Business’s Vision and the needs of the Customer.
2. Build the Product Right:Ensure that the work product of the execution team correctly realises both the Business’s Vision and responds to the actual needs of the Customer.

At first glance, these activities may look like they should be performed by the founding team—and they often are. Many famous founders and CEOs come from PO/PM backgrounds: both Reid Hoffman (founder of LinkedIn) and Marissa Meyer (former CEO of Yahoo) came up through the Product Manager tracks at Apple and Google respectively. But for most non-technical founders, the Product Owner’s responsibilities are too granular, too technical, and too time consuming. As we’ve mentioned before, a startup has two jobs: Building and Selling. The role of the Product Owner is a Build role: one focused on informing and executing your vision rather than defining it. 

Having a good Product Owner on your development team gives non-technical founders a single point of contact for the entire product development cycle. The PO is the one responsible for translating your vision into execution tasks. They’re responsible for setting the priorities of the implementation team, making sure that they’re designing and developing the right features. At the end of the sprint, they make sure those features are ready to take to customers, and that we’re tracking the metrics we need to track our product’s success. And at the end of the cycle, they’re responsible for analyzing those metrics, reassessing the business’s strategy and tactics, and suggesting new priorities for the coming cycle.

Put another way, the Product Owner is responsible for managing the process of finding Product-Market Fit. Without them, your implementation team is rudderless, executing on tasks as they come, launching when they’re able, and learning little from each release. Having a good PO can be the difference between stagnant, linear growth and reaching your Hockey Stick early.

Project Manager

Compared to the Product Owner, the Project Manager’s job is more of a traditional management role. Their job is relatively simple: make sure that each member of the implementation team has what they need to execute efficiently.

In practice, many teams split the Project Manager’s responsibilities across other team members, or rely on project management platforms (like Clubhouse, Jira, or Trello) and communications tools (like Slack, Confluence, or Notion) to do this work for them. There’s nothing wrong with this—as long as the rest of the team remains unblocked for the duration of the sprint, we don’t need a dedicated Project Manager to oversee this process.

Design Nerds

After the Product Owner finishes preparing a feature for development, it typically moves next to the Design Team. Here, our User Experience (UX) and User Interface (UI) designers turn the Product Owner’s written feature descriptions, and turn them into wireframes, mockups, and prototypes for the developers to later implement in code.

Put simply, UX design is focused primarily on how the user interacts with the product, while UI design informs how those interactions look and feel. Going back to our analogy of building a house: UX designers are like architects, while UI professionals are more like interior designers. 

User Experience (UX)

As the name suggests, UX Designers are responsible for the entire User Experience. A good UX professional isn’t just concerned with a product’s visual components but also:

• How is the product organized?
• How is information organized and presented to the user?
• How does the product’s design inform, suggest, and provoke actions from the user?
• What is the context the app is used within? What is the user doing, where are they when it’s being used?
• What are the user’s priorities as they navigate the product?

Answering these questions requires a special skillset—one that goes beyond simple visual talent and requires a deep understanding of user psychology, including topics of behavior, motivation, and learning. Having a true UX professional on your team is often the difference between copycat products that are “good enough” and disruptive products that are truly great.

User Interface (UI)

Unlike UX Design, UI Design is focused exclusively on the product’s visual components, how it looks and feels. Good UI design incorporates a wide range of elements, including the product’s brand, its target user, and the platform it calls home: a mobile app helping children learn to read looks very different from a desktop app helping mechanics manage inventory. 

For the most part, UI design is more art than science. While UX professionals need to understand the greater social and business contexts of a product, a UI designer only needs deep knowledge of the medium they’re designing for.

• Building a home:

  • Architecture is very different from art.

    • You don’t need your architect to paint your walls.
    • You shouldn’t expect an artist to be able to construct a blueprint.

  • On the execution level: different skill levels.

    • Wouldn’t want to pay Michelangelo to roll paint on your bedroom walls.
    • Don’t expect your $15/hour contractor to paint the Sistine Chapel.

• Ask your UX professional to see work they’ve done that’s ended up in functioning, existing products.

  • If they only have designs, then they’re not a UX designer.
  • If you don’t have a UX designer, your product might look great, but there’s no guarantee it’ll actually be useful.
  • Needs to fulfill the promises set out in the PRD.

• UI execution requires time, but not necessary expertise.

Leadership v. Execution

The distinction between UX and UI is often blurred, even by designers themselves: many professionals call themselves “UI/UX designers,” regardless of whether they have the training and experience necessary to really excel at UX. When you’re looking to hire a designer, its important to understand what you’re really looking for.

If you’re looking for someone that can handle both roles, focus primarily on the UX component. Any competent UX professional is also capable at UI design. But the opposite isn’t always true. Too many UI designers call themselves “UI/UX designers” without having the skills or experience necessary to handle good UX.

When you’re looking for someone to fill these roles, ask to see designs of theirs that have resulted in actual, functioning products. If they can only show graphic designs, or non-functional pieces (like ads or websites), then its unlikely they’re actually a true UX designer.

Ideally, these roles are separate—or at the very least, our UX designer is supported by one or more UI designers. While its necessary to have the leadership that a true UX professional provides, relying on them for the entirety of our design execution can be expensive and counterproductive. 

Going back to our house analogy: you don’t need your architect to decide which shade of beige your living room should be painted. But you also shouldn’t trust your painter to decide how your new home best makes use of the lot your building on. Building a team with a range of skill levels allows you to assign the right task to the right individual—paying Michelangelo to roll paint on your bedroom walls probably isn’t the best use of your funds.

Development Nerds

With the visual components complete, the project moves into the development phase. Whether you call them Developers, Software Engineers, or Programmers, this is the phase where the true Nerds enter. Their job is to translate the product descriptions and visual designs into code, building your product line by line.

Software Architecture

Like design before, the development process starts with architecture. In the past—before Agile—this role was a separate discipline, handled by a Software Architect. This individual would plan the entire system from top to bottom, describing each component in precise detail, building diagrams related to how those components would interact, and writing schemas for how each piece of data was to be structured. 

Like most aspects of Waterfall, this process feels like common sense. If we’re building a bridge, we don’t want to just start pouring cement into a river—we need exact measurements and calculations. Shouldn’t we approach development the same way?

In practice, the bridge metaphor breaks down. When building software, we’re often not able to see the other side of the river. We don’t know how long it needs to be, or how deep the water is under each support. The process of writing code deals with abstractions, and abstractions are difficult to measure and predict.

More often than not, investing in upfront architecture isn’t worth the time. As our engineers progress, they’ll learn more and more about the system they’re constructing, and these schemas and diagrams will change over time. Because of this, in Agile teams, each individual developer is responsible for handling their own architecture as they progress, rather than relying on a single individual to do everything.

Types of Developers

Developers typically specialize around a single type of software. You may have heard the following terms:

• Backend Developer

  • Someone who focuses primarily on the server side of development. They’re responsible for creating the “backend” that any of your web or mobile applications will communicate with.
  • Gmail example: the backend is responsible for tracking the status of each email you send and receive.

• Frontend Developer

  • Although “frontend” can technically refer to any customer-facing interface (like a mobile app), the term Frontend Engineer exclusively refers to someone who programs web applications.
  • Gmail example: when you open “gmail.com”, the frontend is responsible for getting a list of your emails from the backend, showing that list, and responding to your input as you click around.

• Full-stack Developer

  • Because Web-based applications require both frontend and backend components, its very common for engineers to specialize across the “full stack” (both frontend and backend).

• Mobile Developer

  • The technologies used to build mobile applications are very different from those used to build for the web. Some mobile developers may specialize in just iOS or Android.
  • Gmail example: when you open “gmail.com” in a browser, the application is loaded from the web. When you open the Gmail app on your phone, its always there, even if you don’t have an internet connection.

Within their specialities, developers are typically capable of handling the full range of tasks they may need to complete to build a specific feature. All developers understand basic architecture, databases, network communications, etc. Its only for advanced technologies (AI, Machine Learning, AR/VR, etc.) that you’ll need to find specialists, although that’s becomes less and less necessary as these technologies mature and become commodotized. 

Leadership v. Execution

That doesn’t mean that all developers are created equal, however. Like designers, there is value in understanding the difference between engineering leadership and execution. With design, this distinction was one of profession: UI vs UX. With developers, its mostly one of seniority. 

Software engineering is a deep topic, and one that changes all the time. Building an understanding of all the systems involved in a modern application takes time. Junior engineers are expected to be familiar with the platforms they build on, but their unlikely to know the intricacies of how those platforms behave in every context. That level of understanding only comes with seniority. 

That doesn’t mean you should avoid junior developers. For most tasks, they’re more than capable of handling themselves just fine, and paying senior engineers to do junior work isn’t going to get that work done any faster. Joseph Strauss, chief engineer of the Golden Gate Bridge, isn’t going to be any better at pouring concrete than your local general contractor. But you probably don’t want to cross a bridge designed by one of the guys painting your fence.

The best teams incorporate junior and senior engineers to make sure the hard work is done by experts, and the time consuming work is done by those still learning. Ideally, they also have a single “lead” engineer, who is responsible for making sure each individual’s output is coming together in a cohesive unit. 

When looking at hiring existing teams, ask about the different seniorities present on the development team. If they only have one designation, its a good sign that they hire mostly junior engineers: after all, one of the things that signifies an individual’s promotion to “senior” is their ability to mentor and teach juniors. If everyone is the same level, that’s probably because their senior or lead engineers promote themselves out of the company rather than sticking around.

More Does Not Mean Faster

One of the most common mistakes I see non-technical founders make is believing that adding developers makes the development process go faster. This mistake is rooted in the belief that the development process is similar to laying bricks: if Jane can build the app in 2 weeks, and Sally can build it in 2 weeks, can’t they build it in 1 together?

In reality, software development is more like cooking: adding multiple chefs won’t make the meat cook any faster. While two engineers is definitely better than one, you’ll quickly reach diminishing marginal returns as you scale. 

And even worse, adding too many developers too quickly can actually slow down your progress: with each new addition, you’re increasing the number of people every other member of your team has to communicate with. That means more opportunities for miscommunication and misunderstanding. 

In Fred Brooks’s book on project management, The Mythical Man-Month, he gives the following formula for calculating the number of commuincation channels present in a team:

With just 4 developers, you’ve already created 6 lines of communication. With 5, that number grows to 10. And with 10 developers? 45 discrete lines of communication!

When building development teams, more isn’t always better. Always prefer strong teams to those with a greater headcount.

Testing Nerds

Once a feature is complete, it needs to be tested. Ideally, these tests are done in parallel with development, and each feature is verified as its completed.

Traditionally, testing was the job of the Quality Assurance (QA) team. While having a great QA team is a huge asset to developers, the majority of testing today is done automatically. We’ll talk more about QA teams shortly. For now let’s focus on automated testing.

Automated Testing

Our development team is capable of handling the majority of testing themselves. On larger organizations, this role is occupied by dedicated Test Engineers. For our purposes, our developers will be responsible for testing their own features.

The following tests can be handled via code, without the need of manual intervention:

• Unit Tests

  • Does each component of the new feature work the way the developer intended?
  • Example: On a calculator, when we press the number “2”, does a 2 get input?

• Integration Tests

  • Does each component of the new feature, when put together, work the way the developer intended?
  • Example: On a calculator, does the “+” correctly add 2 numbers together?

• Behavioral Tests

  • Does the new feature respond to user input in the way that it should?
  • Example: When a user presses “2”, “+”, “2”, “=”, does the screen show “4”?

• Regression Tests

  • Do previous features still work properly after adding the new feature?
  • Example: After adding subtraction to our calculator, does our existing addition feature work?

The best Agile teams write tests for each feature developed during a sprint, and add those tests to the larger “test suite”. Automated systems run through the entire suite every time a set of changes is made, verifying that the new changes don’t introduce any new bugs.

Automated testing isn’t perfect, however. Coming up with every possible use case ahead of time can be difficult. Platforms update, new hardware is released, and systems we depend on go down. 

Whether caused by our internal or external changes, bugs are unavoidable. But when they do come up, having an existing test suite in place helps us identify exactly where things went wrong: we know what parts of our system are working properly and which aren’t. If we don’t have an existing test “covering” that aspect of our product, we write a new one, add it to the suite, and expand our protection as we go.

“Coverage” is something you can measure, both on a feature and lines of code basis. When looking at technical partners, ask them about their testing processes, and what their target coverage is. You should aim for 100% coverage on behavioral components, and around 80% on a line-by-line basis. Any more starts to become pedantic, testing for things like “does 2 still equal 2”.

The Role of Quality Assurance (QA)

Although a QA team isn’t explicitly necessary during the development process, they can still be helpful. Bugs can sometimes be difficult to “reproduce” (i.e. trigger in a testing environment), and QA professionals are experts at identifying the exact set of circumstances that cause one to appear. Describing these steps in detail means giving more information to your developers so they don’t have to spend valuable engineering time trying to get a bug to appear.

Once your product is launched, your going to see an influx of bug reports. Real world users can be incredibly creative in the ways the find to break products. And their descriptions of what went wrong aren’t always that helpful. A good QA team can help translate their complaints into discrete tasks for your development team to tackle.

But Does It Do What I Want?

While all of these tests are great, they fail to verify the most important aspect of a startup’s product: does it actually fulfill the vision of the founding team.

This is where “acceptance” tests come in. They determine if a particular feature satisfies a set of “acceptance criteria”: a list of qualitative measures that describe what’s necessary for this feature to be considered “complete”.

While QA teams can verify them, writing acceptance criteria is the job of the Product Owner, and is something done during the Sprint planning process: each development task needs detailed acceptance criteria before an engineer can begin working on it. Only once these criteria are satisfied can it be considered complete.

Deployment Nerds

We’ve reached the finish line: our product is designed, developed, tested, and ready for release. All that’s left is deployment.

What is DevOps, Anyways?

In large organizations, deployment is typically handled by “Developer Operations” or DevOps. Their job is to build and maintain the systems and infrastructure that allow the rest of the development team to deliver features to your customers. Before launch, they prepare the servers and platforms that your application will run on. After launch, its their job to monitor those systems for errors and performance issues, and respond to those issues as quickly as possible.

For smaller teams, DevOps (like testing) usually gets rolled into the development team itself. Platforms like Amazon Web Services (AWS), Google Cloud, or Microsoft Azure allow developers to offload most of this work to more capable providers for a fraction of the cost. “Serverless” architectures, deployed onto services like AWS’s Lambda or Google’s Cloud Functions allow teams to push this to the limit, eliminating the need for server infrastructure altogether. 

Isn’t The Cloud Expensive?

While these services are more expensive then manually running your own servers, the minimal increase in price is more than worth it to have your provider’s army of Site-Reliability Engineers (SREs) supporting your infrastructure 24/7. Comparing the few thousand a year you may spend extra building on top of cloud providers instead of provisioning your own hardware at a data center is pennies compared to the hundreds of thousands in salary you’d need to pay to get comparable support.

As you grow, you may need to add DevOps to your team. But when you’re just starting out, always prefer to outsource that work whenever possible.

That’s a Lot of Roles

That doesn’t mean we need ten different people to fulfill these roles. Solo founders, Jack-of-all-trades technical cofounders, and superstar freelancers exist that can handle this entire workload themselves. But the more we’re able to specialize, the more we’re able to balance expertise with cost, letting us iterate both quickly and efficiently.

In an established company, with endless funds, we could hire each one of these roles full-time. But for a startup, we’re not going to need full-time work from each of these professionals. If we want to take advantage of the efficiencies gained through specialization, that means we need a team that’s capable of spinning up and down as needed, one with experience across the entire design and development process.