Leading a team

There are many ways for lead a development team. Some of them require a work of long term, and other are more practical. The long term is not viable, because the members of a team in this sector is changing constantly.

I know three ways for lead a team that is succesfull if we combine them:

Leader with direct orders
table-militar-startupThis dictatorial way can be used when a project is in crisis, about to fall. In this case the team need a decisive leader and with personality. Also is helpful when must be a make radical changes. Sometimes the members resist to radical changes, or to new labor policies.

If you have member without compromise or enthusiasm you would up the team with this way. But this not good to long term, because some people can be desmotivated.

The coach leader

coaching-leaderThe coach leader is a technical referent that cooperates with all the team. He take desicions together with all members. Using this method, you should share the knowledge and generate feedback constantly . Each step is explained and discussed with the workteam, empathy and enthusiasm and promoting the personal growth.

The risk of this is the聽low productivity because the under聽control.


The director

director-leaderWorking of this mode聽the leader shows the way, directs the activities and monitors all process but doesn’t participating directly. Supports all their trust in your team. This is useful in teams with high degree of motivation and compromise. In short: direct and delegate.

The great disadvantage of this is that team feel that their leader is not actively part of the team and no commitment as equals.

You must combine this ways, depending of the circumstances. Anyway, be honest, listen of your team, delegate and respect regardless of the technique used, is the most important… for me 馃檪


Before starting a new application for Start Up projects

Many times is thought that when starting a new start up project, we must be quick in gather the requirements, quick in development process, quick in test process… etc. We must devote specially attention and time to the requirement process. This step is the more important, and this step is decisive for the success or failure of the project.

I thought some fast tips for starting a new start up project:

  • Gather information about the customer company:
    • Objectives, services, products. Is a USP? (Unique Selling Proposition).
    • Competitors.
    • Define the targeted audience for the new application (age, social sector, etc).
  • Access to the application (devices, resolutions, etc)
  • What likes/dislikes of the other applications.
  • Define the limit for the plan project: final date, resources

checking list start up

This few points seem fast, but it is a round trip with the customer of many meetings before starting the new project. In each meeting the customer will define new features and flows, and the original idea will mutate.
Mutate a started application can be very difficult, or not viable, for that reason define this points before of start is the best way of avoid the failure.

Define first… take five聽馃檪


Documenting start up projects

In software engineering聽become independent the聽people of the processes is not an easy task. Even more in 聽start up聽projects.聽We can know some methods and practices that we are likely to lead to success,聽but we are never entirely sure and that’s because every project and every workteam is a world in itself.聽However, we can always limit to the maximum the errors and failures following simple practices and processes that will help us not to trip over the same stones.

Why document?

One of the advantages of having trained leaders in the workteams聽is that we can count on your experience.聽They will remember cases and situations that led to the triumph of their teams聽and recognize those practices that led to fail. One of the problems is that in the development market and start up solutions, the workteams聽are disassembled and technologies and processes become obsolete quickly.road to success documenting
When a challenge arises or聽a new project appears, the聽first thing we do is look for documentation about it.聽Seems that there is always someone who has taken the trouble to share and document information.聽We have to document in detail our successes and to apply it despite the time, techonologies and workteams.聽We analyze and write what led us to a happy ending, or failure to learn from it.聽But also for others who continue to the project,聽or who entering the team to have everything needed to adapt and continue working -which means cost savings when it comes to bring in a new member-.聽It’s very common to see people coming and going every day in the聽development companies,聽and is more common to see companies lose the control of their projects by this constant employees flow.

When making decisions in a team,聽forms of work are chosen or聽agreements are made,聽is important to write and document a methodical way.聽All agreed and discussed at each meeting must be captured to take it as reference聽and guide for our daily work.聽Is very easy that the words are carried by the wind, and the responsible persons are hidden behind this fact.聽When the agreement is documented聽we have a record and evidence that聽sometimes it helps to keep the wheels on the road.
This documentation of agreements and meetings is also valid for customers, they also must be able to refer to everything discussed and agreed in an easy way and anytime.

How to document start up projects?

document shared start upThe customers want efficient and simple products, but mainly聽they want it fast and at low cost. Document takes time,聽therefore increases directly on the cost of the final product.聽Find the balance between a relatively detailed documentation and the time available to apply聽is one of the challenges of development of agile applications companies.

There are many methodologies to implement at low cost聽but in any case it requires a number of practices in the development process聽and a series of complaints from developers too :).聽In any case you will need:

  • An initial documentation to clarify the proccesses of documentation of projects.
  • A control process that ensures that all member of the teams follow the documentation process.
  • A quick and easy way to write processes, meetings, agreements, technologies used, way to application and activities taking place.
  • A tool easy to learn and does not require lot time of聽maintenance.

This is how a policy of documentation in your workteam聽will allow you the projects become independent to the people,聽learn from your mistakes and repeat your success.

Now, as always for closing I leave a new auditory adventure 馃檪


Organization of start up developer apps

Articulate a developer workteam is not should a easy task. Again… in the start up projects all is fast and should be practice for get the final product to customer quickly.

First, we need choose a methodology for organize the work. All the team should know in details all process of work. The way most choosed usually is the Scrum. Why scrum? because es very easy of apply聽even the dumbest person can work with scrum methodology and not needed many roles. An聽simplified way of Scrum should be have:

  • A Product Manager: He has contact with the customer. Manage the available resources. Document their needs and guide to the workteam to the final product.
  • A Project Manager: Define the scope of the each iteration. Defines the roles and controls the process are complies聽as: documentation, responsabilities, delivery times, etc.
  • Testers: He test the quality of each element of the system. Defines the standard and the process of quality. He controls that each part complies with聽the correct programming methodologies.
  • Developer team: Generally, all does this. The mentioned roles, they haven’t much time for programming, but usually participate in the developer process.


meeting-start-upA system of comunication is essential. Forums, internal messages system (chat), tracker system (fundamental) and a series of regular meetings. The meetings of team is particulary important, this allow to the all team analyzes, shares, talk about the problems or detours and take some decisions together. 聽Any member of the team should can request a meeting for talk about contingences, new ideas or new challenges.


motivation-start-upThe motivation is the heart of the team. Many enterprises leaving aside this aspect, instead apply more control systems focusing the motivation in the member with the highest roles. But the point is that all the team must be motivated, with energy and especially聽considering what the customer wants.

This point has become the most sensitive for some聽development companies. They are dedicating considerable time and resources for obtain motivated teams. Is very common see games rooms,聽training events, special benefits,聽extensive聽and comfortable places of work with high technology in the development companies.

Personally, I think like any worker -in a ideal world- each member of the team must have a competitive salary, be heard聽and love what do.

For you… 芦First Circle禄


Estimation for start up projects

In the market of the development of applications for start up business, the estimation of the projects is one of the most crucial tasks. It depends largely the success or failure of all the project. Detours, delays, incidentals and other external factors affect the development time and in the start up world there is not time for a complete planification of project.
However, it’s our duty devote time and effort required for find a way of standardize the estimation process. Why standardize? for reduce the effort whenever a new customer appears. The standardization processes allows invest the effort once.

There are many techniques for the estimation. But, I have some shortcuts for start up projects that usually consider:

  • Define some available resources:
    • Size of workteam.
    • Capacity of the members of team -each member of the team should have a different weighting of the time effort-. For this reason we have take a standard time unit, and weighting each member according to their abilities, e.g. 1 hour for Technical Leader = 1.4 hours for SSr. developer.
    • Available technology.
  • Divide the project in small tasks, as small as possible.
  • Add 5% for testing tasks. Each part must be tested and revised.
  • Add 2% for documentation of the most important elements.
  • Add 5% for planification and organization of the workteam (meetings, analysis of the system flow, etc).
  • Add 10% for contingency and possibles delays.

Once we have define this, we create a small guide for follow each time we have to estimate.

And now… Fabiana Cantilo