How to Build a Successful Development Team

Step 1: Deciding whether a development team is needed at all

Sometimes it’s better not to have a development team. As a rule of thumb:

If the software is your company’s core service or the product itself, it makes sense to create a separate software development team.

If, on the other hand, the software is just a tool for providing a service, the company should consider alternatives. These include:

• Using and adapting existing software solutions
• Using a specialist development service provider

Step 2: Finding the right point in time to create the development team

a) Expect a lead time of 3 to 6 months

Getting a development team up and running takes between three and six months from the time the decision is made to create one. But that assumes you already know how to build such a team.

b) Create the framework required for building the team

Startups and other manufacturers shouldn’t start building their development team until they have:

1. Clarified their product vision
   The product vision is clear and has stood up to initial evaluation by potential customers.
2. Established the intended purpose and stakeholder requirements
   The intended purpose and stakeholder requirements have been determined. These include, above all, the user requirements and the technical requirements.
3. Established the product owner
   There is one person at the company who has internalized this product vision and intended purpose, for example, a product owner.
   This person is available both during and after the development team creation phase.
4. Made financial resources available
   The company has the financial resources required to build a development team.
5. Defined how it will integrate the team
   The company has an idea of how it wants to incorporate its development team into the company. This includes, for example, making a decision on whether the developers will have to work on-site in the office and what expectations there are with regard to time zones and language skills (e.g., German).

Step 3: Deciding how to staff the team

a) Decide on roles

The very definition of which roles exist in a development team determines the culture that will later prevail in this team..

Software architect

For example, the decision to hire a dedicated software architect brings with it both opportunities and risks:

• Opportunities
  The probability that a well-documented, consistent and maintainable software architecture will be created is increased by having a dedicated software architect role.
  This role will help avoid architectural debt, which then has to be expensively paid off after a few years, being accumulated in the first place (as usually happens). Such debt can result in phases where barely any new features are developed, leading to dissatisfaction among the (by then hopefully numerous) customers.
   
• Risks
  The demand for integral architectures can slow the team down during its early “trials and tribulations” and increase the length of time required to create a product-market fit. If this takes too long, the company starves.

On the other hand, if a good, efficient architecture is created, the software development process will be more successful and efficient, and thus even faster. A lot of senior developers understand this fact better than “full-blooded architects.”

Taking knowledgeable and correct decisions on architecture is more important than having a specific role. In an ideal world, senior developers will also be able to make these decisions. Not having a team member dedicated to this role must not be confused with ignoring it completely because it is a role that is needed to map the entire process.

Programmers

The fact that a development team needs passionate software developers should be obvious.

Software tester, quality assurance staff

The software quality assurance role is less obvious. But, for medical startups in particular, it is essential.

The software tester, for example, can wear this hat. In any case, there has to be a person who drives all aspects of software quality assurance right from the start:

• Constructive quality assurance
  This includes the selection/design and continuous improvement of processes (e.g., modeling, test methods) and tools.
   
• Analytical quality assurance
  Software testing, code reviews and static code analysis, including tracking of code metrics and coding guidelines, should be established from day one. Introducing it all later will be difficult and costly to say the least.
  The person in this role should take care to increase the level of automation of, e.g., regression testing and static code analysis as these will act as guard rails in the further development.

b) Decide on seniority levels

Keeping a good balance in terms of seniority levels is important when building the development team. If the spread is too big, hierarchies that are detrimental to team building and to its productivity will emerge.

On the other hand, focusing exclusively on enthusiastic novice programmers is also dangerous because it could damage the quality of your software.

Step 4: Finding the right people for the development team

a) Deciding for or against global teams

Deciding where the team should and may work spatially has an impact on recruiting:

• The pool of possible candidates is obviously bigger if you look globally rather than locally. Since the pandemic, it has become even more difficult to find developers who want to (regularly) come into the office.
   
• Costs for employees in countries such as Germany, Austria and Switzerland are significantly higher than in other countries.
   
• The acceptance of a lengthy application process varies. Internationally, a process that lasts more than two weeks from initial contact to contract offer is too long for a lot of applicants. They will have long since taken an alternative offer.
   
• The same applies to the acceptance of test work: Companies should test the technical skills of applicants but programming tasks that take significantly more than half a day will put applicants off.
   
• The contracts (employment contracts, service agreements) must be designed so that they can be used globally without further adjustments, and not just in terms of language.
   
• The channels for approaching potential applicants differ depending on the geographical search radius as well.

b) Communicate the mission and vision

The more potential candidates learn about the job, the more likely you are to find the right person. Therefore, it can be helpful to conduct the search through multiple channels, for example:

• Classic job portals
• Searching for and contacting people directly on LinkedIn
• Analysis of forums and searching for active and relevant people
• Searching on GitHub and targeted approaches. It’s not just open-source projects with relevant technologies that can be used. Countries such as Brazil have their own repositories that function as job markets

Once you have found a potentially suitable candidate, you should hold an interview right away, introducing the company and product vision. One advantage medical startups have is that they contribute towards making life better for patients and the healthcare system. This mission can be a big attraction for developers.

c) Make your selection carefully

Dare to look for “polyglot” developers. When you have a hammer, everything looks like a nail. Even if your HR department is not very technically oriented, they can ask what the advantages of framework A are compared to framework B (e.g., "How do JavaScript and Python differ?" or "What are the key differences between Angular and React.js?"), are and under which circumstances the candidate would recommend which.

Look for quality-oriented developers. Especially in the web environment, you can take a lot of shortcuts that could have regulatory repercussions later for a medical device manufacturer. One possible question in the interview would be how the developer feels about writing tests themselves.

Step 5: Ensuring good onboarding

New members of the development team need to know what to expect and what is expected of them from the very first day.

a) Clarify the importance of the QMS straight away

This includes clearly communicating how important quality management and documentation are for product conformity and success.

Accordingly, new team members must immediately learn these requirements and receive feedback on how well they are meeting them.

b) Enable self-efficacy

Small, limited tasks with clear results create an early sense of achievement and therefore reduce the dropout rate in the first few weeks.

c) Communicate goals clearly

People who haven’t developed medical devices before are often not sure about how to meet regulatory requirements (see section a)). Examples, “sample solutions” and quick feedback can help here.

Step 6: Continuously support the (collaborative) work of the development team

a) Through processes and procedures

The point of processes is to ensure consistent quality without having to depend on the performance of individuals. Therefore, agreed and lived processes and procedures are a prerequisite for effective and efficient collaboration.

Examples of these processes and procedures include:

• Coordination with the product owner
  The development team needs clear information on how and how often it will receive input (especially requirements) from the product owner and how it will receive feedback on whether the output meets the requirements.
  A lot of companies use Scrum for this with sprint lengths of between two and four weeks.
   
• Architecture development
  The development team should decide for itself who makes the development decisions, when they are made and how they are documented. Transparent and collaborative decision-making has proven to be effective.
   
• Code reviews
  Particularly for development teams working remotely, code reviews and merge requests are vital for ensuring that members receive feedback quickly and become familiar with the code base as a whole. This helps improve the quality of the software.
   
• Continuous improvement
  Scrum retrospectives are a key tool for learning from mistakes and continuously improving processes, methods and tools. The development team should be given freedom with regard to this continuous improvement as well as the responsibility for it.
   
• Software releases
  The team should take the software release process seriously, and not just because IEC 62304 requires this release. It should be seen as a moment of truth:Is really checked that we have taken all the measures required to ensure software quality? Is the company really only releasing software of the required quality – or is it giving in to stakeholder or customer pressure?If the organization does not act consistently here, it will contradict all its statements about how important software quality is. Software developers notice these discrepancies immediately.

b) With tools

Even the best tools are worthless if no one uses them. This happens when:

• Their usability is poor, and familiarization and workflows are too cumbersome
• The tools do not help with any of the activities that the developers actually perform
• There are no defaults, and everyone uses their own tool stack

Development tools

There is no lack of tools. Established all-in-one solutions, such as Gitlab, integrate all the necessary functionalities, for example:

• Version and configuration management
• Management of merge requests
• Automation (CI/CD)
• Issue tracking
• Documentation

Atlassian also offers a powerful tool chain but becomes disproportionately expensive as team size grows.

Communication tools

Especially if the development team is working remotely, the tools must support synchronous and asynchronous communication.

The tool landscape is huge: MS Teams, Rocket.Chat, Slack, IRC, Twist, Discord as well as the solutions mentioned above, such as Gitlab, offer the necessary functionalities and, generally, options for integration with other tools as well.

c) Working with (communication) rules

Good communication tools alone do not guarantee good communication within the development team. Therefore, the team also needs additional rules and agreements:

• Reaction times
• Communication channels
• cc policy
• Office hours (from when until when can the team communicate/ignore messages?)

7. Conclusion and summary

Building a high-performance development team is not rocket science. But there are countless little things that need to be taken care of if you want the team to succeed. The six steps above will help you get a lot of these little things right.

These steps are not only useful for startups, they are also useful for larger and established companies that want to improve their teams’ performance.

This article is based on a podcast with Martin Schulze and Christian Johner (in German).

Martin Schulze is founder and owner of the company slash-m. He specializes in helping startups put together and establish high-performance development teams.

The Johner Institute has helped hundreds of startups through the medical device authorization process. Its subsidiary Johner Medical acts as the distributor for startups that do not yet have a certified QM system and provides companies with a comprehensive tool landscape. Contact us here if you would like to learn more or to request support.