BBVA API Market
During my time here at Karumi, I have worked with and helped a lot of startups and major companies. Sometimes this was at the technological level, helping them improve their software, whilst on other occasions it was helping them improve their organization.
We often believe that a company’s big problem is technological when really it is organizational: tech companies are based on people, and they are the core of the business. It is not enough to know how to scale up our code base or our Amazon instances, or how our database will perform when we have 5 million users. We also need to be ready to grow our teams, and we need to know how to carry on succeeding when we walk through the door and don’t even know the names of half of the people with whom we are supposed to be working.
We have been through these situations many times in Karumi with many companies. In this article, I set out the major problems we have found and offer some of the advice we have given.
With a startup, the idea is to get the product onto the market as quickly as possible. You work every hour you can, sacrifice your income and squash years of your life into months to try to get the idea from out of your head and in front of your customers as soon as possible. But, this stops working as the company grows: it is difficult to get someone working for a salary to put everything they have into a product that isn’t theirs, or that they don’t feel ownership of.
The most common solution is to give the company’s initial workers a share in the company so that they feel it belongs to them. This can work at the beginning, but the balance between the percentage stake in the company and commitment is usually difficult to measure.
I believe the best approach is to listen to your workers, hear what they have to say and always keep them in mind. If people are happy in what they are doing, and if the ideas are theirs, they will be more involved: this will help you to build the team and makes it easier to integrate new members.
Another issue inherent to startups is working hours and ‘crunch’ periods. When there are just two of you in the team, your objective is clear: you have to get out there and make money. But as the team grows, you have to appreciate that people have a life outside work. In order to avoid your workers burning out, the best approach is to be clear about both the company’s objectives and the personal objectives of every member of the team: there should never be any doubts about these. Communication should be clear and concise, and always honest.
Telling a team that they need to work the weekend or 14 hours a day for a week because you have a contract to fulfill, or you have to get a new version out for a particular campaign, is easy for everyone to understand, and nobody will mind putting in extra effort. To complement this, try to reward this extra effort, not just in cash through a bonus, but with days off after the crunch, dinner or a trip, even if these seem like small and insignificant gestures.
Crunch periods must always be justified and not just the whim of the boss, or because you want something to be ready now: if there is one lesson that needs to be learnt, it is that software takes its time. And always say thank you.
Finally, everyone needs to have a clear short, medium and long-term vision of the company, even if this vision may evolve over the medium and longer term. When companies are growing, new entrants often have no idea where the company is heading, and working on day-to-day tasks overwhelms the long-term vision. And if a company changes its objectives every week, and everything is important and urgent, the team will become demotivated and will break up.
A company consists of its professionals, and it is hard to find good workers: if someone is unhappy, they will leave. We have to try to stop people getting into this situation.
One of the problems of growing teams is that we have to start creating organizational structures and appointing people to lead them. The main problem is that the founders are often given roles such as the CTO, CEO or Head of Design without having the least idea about what such a role involves.
One of the things I recommend to a lot of companies is that they should change their CTO or CEO because they are not ready for the step up from being a startup. This doesn’t necessarily mean they should leave the company: but they should be ready to move aside and do the work they are good at, which is what has got the company this far.
Another problem is that we often believe that great engineers are going to be great managers, and we have the idea that you have to manage people if you want to earn more. We have to deploy workers efficiently, putting people in management positions who have the right skills for this and who enjoy the role, keeping technicians in posts where they have the most to offer. If you find a good engineer, try to hang on to them, because these skills are rare and it will be difficult to fill their post. And don’t promote them up the hierarchy: they will be much more useful helping the other technicians from their current level. This means that good engineers might earn more than the bosses: this shouldn’t be a surprise, as these people have a valuable contribution to make.
A good leader should do two things well: listen and lead by example. A good leader should listen to everything, because the best ideas come from the simplest questions, and because new arrivals offer a fresh perspective before they have absorbed the company culture. And leaders should lead by example: never ask your team to do something you wouldn’t do. If there is a period with more work, stay with your team and give them a hand, so they feel you are on their side.
From the outset, it is important to establish a range of tools and rules for everyone, even if you are on your own initially, you can always change them in the future.
Common rules for technology should be established for everyone to follow. I believe the most important to be, and always recommend: put in place a work system with version controls and a system of code reviews, and establish a coding style guide. I consider these three aspects to be essential, and always introduce them into the teams I work with, if they don’t exist already.
In a company, everyone must use version control and apply it in the same way. I am not going to get into whether you should use a functionality branching model or gitflow, or which technology is best, as I would recommend Perforce for videogames and Git for applications: the important thing is that everyone works in the same way.
Our commits must be small and descriptive. This will help us if we have to resolve a conflict or if we have to go back through the repository log to see why a change was made or understand why an error occurred. A version control is not just a shared folder on Dropbox, it’s time we stopped using it like one, it is time to stop uploading loads of change with a description saying “preparing release“.
Code reviews help knowledge flow throughout the team, achieving a consistent coding style. The idea is that at least a couple of our colleagues should comment on our code before it is uploaded to our project, so as to spot any errors, improvements or style faults. This also means that several people will have at least some idea of how this piece of software works, as they have spent some time examining it. This allows people to learn from each other, with the more senior members explaining errors to junior team members, helping to improve their skills.
Code reviews should focus on the code, not on who wrote it. Reviews should be cordial and written from the viewpoint of a beginner, remembering that we all make mistakes and continue to do so. I would recommend highlighting aspects that are particularly good and praising the work of your colleagues.
Finally, and no less importantly, we should define a common language, both in the strictest sense of how we write our software – how we name the classes, methods, tabulation, etc. – and the semantic aspect of the software – what we call things, so that a “user” is always a “user”, and we don’t call them a “client” or an “account” in other places, when we are referring to the same thing.
Syntax helps us to combine code from different writers and to read their code. This can be automated in most languages, and it is a good idea to define terms down to the level of how the artists call the assets and how tasks and bugs are defined.
I recommend you take the time to write a glossary for all the platforms and people involved: even product staff should know that what we are talking about is a “user”, not a “purchaser”. Sharing standard vocabulary fosters communication and makes it easier to move between teams.
And if this is all set out in writing in an employee manual, it will help new people join the team and get used to this way of working, whilst code reviews will help guide them in the right direction.
Automating everything that takes time that is not a central part of the business is one of the main tasks a company should undertake as it grows. I see a lot of companies using their engineers’ time to set up versions to demo to customers, preparing a release or taking grabs of an app for the market. This is a waste of time.
All of these are easy to automate and most won’t take more than a day’s work, whilst saving us a lot of time in the long run and eliminating human errors: we have all put an app into production with the debug activated or aimed at the wrong environment.
A very common mistake is for the engineers who create the applications to have the passwords for them. This doesn’t work as your company grows: the worker could fall out with the company, for whatever reason, and do you a lot of damage, or a laptop might be misplaced, compromising the security of your product. Just as you wouldn’t give the keys to your house to the first person you meet, even if they seem like a nice person, you have to be careful about who you give the keys to your application.
We shouldn’t let our day-to-day work stop us improving our development processes, as this can save us a lot of time and problems.
Can you imagine a chef who doesn’t taste their own food? This is exactly what happens in the software world. Programmers don’t try their own food: they make it, check that it looks like a plate of food and give it to the customer, not worrying about whether it is any good or not. I see this problem in most of the companies I visit: many don’t seem concerned about whether their food is any good or not. Some even see testing their food as a waste of time, and automating this process even more so.
Many companies contract people to taste their food before it is served. But it sounds strange to me that a kitchen should have a chef and someone to taste the food: but that is what we do, we call it a QA. I feel it is a waste of time to have people testing applications, particularly when they could be helping to get things done and to develop functionality. We should all be responsible for ensuring that our software works correctly; we shouldn’t be delegating this to others.
When faced with this, I always demonstrate empirically that it is quicker to automate testing than to test everything manually. The big problem is that many people have never carried out a test and are afraid of doing so: there is something almost masochistic about demonstrating to yourself that the software you have written is poor. But what I always see is that, once people start writing tests, they never stop: tests provide a safety net that demonstrates that what you have done is good, giving you peace of mind about your work and helping resolve problems in the software. You write tests for yourself, not for anyone else. They are a way of knowing that what you have done works, and that you are not destroying the work of your colleagues.
Knowing what to test and what not to test is another problem. It is important to cover the things that are crucial for the business or the functionality being developed, relying on the opinions of people on the product side to find out what is important for them: they should be the ones setting the agenda for what we cover.
Technicians must also be able to discover which piece of software is most sensitive, to ensure it is tested properly and we know whether it needs modifying. But there is no need to become paranoid about testing. And while it is important that we establish the testing scope correctly, there is no magic formula for this: time and experience are the only guides.
Another major problem I have found is that companies give more importance to processes rather than what they are used for. When a company starts to introduce agile methodologies into its teams, it tries to impose them or apply them directly without understanding or assessing what they contribute to the development cycle. Instigating a scrum or kanban will not solve your organization’s problems on its own: but, if used well, it will offer tools that can improve your workflow. Using a scrum doesn’t work when it is more important in a team to attend a retrospective than a planning meeting, or when standups are just meetings where I have to tell my story and I don’t get to hear what the others have to say.
As teams grow, there is no room for cowboy developers who are fighting their own battles. Working methodologies obviously have to be established, but these must come from the teams. We have to talk to them and find out about their problems and how to solve them. It is pointless to try to force a team to unwillingly follow a set of rules that they are going to try to get round: they are going to use the methodologies and they need to be happy with them.
Converting between Agile and Waterfall is another problem. Many companies say they use Agile methodologies, but in reality, all of the tasks are of equal priority, there are no iterations, the work flow is not updated, and the project triangle – reviewing resources, time and functionality – is static. These companies have to learn to prioritize and to say “no”; they need to know how to postpone decisions; and to be able to do more with less.
What I am trying to say is that growing is not easy. Some people will be left behind, and others will come on board, full of enthusiasm. The key is to work as a team, being comfortable in what you are doing and proud of your work. Remember you are working with people, and they are one of the most important assets for your company.
Photo | Flickr
By Jorge J. Barroso:
Jorge J. Barroso is an Android expert at Karumi, a development studio that prioritizes quality and working closely with customers. He worked for Tuenti from 2009 to 2013, rising to be the tech lead for the Android Core team. He has worked on many of the company’s mobile projects, such as j2me, Blackberry and Android. Prior to joining Tuenti, he worked for various companies developing games for mobile devices and multi-player games. He has been Android’s Google Developer Expert since February.
Follow us on @BBVAAPIMarket
In a connected world, APIs are the glue that keeps all the parts that form our day-to-day lives in place. The same way the power of glue depends on the material it is used on and the knowledge of its properties, APIs are only as useful as their documentation allows for.
Want to know the key elements of a successful startup? Focus on being the best in one (and only one) product or service; avoid cheap customers; define a philosophy, and defend it; convince customers to work with LEAN; and promote a happy working ecosystem.
There are different solutions to monitor the performance of an API, in terms of traffic, quality and speed of the answers it provides. Detecting faults in the code or quantifying the generated revenues are also some of the options offered by these useful tools.
