Posts tagged "the plataforma way"

[as some of you might have noticed, I accidentally clicked on "Publish" on my draft version, here is the full version of the post. Sorry about that]

*Though this blog post was written for any audience, there is a chance that you’ll be more interested if  you are a startuper or running a knowledge workers based company.

A year ago I was writing about a few uncertainties that we faced while starting up Plataforma Tec and how we dealt with them. We know that we still have a lot to learn, but now that another 12 months have passed by we are feeling much more solid and confident about what we’re building.

As last year’s post, this will also be about sharing our thoughts and a few practices that have been helping us a lot in creating a company culture and leveraging our team into its best. I hope you enjoy and find them useful!

what a team! =D

what a team! =D

We believe that (…)

1)… mastering our work IS our work

better and better and better - steve jobs keynote

"better and better and better"

We constantly tell people and customers “hire us only if you need a well developed application” (for example: a web application that will provide a revenue stream or will constantly have new features). This is one of our main assets and our main differentiation in this price competitive industry. Frankly, this strategy has been working fine for us but in order to keep it running this way, we are constantly looking for mastering our work all the time. Otherwise, if we don’t, there will be a great chance of losing our competitive edge.

2)… responsibility comes along with autonomy

"with great power, comes great responsability" - uncle ben

"with great power, comes great responsibility"

In last year’s post we mentioned that we only hire professionals that we feel comfortable giving autonomy, but it’s important to remember that it must be used very carefully. So, although autonomy makes a great pair with the constant search for mastery, don’t forget to be very cautious when dealing with decisions that might have a great impact in your company. We usually handle this kind of situation with two simple practices:

  • we show our team, in a very explicitly way, the goals and guidelines that should de followed;
  • and we constantly gather the team to discuss important issues (see the item below).

3)… gathering  the team to discuss problems is a great way to find solutions

gather your team and discuss problems and solutions

gather your team and discuss problems and solutions

Once in a while we face situations that are a bit more risky or complicated to be solved by our selves alone. They can be technical or design problems, a project management issue or even a simple warm-up for a business meeting. For all this we usually gather two or three team mates to ask for their opinion and discuss about the options that we might have.

4)… projects managers shouldn’t delegate work or establish random deadlines. They should serve and protect the team from undesired noise.

to protect and serve

"to protect and serve"

In our company, projects managers, salesmen and organization leaders work together with developers and designers. We see it as a system that must work synchronized. Also, the actions of planning, estimating and taking decisions in a project  should be made by the whole team (and not only by the manager). We found out that serious problems might arise when this system is desynchronized or made only by one person.

In our opinion, the manager role is to assure that developers and designers have the proper atmosphere to do their best. And by ‘proper atmosphere’ we mean that they have to provide the right tools (hw and sw), proper workplace, avoid useless interruptions and support the team when they get stuck with something.

5)… establishing roles is good and we avoid hierarchy levels

do not create communications layers between team and managers and leaders

Some managers try to list and predict 100% of the problems that might happen in a project. Here at Plataforma Tec, we assume that it’s impossible to do so. Therefore the big deal is NOT about trying to predict and avoid 100% of the problems. The deal is to BE PREPARED TO REACT when a problem happens and trying to avoid the most obvious problems that could happen.

Ok, but what does it all have to do with Roles vs. Hierarchy?
Check this: if we are prepared to react to a problem, first we must DETECT the problem. Right?

So, that’s where hierarchy kicks in… there is a great chance that creating hierarchy levels will degrade the communication quality in you company. This is one of the reasons we avoid creating different levels here at Plataforma Tec. Instead, we prefer defining roles. Developers should develop, Managers should support, Salesmen should sell (but synced with the whole “system” mentioned in item “4″).

If you’re having trouble understanding the difference between Roles and Hierarchy, take a look at Scrum’s roles (as an example of definition of roles).

6)… business leaders must create the right policies to enable all the items above

new policy

policies should be discussed, not imposed

All these practices won’t be effective if the organizational leaders don’t believe and provide the right policies to really enable them. Important notice: be careful not to confuse policies from impositions.

Well, this is a list of a few things that we’ve been doing and they have worked fine for us. Also, these six practices will work a lot better if implemented together, since they leverage each other.

I guess that’s it and I hope they’ll be useful or inspiring to others. Also, don’t forget to comment what you think about this small list of practices… Do you think they’ll work in your company?

2009 se foi. Foram 10 meses muito agitados para nós. Aprendizado intenso, momentos de cansaço físico, desafios constantes e dúvidas sobre o futuro são fatores que estão presentes no nosso dia-a-dia.

Antes de iniciar as operações da Plataforma Tecnologia (fev/09), nos questionávamos duas perguntas que davam frio na barriga:

Como fazer uma empresa de serviços dar certo?!
Como sair da inércia e conquistar os primeiros clientes?!

Não sabíamos as respostas. Mas estávamos lá.
Cada um com suas habilidades e todos com um sentimento que se equilibrava entre arrogância e inocência. Sem motivos muito claros, nós simplesmente acreditávamos que poderia dar certo.  Então, por que não tentar?

Aqui estamos: tentando.

É difícil dizer se a Plataforma Tecnologia será bem sucedida ou não. Só o futuro dirá.

O que podemos dizer é que avançamos muito mais do que imaginávamos e acreditamos estar na direção certa.  Sabemos onde queremos chegar, mas há inúmeros caminhos para escolher. Uns melhores, outros piores.

Fato é que durante 2009 descobrimos algumas coisas que consideramos valiosas e queremos compartilhar nossa opinião.  Seguem abaixo.

  • Contrate pessoas cujo trabalho você confia (e vice-versa): se você precisa micro-gerenciar sua equipe, então algo está errado. Micro-gerenciar times de desenvolvimento de software é uma tentativa (ruim) de assegurar a qualidade durante o processo produtivo. É preciso entender que o processo em si não é tão importante. O importante é o resultado final. Dê autonomia a sua equipe. Parta do pressuposto que sua equipe é capaz de atingir os objetivos até que seja provado o contrário (e se o “contrário” ocorrer, há diversas ações que podem ser tomadas, mas isso rende assunto para um outro post inteiro).
  • A maioria dos clientes descrevem soluções ao invés de descrever as reais necessidades: é natural que isso ocorra. E ao invés de culpá-los por não saberem descrever corretamente as necessidades, ajude-os a esclarecer qual o problema a ser resolvido. Em seguida, construa com ele uma solução (software).
    Não se esqueça que é o seu cliente que tem o conhecimento sobre o segmento/negócio e uma boa solução será resultado de um trabalho conjunto. Se um cliente não se dispuser a trabalhar em conjunto para desenhar uma solução, então caia fora. Este projeto terá grandes chances de ter problemas.
  • 6 meses é muito tempo para empresas recém-nascidas e pequenas: É importante saber onde se quer chegar, mas nesta fase da empresa, não faz muito sentido realizar planejamentos com horizontes longos. Muita coisa muda e muito rápido.
    Descobrimos que vale a pena fazer planejamentos com maior freqüência e com horizontes mais curtos. É como se a cada 6 meses a empresa estivesse realizando um “release”. Faça “retrospectivas”, “release plannings”, “sprint plannings” relativos à empresa e priorize a execução do que trará mais valor durante os próximos 6 meses. A grande vantagem de uma empresa de pequeno porte é sua capacidade de responder à mudanças (agilidade). Aproveite-a!
  • Nunca haverá momento ideal para implementar algo: já nos pegamos dizendo “assim que der uma sossegada, a gente começa a re-estruturar bla-bla-bla”. A verdade é que este momento de sossego dificilmente chegará, ainda mais se a empresa estiver em crescimento. Se há necessidade em implementar ou mudar algo na empresa, faça-o o quanto antes (ou de acordo com a prioridade). Esperar só vai piorar os sintomas que este problema estiver causando. Quanto mais você esperar, pior será.
  • Saiba claramente qual o seu DNA: isso pode soar um pouco filosófico, e de fato é. Mas é algo que se mostrou muito importante para nós. Todo o time deve saber e compartilhar dos valores que moldam as decisões de negócio e refletem na maneira de operar o dia-a-dia da empresa. Pode ocorrer momentos em que fechar um novo contrato significará deixar o DNA de lado e isso será um pouco doloroso.
    Mas da nossa experiência, posso afirmar que valeu a pena não se desviar do DNA. Quando olhamos para trás, fica muito claro que tomamos boas decisões. Warren Buffet já dizia… “In the business world, the rear view mirror is always clearer than the windshield“.
    É a mais pura verdade!

Espero que estes tópicos possam ajudar startups e outras empresas iniciantes.

Gostaria de pedir que ajudem a enriquecer o post e comentem. Compartilhem suas experiências!