In my life, I’ve met very talented and committed people, full of energy and always delivering great results. Naturally, they had very different personalities, which didn’t affect their excelent performance and I actually believe that a great team must include different mindsets, as diversity will certainly lead to a more vibrant and open culture. However, if I could get all these people together in a room, separate the optimists from the pessimists, and then give both groups the task of creating a company, I strongly believe the pessimists just wouldn’t make it. The problem is that there’s tons of uncertainty but absolutely no time for careful analysis in the beginning of a company, so they become depressed really fast.  The very mindset that makes them deliver great results doesn’t work here – a startup can’t afford to plan minusciously, to test thoroughly or to fine-tune a certain component until it’s able to survive a cataclism. Most of all, a startup fails. A lot. And pessimists are very intolerant (almost allergic) to failure. I’ve seen pessimists who were working at bullet train speed coming to an halt after a single failure. It’s almost as the entire world had collapsed on that moment and they have to rebuild an entire nation.

On the other hand, to an optimist, failure is just a bump in the road. They just go around it and move on. Scott Halford writes:

“Optimists think that there are more options when bad things happen. So they try different things in order to get out of a jam. Serious pessimists usually give up once they think the outcome is foretold.”

All the stories about successful entrepreneurs are filled with optimism and bright visions of the future. Here’s a quote from Marc Randolph, founder of Netflix, found here:

“In my past life as an entrepreneur, this optimism was a critical tool.  I just always believed we would succeed.  Even when everyone else said my ideas were ridiculous. Even when we were almost out of money.  Even when the metrics were all upside down.  I always have confidence that I’ll figure something out.  I just have that confidence that things are going to work out fine.”

Back to the group of people in the room, when you hear some of them talking, they sound almost idealistic and naive. These are the optimists, who don’t remember that things fail, so they are much bolder on their plans. They are not satisfied for fixing a problem or making something work, and thank God for that because I’d rather have those type of tasks being done by pessimists. A serious pessimist fixes a problem for good because he remembers everything that can go wrong and prevents that from happening. Even so, he will finish the task saying that he cannot guarantee that it will work 100% of the time. So, pessimists are a perfect fit for developing rock-solid software, which is not what a startup should care about in the beginning.

So, if you’re starting something new, make sure everyone aboard is an optimist. At least in the beginning. Or you’ll risk having people who won’t miss a chance to tell you “I told you so” (this is the mark of a pessimist), when you should (you must!) have people telling: “Glad we tried that one, even though it didn’t work. Now let’s try this one”. Your team must not only see the glass half-full but they actually should be seeing the glass overflowing all the time! If it succeeds, and only when it shows strong signs that it will succeed, then it’s time to bring in the pessimists.

In computing and systems design a loosely coupled system is one where each of its components has, or makes use of, little or no knowledge of the definitions of other separate components.

The main advantage of these systems is that they are much easier to manage. For example:

• you can change the behavior of one component without breaking the whole system;
• you can replace a component without breaking the whole system;
• you can easily test a component because it’s isolated from the others

Recently, there has been a growing interest in asynchronous communication, like Message Queue or Publish/Subscribe systems, where the component that sends the request doesn’t block waiting for a response. Again, this is the “loose coupling” principle put in practice. There are some producers who produce messages and there are some consumers who consume messages. What makes it loosely coupled is that fact that producers don’t have a clue on who are the consumers and vice-versa. This makes it possible to build applications in completely parallel branches. You can have two independent teams who are completely oblivious of the existence of the other, one developing a producer and another developing a consumer. The application is worthless without these two pieces, but each one can function by itself.

The advantages of these systems are well understood and recognized by experienced software developers, but I wonder if the same principles wouldn’t apply to project management in general. One of the most difficult things to manage in a project is task dependencies. That’s where you’ll find the bottlenecks: some people have to stop their work because their tasks depend upon completion of another task. In other words, the tasks are as tightly coupled as they can get: they not only depend on other tasks, they have to know about the other tasks (at least, they have to know which tasks they depend upon and when those tasks finish).

What if you could manage the project in a completely loosely-coupled fashion? You would setup a simple rule: everyone in the team must be able to finish their tasks without depending on someone else. This means that when two tasks have a dependency between themselves, you have to mercilessly remove that dependency at all costs by:

• Trying to redesign the system so that it can work asynchronously or
• Simulating the output of the task you depend upon (in software development, this means using mocks or stubs)

If you fail to remove that dependency, then those two tasks must be done by the same person.

Now, I won’t lie to you: this comes at a price. Removing the dependencies will probably make the tasks longer, because you have to develop additional mechanisms, like simulating the output of other tasks. Assigning a sequence of tasks to the same person is also a risky move – that person may be doing a series of mistakes but since she doesn’t depend on anyone, you’ll only notice it later than in a typical project.

However, if you have a talented small team, it will work really well. It will be like watching several high-speed trains running in parallel, leaving a complete finished component from time to time. Maybe one of the trains is going faster than the others. It doesn’t matter. The project manager just keeps picking the finished components, until they can connect to each other (for example, until you have a producer and a consumer). It’s a great feeling. Try it.

She gave some examples of serendipity:

• Searching for something and finding something else
• Browsing randomly and stumbling upon interesting things
• Hearing someone talking about something apparently irrelevant that somehow turns into highly valuable information some years later (the post-it story)

I think everyone of us can relate to situations like those, specially in the dense social contexts that Internet provide us (twitter, facebook, …). However, most interesting is thinking on how we can encourage serendipity within enterprises, to improve collaboration and information sharing. Bringing social software to the enterprise (the so called enterprise 2.0) is a step towards serendipity – after all it seems to work on our personal lifes, why not in business? Also, as Ana referred in the presentation, designing physical spaces where co-workers can get together informally is another approach to this. These two techniques make sense because they provide a place (either virtual or real) for serendipity to happen. But I’m not sure this is enough.

For example, conferences are serendipitous places by nature because people go there with a predisposition to engage in social relations. Browsing the search results of a twitter hashtag also presupposes an openness to be surprised. But in a company, people can (and should) socialize but they are not there to socialize. They have clear tasks and goals which have nothing to do with searching or having a nice chat over the coffee machine.

Suppose you have to write a report about something and you work in a cool modern company, with an internal wiki, blogs, a micro-blogging app like yammer, etc. You could search for people or information related to that report before actually starting the task, but in most cases you won’t. First, you think you will able to do the task by yourself (after all, that’s why you are being paid, right?). Only if it goes wrong or you run into an obstacle, you will consider asking for help. Except for the fact that you may not know if it’s going wrong or not…And don’t forget that searching for the right person/data may require a lot of effort. Effort that you should be directing to complete the task.

Here’s an example from my daily work. I lead software development teams, and one of my tasks is to walk around trying to spot problems that (younger) developers may be missing. Sometimes, some of them start talking loud about something and I overhear the conversation. And once in while, some sentences catch my attention and I enter the discussion. This is serendipity in its most pure form. My colleagues are not searching nor socializing, they are just trying to fulfill their tasks the best they can. And I can help them, but neither of us know when or how. The current crop of social software doesn’t work in these cases. Unless you narrate everything you do in some micro-blogging tool (requiring lots of effort and stealing time from actually doing your job) you are out of luck.

I strongly believe serendipity is a highly relevant topic for effective enterprise collaboration (and will become even more so in the years to come) but current social enterprise tools are not there yet, because they provide a kind of parallel-to-work serendipity. The great challenge will be to provide a seamless integration between work and serendipity, the “overhearing” effect you can feel in a open-space, and the reason why war rooms work so well…If that’s not magic, I don’t know what it is…

You can see Ana’s full presentation here.

They are what the famous marketing guru Seth Godin called Linchpins, in his last book:

(…) people who bring art to work, people who reach out, make a connection, cause change to happen. The linchpin is the person who is indispensable, because they refuse to become an interchangeable part, someone who merely follows the manual.

From http://gapingvoid.com/2010/01/21/linchpin-ten-questions-for-seth-godin/

And they are what knowledge-intensive companies hope to recruit and retain, because they’re the ones that keep the machine working and reinventing itself, that make remarkable things happen.

What I find ironic is that these same companies who aggressively seek for this kind of employees don’t realize that if the number of linchpins grows above a certain level, they will be in trouble. Fortunately for them, these people are rare. And while they are keeping a “healthy” ratio between linchpins and non-linchpins(which Seth calls cogs), say 1 linchpin for every 5 employees, they (company) are pretty safe.

I’ll tell you why in a moment but first I’ll have to explain a few things about these crazy guys. You see, linchpins will not abide by the company rules if they feel that they are in the way to achieve their goals but that’s ok because the result is usually so good that it largely compensates that misbehavior. For example, companies don’t usually let their employees stay home when they feel like it. Even if they do, they create a rule that (1) puts an upper limit for  the number of days they are allowed to do that and (2) catalogs the possible reasons for doing so. They do that to prevent abuse and I understand that – I firmly believe that most people would actually abuse thus leading the company to serious problems. Nevertheless, a linchpin will promptly ignore that rule, disappearing from the company for a few days only to come over with a lot of things done. Maybe he was being interrupted all the time and needed to focus on something. Maybe the office was too hot and he preferred to work outside. I don’t know. The fact is – he has work done, with great quality, so no one will bother him for breaking the rules.

Another interesting thing is that linchpins don’t respond that well to the typical incentives, such as career progression, collecting titles or having the opportunity to go to “important” meetings. They just don’t fit on the common career path and will create their own path. As long as the company allows them to pursue their path they will stick around and both will benefit immensely from that. If the company forces them to follow the instituted path, they will ignore them at first, but if the company persists than they have no option but to leave. Most important, they don’t need any incentive because they are self-motivated. They take immense pleasure from the work they do everyday, so all they want is to let them continue doing their work.

By now, you might have guessed the problem of companies that only have linchpins. The rules will no longer work because they will not serve their purpose anymore. Their purpose is to, somehow, determine and standardize behavior across the company. You can’t standardize a linchpin, so their purpose is gone. If the rules are gone, those people who are in charge of guaranteeing that people follow the rules are also gone. For example, there’s no need for someone to control that the team delivers the product in time. A team of linchpins will probably deliver it ahead of time anyway. The whole hierarchical structure will start to fall apart. The need for the company own existence starts being questioned.

This may sound apocalyptic but you have to understand that I’m imagining an extreme scenario where a company is only made of linchpins. Usually, a company starts with only linchpins (the founders) but soon will start recruiting cogs. Afterwards, it starts creating rules for those cogs. That’s the most common path, by far. Those are all the cases that I know of, and many are being successful. But, what if it continued to recruit only linchpins? How big could it grow before starting to fall apart?

“I look for two things that are paramount above all:

1. Great team. It’s obvious. It’s a tautology. Everybody says it. You have to be working with some of the best people in the industry you’re in.
2. Huge market. Niche markets just don’t work because the first idea never works. You always have to change the idea, so you need room to maneuver in a big market.

“There are three more factors that I look at. Not all three of them are required but I prefer a company to have at least two of them:

1. Difficult technology that is compounding over time.
2. A proprietary distribution channel. A clever viral marketing, or SEO, or partnership, or whatever strategy that gives them a leg up over competitors.
3. A direct monetization model. Something more than throwing up 10 cent banner ad CPMs.

In this era of feature-less applications supported by ads or other indirect business models, it’s refreshing to see factors like “difficult technology” or “direct monetization model” come up on this list. I still don’t get those applications that anyone can replicate in a weekend in PHP and for which is impossible to understand the business model (e.g., don’t have a “pricing” or “buy” link in their home page).

But what I really wanted to write about is his first point. I’m always telling this to my colleagues and friends, but I realized I had never written it clearly in this blog, so here it goes:

To create a great product you mostly need a great team.

From my experience, people give credit to a lot of irrelevant stuff around the project, instead of recognizing that, besides the team, the rest are mainly “distractions”.  Managers who happen to be fortunate enough to manage great teams are sometimes led to believe that a certain “cool” managerial style (e.g. card sorting prioritizing meetings, getting the whole team out for the cinema, etc.) is responsible for their successes. It is not. It doesn’t matter. Switch your management techniques at will, because the team will probably continue to deliver great results. When those managers are given a different team (not as good as the previous one), they try to use the same techniques but the outcome is not the same.

The canonical example of this phenomenon is the C3 project, the project that gave birth to the famous XP methodology. The project was running late on schedule so they brought in Kent Beck, Ron Jeffries and a few others who were able to ressurect the project and deliver it (nearly) on time. Many people attributed the sucess of the project to its revolutionary methodology (XP) but didn’t realize that the team behind it was comprised of programming top stars, who would do a great job no matter what. In fact, many subsequent XP-style projects have proven that this methodology works best in small teams with highly competent and experienced programmers. No kidding, hein?

I’m sure that this makes sense to most of you, but think about how much time you devote to getting a great team (recruitement) versus all the other things (managing a team, planning, experimenting new tools, etc.). I did, and I’ve been changing my priorities, since then.

We usually talk about bandwidth while we’re downloading a movie from the Internet or playing an online game. But what’s the actual required bandwidth for efficient communication between an human and a computer?

I think the presentation went well. Some of my colleagues told me they had never thought about bandwidth on that perspective, which was exactly my goal. The event was packed with great presentations – they were recorded and will probably be available in the upcoming weeks. In the meanwhile, I uploaded my presentation to slideshare. Hope you like it.

For RSS viewers, see the presentation here.

The above story may state the obvious but for us, software engineers, it is (sadly) not that obvious. Since the dawn of computation, we are always trying to pack different little things into one common meta-thing that will make irrelevant which little thing you are indeed using. In fact, these abstractions are the fabric of most modern software applications: we have abstractions for databases so that we don’t have to mix SQL with our programming language, we have abstractions for xml parsers, so that we can easily switch the underlying engine, same for logging, and so on.

The canonical example is trying to abstract away the communication channel. On object oriented communication protocols (e.g. CORBA, RMI), there’s this myth that you can interact with an object independently of its location – you always treat the object as local. This has proven many times to be flawed – if the connection with the remote server drops or takes too long, the “local object” metaphor starts to break. Also, the idea of building a protocol that can run seamlessly on top of HTTP and  SMTP is just that. An idea. Or an academic paper. In the real world, you don’t try to create a synchronous protocol over an asynchronous channel.

This leads me to the new Facebook messages, that will unify into a single seamless interface four communications channels: e-mail, SMS, IM and Facebook messages. From the official announcement:

Today I’m excited to announce the next evolution of Messages. You decide how you want to talk to your friends: via SMS, chat, email or Messages. They will receive your message through whatever medium or device is convenient for them, and you can both have a conversation in real time.  You shouldn’t have to remember who prefers IM over email or worry about which technology to use.  Simply choose their name and type a message.

Oh man, the “let’s hide that pesky communication channel” virus that plagued the programmers’ lives for so many years is being now transported to the end users. You see, when you try to combine different dimensions, you have no choice but finding the few features that are common among all dimensions, and leave out the rest. Guess what? The users won’t be happy. Consider the typical features (and behavior) of IM as compared to e-mail? When you write a message to someone using IM, you expect to see a response in a matter of seconds. On the other hand, when you use e-mail, you tolerate a much bigger delay – a few hours lag is common in e-mail exchange. And let’s not forget the size of the message. It would be absurd to chop into dozens of SMS a long multiple pages messages that was originally meant to be sent through e-mail. But I guess it’s an interesting geeky challenge, and that’s why it has been tried over and over. And since Facebook is probably dominated by geeks, they couldn’t refrain themselves of giving it a shot.

So, why do I feel like a complete moron when I meet with fellow programmers that are eager to tell me the latest breakthrough in software development? Every metting I’m introduced to a new technique: Pair programming, Test Driven Development, Scrum Meetings, User Stories, Product Backlog, etc. and they are all described as revolutions. Most of them fiercely believe that, by using one of those techniques, they will produce better software in less time. And I won’t refute that, these are valid techniques. My problem starts with statements like this, which come up quite frequently in these reunions:

In our team, since we tried Pair Programming, we never looked back. We now use it everyday.

I don’t know about you, but this sounds quite dogmatic to me. Isn’t agile a cooler way of saying flexible? If you use something everyday and defend that thing almost religiously, how flexible are you?

But still, that’s not the reason why I feel like a moron. Because I know what Pair Programming means and, forgive me for the extreme simplicity, it is nothing more than an extreme form of code reviewing¹. What pisses me off is when someone tells me of a technique that I have never heard before, describing it as a new way of doing something. And I get enthusiastic with the idea, and then they explain the idea (or I google it in the background while pretending to be an expert in the subject), and then, after removing all the marketoid inspiring buzzwordy content, what remains is just a basic common knowledge principle that exists for more than twenty years…

Take Kanban, for example, one of the new kids in the block. Kanban was invented by Toyota to support their production system and was translated to software project management as a technique to avoid overallocation and underallocation. This is usually implemented in a board, as explained here:

On the board, engineering tasks are represented by cards (Post-It Notes), and the statuses are indicated by posting them to separate areas on the board labeled “ToDo”, “Doing”, and “Done” (Label names often differ from site to site, examples are “In Progress”, “Tested”, “Accepted”, “Blocking” etc.). This Kanban Board helps visually signal tasks and limit WIP (tasks actively being worked on). But no “processes” (upstream or downstream) are found here, and a new concept of “iteration” appears. For each iteration, tasks are newly identified by breaking down user stories into tasks and it is these tasks that are posted onto the ToDo area.

So, what exactly is new here? Isn’t this how all issue trackers were supposed to work? An issue is created (ToDo), afterwords it is assigned to someone who starts working on it (Doing) and finally is resolved (Done). I guess the shared board hanging in the wall can be cool but isn’t that just a fancy frontend to a basic, boring, issue tracking system? It is so obvious that there already plugins for issue trackers that do exactly that.

This article is not meant to ditch Kanban, it is just an example. And these techniques are important! However, they are important not because of the specific technique per se, but because of the underlying principles like early feedback, small iterations, team communication or process automation. I know it is sexier to say “we use 2 week sprints” as opposed to “we use small iterations” but it is the same f* thing!²

In the end, I have come to realize that I use every one of these cool techniques, all mixed up, since before they were invented. And I bet you do too.

1. It is extreme because all the code is reviewed, and because it is reviewed at the same time it is being written.
2. Actually, the duration of the sprints/iterations is another nonsense religious discussion – 2 weeks, 3 weeks, who cares?

1 – Empresas que geram muitos lucros

Quais são as empresas que geraram mais lucros o ano passado (por exemplo, ranking na área de TI)? Arrisco-me a dizer que existe uma correlação forte entre essas empresas e as melhores empresas para trabalhar, pois (pelo menos em TI) para gerar mais lucros que a concorrência tem que se ter uma equipa melhor. E se temos uma equipa melhor é porque a empresa é, muito provavelmente, melhor para trabalhar.

2 – Empresas com turnover baixo

Isto é, se uma empresa é a melhor para se trabalhar, então porque haveria alguém de querer sair? Note-se, que tirando startups com meia dúzia de empregados, é idealista pensar que se obtém um turnover de 0% (ou seja, ninguém sai). Existem muitas vezes razões exógenas à empresa (por exemplo, mudança de residência) que levam uma pessoa a sair. Isso é inevitável e não há nada a fazer. Mas existem muitas empresas conceituadas na praça com um turnover elevadíssimo, e certamente que não serão todas por razões exógenas à empresa. Porque será?

Referi também que um dos problemas da minha estratégia é que era impossível saber o turnover de uma empresa, pois essa informação não é pública. Bem, isso mudou. Recentemente o linkedin introduziu uma catrefada de estatísticas giras sobre as empresas incluindo:

• Crescimento da empresa (em número de empregados) no último ano, comparativamente a empresas similares (mesma indústria e tamanho similar);
• Percentagem de empregados que mudaram de título no último, comparativamente a empresas similares;
• Média de anos de experiência dos seus empregados;
• etc.

Por isso, reiterando o que disse anteriormente a quem procura emprego, sugiro que consultem os lucros obtidos pela empresa nos últimos anos assim como o respectivo perfil da empresa no linkedin.

Only allow stars (outstanding employees) to remain in the company, others get a nice severance package. As they say: “We’re like a pro sports team, not a kid’s recreational team“. Stars get more done and cost less than 2 adequate employees. Since they have only stars, there is no need for variable remuneration based on yearly performance reviews (e.g., bonuses) – just give everyone top of the market salary and/or stock options.

Usually, companies have three growth options:

• Stay creative by staying small
• Try to avoid rules as you grow, suffer chaos
• Use process as you grow to drive efficient execution, but cripple creativity, flexibility and ability to thrive when market shifts

Having worked in big companies and been watching a startup grow from 5 to more than 60 employees, I can say that is almost impossible not to fall into the third option, sooner or later.

But Netflix introduces a fourth option:

• Avoid chaos as you grow with ever more high performance people – not with rules. Then you can continue to run informally with self-discipline and avoid chaos.

This is very ambitious and it can only work if you choose very carefully who joins the company. They have to be stars, but they also have to be great colleagues with the highest sense of responsibility (as they say, people who “pick up the trash lying in the floor“). Given Netflix’s success, this is probably working for them.