Startup Crash Course 101: How to Put Together & Manage a Tech Team

How to put together and manage a tech team?

So you’ve got a world-changing idea that you want to develop into an app or online system? You start gathering ideas, pitching these ideas to potential investors, and reach the stage of development. So, what next?

There are two roads to take during this step: develop your own tech team or outsource it.

Arcanys has worked with a lot of startups who want to get their products off the ground—fast, partnering with us to make the technical development as seamless as possible. Since 2010, we’ve worked with several hundreds of teams and have measured all the ways teams could work more efficiently, including being able to identify setups that are bound to fail.

Watch this Crash Course for startups by Arcanys Co-Founder Frederic Joye as he talks about how to put together, manage, and inspire your startup’s dream tech team. He also discusses how to salvage failed projects and what makes or breaks your chances of startup success!

IF YOU PREFER TO READ… [TRANSCRIPT]

If you prefer to read thru the discussion, here’s a transcript below:

Hello everyone, and thanks for watching this video for startups, where I will introduce you to the best practices of software development and outsourcing in particular: HOW TO MANAGE YOUR TECH TEAM.

Let’s get started! I’ll briefly introduce myself so that you understand why I am qualified to talk about how to manage a tech team for startups.

ABOUT ARCANYS

Since 2010, we’ve worked with several hundreds of teams and we have measured all the ways teams could work more efficiently, and have also witnessed a lot of setups that were bound to fail.

Over the years, we have perfected our model to make sure that we increase the chances of success of any project we work on.

We are so confident about the value we deliver that we invest in startups we believe in, where we know we can make a huge difference in the speed of commercial development for that startup.

We are both investors and providers willing to take the risk of working along with a team to boost their chances of success.

For example, one of the startups we have worked with has been sold to a bigger group for more than USD 10M. A dedicated team from Arcanys is the core of their success, with their team at Arcanys being bigger than in their offices in Sweden.

Today, we are collaborating with the company that purchased them, because they always wanted to outsource but failed 3 times. It’s a perfect opportunity to show them that outsourcing can work when both partners are right for each other.

Another example is a startup we have invested in at the very start which we managed to create some traction creating a product that is good enough, got funding of USD 500,000 from 500 startups Asia. Today, it is now valued at more than USD 5M (which is a lot in Asia vs the USA).

What are your main struggles with your tech team today? This webinar seeks to give those a solution.

CORE FOCUS OF A TECH TEAM

Basically, when you work in tech, there are 2 main things to look after:

1. People

their roles
knowledge
how to manage them

2. Processes

when to use them
how to use them

People / Roles

In technology, there are a lot of different roles. Some of them can be the same person, but this is not the case for all of them. Let me go through them:

Graphic Designer / UI / UX: the person who will help you define the look and feel of your application for the user and the admin parts.

Business Analyst: The BA will usually work before or together with the Designer to work on the requirements and specifications of a project. The BA’s role is to understand the processes, map them, describe what users need and help the designer (along with the founders) come up with the features, look and feel of the application.

Once the requirements are known and validated, at least for the minimum viable product (MVP), this is when the developers come into play.

Frontend Developer: the kind of developer who will program the visible part of the application that users and admins will interact with.

Backend Developer: the developer who will take care of the server and application program interface (API), where the heavy lifting of the application happens.

Full Stack Developer: a developer who masters both skills of the frontend and backend.

DevOps: a relatively new term especially in the cloud. It is a clipped compound of “software DEVelopment” and “information technology OPerationS”, where the DevOps is a hybrid between a developer and someone who also understands infrastructure (QA, automation, hardcore cloud or physical server issues).

Architect: is a high-level developer that makes software design choices and sets the technical standards including coding standards, tools, and platforms. Usually, this is the role of the CTO in a startup. In most cases, we think the CTO should be a central person and even a co-founder in technology startups.

Testers: are often forgotten, but they are central to building a product because they are the one who guarantees the reliability of the software when delivered.

They test the application both from a user point of view and from a technical / performance point of view to make sure the applications are working as expected.

It is important to mention that the tester is a different person than the developer, simply because they are two different jobs and no developer is very good at testing their own code.

Project Manager: In some cases, there is a need for a Project Manager, but most of the time, this role is (at least with us) played by the lead developer.

We think that every person in a technological project must be technical, and this is no exception for the PM. Usually, a PM’s role is to add a layer to the project and is prone to conveying misunderstandings.

We like to have this role blended with the lead developer as long as the team is not too big.

Product Owner: is the person who is in charge of the vision of what he wants to build and conveys that vision to the team. Usually, this is the client or the founder.

HOW STARTUPS CAN INCREASE CHANCES OF SUCCESS

There are usually a lot of processes to keep in mind. At Arcanys, we have about 200 people (including the client side) working at any given time, on about 20 concurrent projects.

We can’t mess with information and at any given time, we need to be in control of our projects and know what is happening. We do this on a daily basis.

For a startup, a few simple processes need to be in place to increase the chances of success, and I’ll go through them:

Managing requirements
Working on lean software methodology, and how to be careful with this concept
Estimating the features of a project and the project as a whole
Creating an architectural design based on the specifications
Managing the team and the communication
And lastly, to never forget user and software testing

COURSE ACTIVITY

Which of these processes are you not following? Why? Which process are you struggling with, and why?

MANAGING RISKS

The number one risk factor in starting a tech startup is the mismanagement of the specifications and business requirements.

Everything is urgent in a startup. Most especially building the MVP.

However when building the tech, there are fast and slow phases. Some things can’t be rushed even though the pressure to push something out is high. Neglecting requirements is one of the most costly mistakes.

Sending your product down to programming without thinking about the whole picture can be deadly for a startup.

Some founders have a hard time sitting down to focus on important requirements. Here and there they have a bit of time, but they’d rather write a few lines quickly and ask a tech guy to give a price/ estimate and deliver something.

Working on the first version of the product is the most important task in a startup. It’s even more important than raising money and finding clients.

Every month, we have to dig into projects that have not been well specified, and it’s a real nightmare to fix. Usually, it’s more costly than to start from scratch, but starting from scratch slows down the release of new features in the short term, and this can really be a problem when you’re facing tough competition.

Again, the number one risk factor for startups is the mismanagement of the specifications and business requirements.

BUILDING YOUR FIRST PRODUCT

Building a house is a good analogy when you think about building your first product.

We have clients who come to us with a one-pager of what they want to build. It looks like a sketch and they’re like: How much will it cost, and how much time will it take? Well, what do you think?

Is this a little hut in the jungle or like a big mansion with a swimming pool? At this stage, it’s in the eyes of the beholder. There are too many uncertainties and whoever gives a price and a timeline for this sketch is making a big mistake.

If your requirements are unclear, you are forcing your developers or your provider to make guesses on your behalf, as well as planning for you while changing your mind all the time until you have what you want.

This pushes you into a messy project that very likely will last much longer than you want. Do you want that?

And if someone gives you a fixed timeline or even a fixed price, expect them to come back later with additional requests in terms of time or payments. The price will go up, and the project will take longer, that’s if it ever gets released because the architectural design would have failed.

After having worked on hundreds of projects, we don’t work on projects where the specifications are poorly done, we always push our clients to work on their requirements by themselves with our guidance, or we work with them to finish it.

Before pushing for development, make sure you determine your broad requirements first.

TOP 3 ROLES YOUR TECH STARTUP NEEDS TO FILL

So, when you build requirements, who do you need?

There are mainly 3 roles that matter when building requirements:

The designer
The business analyst
The product owner

It might not always be 3 different people, because some can fill 2 roles at the same time. Other stakeholders can also give their input and share their opinion, but be careful; they should not always be listened to (they merely guide you on your decisions but you should make the final call).

For example, a tester or a developer might think of technical impediments to building the system and suggest things that make him comfortable or avoid things that he might feel too hard to build – rather than think about the best functionality for the user.

First, you should come up with the ideal tool you really want for your users, then you turn to your developers and ask them how much time they need to build each functionality.

Think of Apple, where the products always start from a design perspective and then goes to the engineers, not the other way around.

BUILDING YOUR UI/ UX DESIGN AND REQUIREMENTS DOCUMENT

Here is an example of UI / UX design and requirements document.

Once your requirements are well done, you should have something like wireframes or with final design (much better) in an interactive prototype and a simple written requirements document that describes the business rules and business logic behind your system.

In the example, you’ll see that the designs also explain the flow between the screens and the actions from each button. This is very important to describe to whoever will work on your project.

Most of the time, when we receive requirements, the entire admin section is missing.

Most people only think of the end-user-facing app but forget about all the management and reporting features that you, as a business owner should have.

Do not be like this!

One very important step is to have all the decision makers agree on the design of your application, at least for the MVP.

You should probably also get feedback from a few prospects, but you need to be careful with it. Most clients don’t know too well what they need and will ask you for a lot of additional features. They might not understand the technology and can’t always imagine themselves using the software, so you might hear a lot of suggestions that sound good, but you must also be careful about scope creep.

Remember:

You need to reconsider (and be picky about) most ideas in your MVP and stick to the core functionalities that are needed for this first shippable product.

LEAN SOFTWARE METHODOLOGY FOR STARTUPS

While it’s usually a very good methodology, you may want to be very careful about using this for your MVP when you’re tight with cash.

And what startup isn’t?

Building the first version of your MVP is when you really need to sort out the design and the requirements and build a product you can ship and test, within your timelines and your budget.

Budgets are not always extensible and the competition doesn’t wait for you.

When you have your first product and your first users, this is when you can work more easily with fast iteration about your product without necessarily planning for the next features. This might help you get a better product, if you have strong adherence to the principles, and you manage to get rapid customer feedback.

We’ve seen it happen with a few clients who were not that disciplined in various areas, and if we didn’t put them back on track, they could have doubled their budget for their MVP, with a lot of things developed for nothing, and then trashed when they change their minds.

One good way to get validation is to integrate the design in prototyping tools. You get a feel of the use of the app without coding anything yet.

We use either Invision or Proto.io.

A CRITICAL STEP: PROJECT ESTIMATIONS

Okay, so now we’ll talk about one extremely important process that most developers hate, and they usually (and unfortunately) skip this step. But this leads to important project delays between what is expected and what really happens.

Basically, it’s like telling your friends that you will meet them at point B at a given time but don’t even bother checking how to get there (because you’ve never done it, and no one has).

How much time it will take, if there is traffic or not, and worse, with what means of transportation that will take you from A to B.

And then think you can do it in one hour. In truth, you have a 99% chance of being late or never making it at all!

So how do you estimate a project?

First, it only works if the project is well defined, with detailed specifications and designs of the UI.

Once you have your specifications, developers will break down the specifications in what we call user stories, which should be chunks of work of 1 to 8 hours generally. If it’s bigger than 8 hours, it means that it can be broken down further, and/ or that the understanding of the task is not enough, and it needs to be further clarified.

This process usually takes a lot of time but saves so much time down the road that it’s the best way to start. Also, knowing how much time each feature takes to do allows you to better plan and prioritize how your application will be built.

The end result will likely shock you in terms of how many hours it will take, and this is normal because we always think things will go quicker than they actually do.

COURSE ACTIVITY

Have you gone through this process? If not, is there anything that prevented you from doing it?

VALIDATING FOR SMARTER BUSINESS DECISIONS

Besides forcing the breakdown of a complex project into smaller, more manageable tasks, it also helps the client validate the features and the product to be well understood. It allows separating the project into different phases.

As I mentioned earlier, most of the time, business people do not realize how much time each of the functionalities they have in mind really take.

Validation helps make smarter business decisions.

If you don’t have access to this information, you will keep on throwing ideas thinking they can all be quickly done and that each one of them takes more or less the same time to accomplish.

In reality, some features might take 20 hours to build, and others 200 hours. But once you give the visibility to the product owner, then, they can assign dollar amounts to the functionalities and decide what to remove and what to keep for later.

ARCHITECTURAL DESIGN IMPLICATIONS

Once you’re set with what you want to build now and later, it’s time to look at the architectural design.

This is a very simple example, but developers must think about how they will put the system in place, along with the architect in charge of the project.

Along with the estimated dev time, your developers should produce an architectural diagram where they could explain to you how the systems will interact together.

This step of thinking about the architecture of the system needs to be done no matter what, and it’s better to do it as early as possible (as they might review it as time goes).

COURSE ACTIVITY

Did you plan the architectural design before? If not, have you struggled with it later?

RAMPING UP YOUR DEV TEAM

Once you are ready with your requirements (know how you should build your system, and how many hours of work is necessary), it would be the best time to scale from 1-2 coding founders to a few developers and ship the MVP within 2 to 4 months.

This is one of the steps where outsourcing could be most useful.

You can add a few developers to ship your product quickly and easily reduce the team size after the initial launch if you don’t have enough cash to maintain an entire team.

Remember: Competition doesn’t wait for you to be done.

When ramping up your team, you should reconsider having project managers (PM).

Even as a big company, we try to avoid having them as much as possible. We recommend them when the clients are not technical in order to add a buffer between the business and the developers because a communication mismatch and crazy added features issues can happen often.

We usually recommend our technical clients to directly talk to our lead developer who will dedicate 10% – 20% of his time as a PM, which eventually has to be done by speaking with the PM if there is one. We notice that this makes projects more efficient.

We also have noticed that adding layers to a project can increase risks of errors most of the time when relaying specifications.

AGILE PROJECT MANAGEMENT

You want to make sure your team is using proper tools to manage the project.

In our case, we use Jira, which is a productivity tool that we have complemented with a tool we created (a specific in-house software) that automatically uploads the user stories to it.

This makes our job easier for estimation purposes. It comes with time estimates that creates a task for each user story.

Take note: always look for ways to make things easier.

With this, we can organize projects and its phases, know if we are on track compared to what we have estimated, understand the problems and correct them as quickly as possible.

Our clients and the project managers have constant access to this information. They receive daily updates where they can check the discrepancies and understand where the team struggles and fix it before it’s too late.

THE VALUE OF PRODUCT TESTERS

One of the most underestimated functions in a software project is testing and the value of a professional tester.

If there is no tester, the founders will spend a lot more time doing testing, and while the functional testing can be well done by founders, a lot of other aspects can be missed.

Professional testers are usually specifically trained for this task and add a lot of value in saving some development time and increasing the quality of the shipped product.

In addition, testers use standardized practices to handle their tasks quickly—from test case creation to execution and bug reporting with how to reproduce them. This saves a lot of time for developers and costs for the founders.

GETTING VALUABLE FEEDBACK

Once you have sorted an MVP that you can push, do it. Don’t wait for it to be perfect, but it needs to be useable.

Take note:

When you push it to users, you have to make sure that you engage with them, make sure they use your software and talk with them to understand what they do, why they do it, what is missing, etc.

Once you get valuable feedback, fix what doesn’t work until you get it right.

Depending on the business model, they can either keep using it for free or pay for it down the line.

Don’t spend too much on marketing until you get something that really works, otherwise, you’ll simply throw money out of the window.

OUTSOURCING BEST PRACTICES FOR STARTUPS

Let’s talk about outsourcing best practices or working with an agency near you.

Thinking if outsourcing can benefit your startup?

When you decide to work with an outsourcing provider and/ or freelancers in another country you significantly reduce costs.

But, consider this first:

You have to be very careful with the differences between cultures.

There is a way to work with each culture, and if you don’t understand that and manage different people the way you do with people in your own culture, you may end up not having the results you expected and also end up having misunderstandings.

So when you outsource, outsource smarter.

You better make sure you understand who you are working with and their culture. There is an interesting book about this that I suggest you look into: When Cultures Collide by Richard D. Lewis.

COURSE ACTIVITY

Have you experienced some cultural issues in your projects so far? How have you worked around them? Have you stopped working with some people because you thought you were having too many communication issues?

FIXED COST PROJECTS: WHAT YOU NEED TO KNOW

I know most people like the idea of having a fixed-cost project to mitigate the risks, but with years of experience, we (and the majority of the industry) have experienced that it works only in the cases where the project is extremely well defined.

This works, for example, for a small and well-defined mobile application. But for the rest, it rarely works because there is always someone on the losing end.

When a provider underestimates a project (not enough requirements, not senior enough, not the right processes, misunderstandings):

Once the provider has spent a number of hours he said he would spend, he is going to start cutting corners and decrease the quality of the product, and after a while, he will ask for more money. Otherwise, he ditches the project.

This can really kill you.

On the other hand, if he has overbilled you, he will earn a lot and you will lose:

This rarely happens, because if you do your job in evaluating the right provider and evaluate 3-4, this shouldn’t happen to you. Usually, providers with fixed prices will give you a low price to get the project and trick you later by asking more money because this and that were not specified.

And if you want to have it, you need to pay more.

In addition, fixed price projects providers will try to limit collaboration with you, because it takes a lot of time and they want to avoid the client from adding more features along the way that are not in the initial scope.

This results in loss of flexibility, which usually is vital for a startup.

I also have written an eBook about How to Evaluate Development Firms When Outsourcing. I recommend reading it if you’re thinking about outsourcing your tech startup and knowing how to weigh the costs.

COURSE ACTIVITY

Have you had any good or bad experiences with fixed costs projects? Could you share some?
Do you have questions regarding this model?

OUTSOURCING ISSUES THAT YOU NEED TO KNOW ABOUT

WORKING ON A PROFICIENT TECHNOLOGY

Another thing we see pretty often are clients that come to us because they have problems with their current provider who has built their entire system on a proprietary framework on their own. This is a big issue because most of the time it’s an outdated technology and it’s very hard to work on these projects without having to restart from scratch.

One of the few steps to keep yourself more independent from a single provider / freelancer:

Make sure you work on a technology your provider is proficient with, but that is also widespread, with a striving community, that is up-to-date and that will be easy to hand over.

Another issue we see sometimes are with clients who do not have complete control over their source code, and when the relationship with their provider turns sour, the provider cuts access to the latest source code.

If you never get the code back, it can take someone a few hard months of work to salvage a project, and hence delay the shipping of a product or miss a lot on revenues from new features.

Make sure you have your own Bickbucket, Github, or GitLab for example.

MAKING SURE YOU HAVE THE RIGHT TEAM

A lot of providers put their A-team for you at the beginning of a project and then switch to more junior people.

If you are on a monthly contract, the provider should commit to keeping the developers on the project or compensate when they change for some reason.

VERY IMPORTANT: Put in clauses to keep your team members on board.

A real partner will work with you to make sure you get the most out of your relationship and encourage further learning for the people on the project. Think about them as an extension of your own employees that stay on the long term with you.

You have to understand what the provider does to make sure they will do everything to reduce the attrition rate. Make sure as well that your outsourced partner is at least as organized as you are.

Another important tip:

Always have a high-level architect involved in the project.

If he is the architect of the provider, make sure he has the experience required for the job as bad architectural choices can create issues down the road.

If you are not sure about the skills of your architect or the one from the provider, you can hire someone for a few hours to validate the architecture of the solution. This is a small cost that can save you a lot of hassles down the road.

WHY A CTO WHO KNOWS HOW TO CODE IS IMPORTANT

One thing we really look at when we work with a startup, and even more importantly when we invest in a startup, is if they have a coding CTO.

This adds a lot of value to the project, and also to the startup when you want to raise funds.

Why is it crucial?

It means that, at least on paper, the key technology is in-house and that the knowledge is mastered in-house too.

This person should establish coding standards super early to make sure everyone is coding the same way, which in turn facilitates onboarding and transitions.

This is a very, very important point to remember:

The coding CTO should do frequent code reviews. This is scientifically proven to be the best investment you can do to increase the quality of your product, and also to train your team as quickly as possible.

This also brings the team together to share experiences, points of view, and fast-track their development. It’s a great coaching and mentoring process.

COURSE ACTIVITY

How often do you do code reviews in your projects?

THE COSTS OF A DELAYED MVP

Always keep in mind the costs of delays of an MVP. This is something people often underestimate.

You need to be ruthless when removing features.

Every day that your product doesn’t hit the market, it increases the financial cost of missed revenues, the cost of paying your developers to get things done, the unpaid founders, and how about competitors gaining traction while you are still in development and haven’t shipped anything?

Don’t try to build the best product in the world (at first).

Do things (in the beginning) that don’t scale.

STARTUPS THAT CRUSHED IT

STRIPE A payment company that launched by creating merchant accounts very quickly by doing things manually to see if they had traction. They were even faxing papers to create the merchant accounts and only launched their automated onboarding months later. But in the meantime, they took the market and crushed the competition.

AIRBNB For the first 3 years, the CEO was living at the hosts’ home in CA where he became an advocate of his company and knew the clients super well.

ARCANYS LABS: HELPING STARTUPS WITH FUNDING AND SUPPORT

We get hired for quickly delivering software development. At the same time, we are also interested in helping startups scale super quickly to help release products quickly to the market by investing in them.

We have a team of UI/UX designers, we have teams of Front-end Developers, and Back-end Developers. We have Testers, some Project Managers, and we recently added a 24/7 team that looks up at infrastructures and customer support.

Most importantly, this initiative help bring in cash investments.

If you’re a startup looking for mentoring and startup support, I urge you to check out Arcanys Labs. It is a unique “smart money” investment model that connects startups with product development support, funding and the right network.

BONUS: Read about the Common Startup Mistakes most founders make.

RECOMMENDED RESOURCES

Blitzscaling Series:

Episode 10 – SurveyMonkey CTO
Episode 11 – Stripe CEO

Books