[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

We believe that (…)

1)… mastering our work IS our work

"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

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

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.

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

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?