[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?

Tags: , , ,

This entry was posted on Wednesday, January 26th, 2011 at 5:24 pm and is filed under English. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.

  • Anonymous

    Thanks!

    Very interesting. I think in our team, we could try these practices.

  • http://mediumexposure.com hakunin

    It’s responsIbility, not responsAbility.

  • http://twitter.com/mauriciojr Maurício Linhares

    It’s def important to have autonomy but it can’t become a “one man solution”. Once issues arise the person that has autonomy to make the decision should also be able to understand that it doesn’t mean he has to make all decisions by himself.

    Being part of a team is great cos you can discuss and get different points of view about a problem and make a better decision once you have more information to do it. People should really avoid confusing “autonomy” with the “lone wolf syndrome”.

  • http://twitter.com/sryche Cainã Costa

    How can a company have problems when they have levitating bosses? :P

  • http://chuckjhardy.tumblr.com/ Chuck J Hardy

    Good to see how another creative company does business. Well done and have a good year

  • http://www.lamiscela.net Junio Vitorino

    Great post. I’d like ask something. In a brief stretch you cite some scrum lights. You’d say that Plataforma consider yourself as an agile company? What’s official agile approach are you using?

  • http://blog.plataformatec.com.br Marcelo Park

    Hi Junio, tks! We use different agile approaches depending on the project. But we are very comfortable running projects with Scrum and Kanban.

  • http://blog.plataformatec.com.br Marcelo Park

    Corrections made. Tks!

  • http://blog.plataformatec.com.br Marcelo Park

    Corrections made. Tks!