April 2009 Archives

Acid Test #3:The Problem Solver Test.

By Paulo Rosado on April 25, 2009 2:15 PM | No Comments | No TrackBacks

Can he think out-of-the-box to come up with solutions for emerging problems?
Can he harness the power of the team to solve these problems?

The out of the box thinking that comes with finding a pragmatic, simple solution to a problem is a difficult skill and one that a lot of good managers have not really mastered. What I have seen that works is people who can harness the ideas of the people around them and have the capacity to spot a good solution when they see one.

What does not work is a person who cannot recognize a good solution. Some managers can pull off relying on their team members to spot and solve problems with minimal intervention. But this is usually a receipt for disaster. There are always situations when a manager needs to dig deeper and challenge a particular solution brought up by a team member because the solution will have an impact on some other area that the report is not aware. So, again, even if managers are not good at out of the box thinking they need to evolve in order to develop an intuition that allows them to accept or challenge a solution coming from someone else.

Be aware also that there are managers that in spite being good at solving problems have issues when executing; let's just say "they don't get the job done". This is a problem that most of the times has to do with lack of experience or too much "strategic thinking" but can be due to other factors, usually detectable through these tests.

OutSystems: 5 steps towards building a customer focused culture

By Paulo Rosado on April 23, 2009 12:42 PM | No Comments | No TrackBacks

"It is difficult to hear a bad word about the Portuguese software company" starts the dutch publication Computable article on describing the general feedback of customers at the OutSystems NextStep event (check out a _bad_ English translation of the article).

This is common feedback for OutSystems. The product is very stable resulting from our R&D focus on quality. The few times we have critical issues the Support Team bends itself backwards to address and solve them. The Professional Services team regularly gets bottles of wine and chocolate cakes for their focus on delivering, on time, on budget, solutions that are adopted fast by the business.

Last year, one of our US prospects (now a happy customer) laid out a very particular set of needs and asked us to provide a reference call with an existing customer in a similar situation. After the reference call, they told us: "You know, this reference had very few bad things to say about you guys. That was not very helpful. We wanted to know how you handle problems because we understand we have some different needs. But finally they reported a situation where they had to use your support and the whole response, in their opinion, 'was top of the line'."

So, regularly I am asked on

"How do you do it? How do you establish an excellency culture that permeates all customer touching units?"

There are many things you can do. A lot is just common sense. However, if I had to summarize I believe the following 5 directions make the most difference at OutSystems:

Put the customer above everything. This means customer satisfaction is above profits, revenues and even employee satisfaction. KPIs, Bonus, etc need to make this direction clear. Management behavior needs to make this clear.
Temper customer satisfaction with fairness. A lot of times our obsession with customer satisfaction drives a misguided customer to take advantage of us. This does not go far. We are very tough on ourselves when we make a mistake but we want the same transparency from the customer when they screw up. Fair is fair. Paradoxically, customers end up by respecting and trusting us more.
Tackle a problem immediately. Speed is of the essence. Act immediately to address any issue with a sense of urgency. Tell your people they have an open direct escalation lines to management to fix any problem.
Solve endemic issues with process. Constant fire fighting does not scale. Our people are trained to spot recurrent problems and deploy permanent solutions that prevent the issue from happening again. The company is constantly tuning practices and evolving processes.
Hire smart, accountable, high-energy people. We can only address new issues fast through accountable, high energy people. We can only solve problems permanently with innovative solutions through smart people. This is why we invest so much in the recruitment process and in creating an environment where this class of people can thrive.

Founders, Stockholders, CEOs and Technicians

By Paulo Rosado on April 22, 2009 12:01 AM | No Comments | No TrackBacks

A common mistake of founders is to believe that being a founder is anything of value. In fact, a founder is best defined as a composition of 3 roles.

The first role is the one of "stockholder". A stockholder holds stock. It is the fact that founders hold stock that will eventually make them wealthy. When you start, you and your excited co-founders own the company. So you are primarily stockholders.

The second role is the one of "CEO - Chief Executive Officer". Well, in a fresh startup being called the CEO is usually a nice euphuism to describe the guy who wears the tie among the group of engineers that make the founding team. But basically it means that as CEO you call the shots and direct the strategy of the company. It won't make you rich unless you take a large part of the profits as bonus (if you happen to be the CEO of a bankrupting financial institution). As a startup your salary is not going to make you rich.

The third role is the one of "technician". In tech companies this role is described as the "CTO - Chief Technology Officer" or something similar. This is most likely, your main area of comfort and initially it is yours (and your team's) technical or service experience acumen that will make the company successful.

The first conflict occurs when you have to bring in investors. Investors give you money and become stockholders. Inexperience, greedy people do not understand the value of well capitalize companies and they refuse to part way from a percentage of the company to someone "who is not going to work". Very common situation when starting small, service oriented businesses. The concept of an investor that will never dirty his own hands is a bit alien.

The second challenge typically happens to the founder CEO, as the company grows. In the beginning the company is small and everyone is focused on building the product or providing a service to a small set of customers. If it is a service the main founder is probably the guy who is doing a large part of that service. As the company grows more work is done at managing people, financial stuff, you know: boring junk. Regularly, the founder tends to find refuge in the "technician" part of his 3 roles and the company starts to suffer. This is probably a good time to think as a stockholder, fire yourself and hire a CEO to run your own company. If you have brought a good VC they will make sure that your investment and theirs is well guarded and they will help you fire yourself.

In the US this is usually okay. People care too much about money to understand they rather prefer to be the owner of a successful company than the leader of a failure. They retrench back to a CTO or technical role easily. The founder of Yahoo at a point was called Chief Yahoo. Cool title.

In Portugal, I have seen founder CEOs who desperately need fresh money into the company alienate investors because they are afraid of losing control, i.e. being fired. A smart investor will not touch these companies with a mile-long pole.

Many founders, ex-CEOs cannot phantom having to work for an external CEO and they leave. Leaving is okay, hey you are still a stockholder and you own an asset that later might be sold to a private equity or another company. So it is worth potential money. It is an investment. Owning a piece of a company might cost you a lot of money or sweat but after you got it is the easiest role to perform. Just stand still and let the thing grow and valuate the best it can.

This is why I do not really like the term founder. I prefer Stockholder, CEO or Technician. If you can define what you are, what you are good at, it will help you and your co-workers work out your internal conflicts of interest. The company will be healthier and all stockholders will know that everyone is working to maximize company value.

Acid Test #2: The Problem Spotter Test (Does your manager detect problems when they are small?)

By Paulo Rosado on April 21, 2009 3:31 PM | No Comments | No TrackBacks

Does your manager detect unforeseen problems when they are small?
Does his team spot these problems when they are small?

There are people that through experience and intuition are good at spotting potential problems. I like people who consider small problems as problematic as big problems and find the energy to tackle them immediately while the impact and cost is low.

People who do not consider small problems worth tackling reflect a behavior where they don't seem to even get there is a problem growing into a major crisis. They breeze through issues without paying notice. And then my capacity to trust and delegate on these people decreases.

There is a category of people that only spot problems. These are in general useful in an organization but they might come out as complainers and whiners. Problem spotters that can not become part of a solution eventually loose credibility. However, in my opinion, it is always better to have a problem spotter that is not a problem solver than to have a person that can neither spot nor solve problems.

Acid Test #1: The Worry Test (Does your manager worry more than you?)

By Paulo Rosado on April 20, 2009 9:54 PM | No Comments | No TrackBacks

Does your manager worry more than you?
And does the team reporting to him worry more than him?

Or has he established a chain of people who do not worry and therefore do not tackle the problems when they are small?

This test reflects the fact that a manager wants to trust that the person reporting to him is worried. I usually try to measure signs of a little stress and accountability when problems occur. If a person that is under you is immune to stress, then he will have less pressure to fix the problem.

I also evaluate the fact that the manager has built a network of people who worry reporting to him. If they have these people then he can trust that a lot of problems that surface will be dealt by his reports.

Worrying is a direct consequence of being responsible. And responsibility is something that a person either has or does not have. I have never been able to recover an irresponsible guy. So the best thing is for you to make sure you don't hire them. If you did hire him, you have made a mistake and you have to get rid of him immediately.

Disclaimer: the text on these Tests uses a lot of "he" and "him" for simplicity in writing. Of course the same rules apply to ladies.

Acid Tests of Great Management

By Paulo Rosado on April 20, 2009 9:44 PM | No Comments | No TrackBacks

Over the years I have accumulated a series of guidelines that I have structured into Acid Tests and which I have been using in my role as CEO at OutSystems.

These tests will help you isolate some crucial finer points of manager behavior and they have helped me and my reports understand specific areas to work on and constantly focus on becoming better. The tests were initially written as a way for my direct reports to understand what I expect from them, therefore the weird tone of the discourse.

If you are a middle manager or a recently promoted manager you can adapt easily to your particular situation.

In the next weeks I will periodically post these tests in this blog. Comments and feedback are encouraged. Enjoy.

Why CEOs and CFOs hate IT

By Paulo Rosado on April 18, 2009 8:04 PM | 1 Comment | No TrackBacks

This insightful article from Thomas Wailgum at CIO.com summarizes the typical situation organizations face when having to adapt commodity software to a changing business and to their specific processes.

Do not change ERPs
Traditional software packages (ERP suites the best example) are, by definition, not meant to be customized. The strategy of ERP vendors is to embed in their software, business processes that are common enough to be deployed in the largest possible number of companies. The continuous addition of new functionality produces a bloated mass of alternative code with very complex product release cycles.

Organizations that customize a package create a private "code branch" that needs to be maintained in-house. This is like diving into the gates of hell. From that point on, you inherit part of the vendor's complex development cycle. You make it very difficult to merge your own changes with the next product release of the vendor. Your maintenance cost sky rockets and your meager resources get sucked by these packages. The wise and experienced IT professional only needs to go through this process once to never again dare to customize an ERP.

But if you use packages to only implement commodity processes how do you support the processes that are your own? And how do you support processes that are the result of internal innovation and represent your own strategic competitive differentiation?

Commodity vs. Competitive

To hint on the answer, I will borrow Geoffrey Moore's Core-Context model. Geoffrey categorizes processes and their respective IT according to two vectors. On one axis, Core vs. Context. Core processes are the ones that are your source of differentiation. Context processes are all the others. On an orthogonal axis he classifies processes as non-mission critical vs.mission critical. The end result is a simple chart that depicts 4 stages of evolution of these processes.

Innovative processes, strategies and ideas and their supporting IT, flow from the Invent, up to Deploy To Scale. In time they become a commodity (as they are copied by others) and move sideways to Manage Scale. Finally some of these processes stop being mission critical and can be Offloaded.

Packages are a good fit if applied to processes in the Context quadrants. And, in this case it is acceptable that the organization actually adapts to the ERP processes. Hey, it is commodity, so except for some reengineering discomfort, why not?

Build Custom Software

IT applied to the Core quadrants however, needs to reflect the innovation that is created inside the organization. In this case you need to build custom software. You need to have the software adapt to the organization processes. There is really no way around it.

ITs that support fast changing organizations, are already doing this. A typical enterprise architecture tends to divide itself between packages and custom built systems. A zoo of Java and/or .Net systems, Sharepoint customized portals, and Process Workflow tools support the two left quadrants. Web Services (I don't dare use the term "SOA") glue these things together.

So, is this a good strategy? Isn't there anything to hate about custom systems? Yes, there is. I will blog about it later.

OutSystems NextStep'09: thank you all.

By Paulo Rosado on April 18, 2009 12:01 AM | No Comments | No TrackBacks

It's only fair that I start this blog with a comment on the OutSystems NextStep'09 conference, held in Lisbon, the past April 15,16. We have come a long way since our first NextStep (2004). As a lot of friends and business associates congratulated me on how much we have achieved since 2001 when the company was founded, I felt a bit like I was cheating, a bit like a proud father.

In fact it was the amazing amount of energy, work and ideas from many OutSystems collaborators and our OutPartner community that created such a success out of this NextStep event.

My contribution was to help hire such great people and stay out of the way. It never felt so good to not be in control.

Main Index | Archives | May 2009 »

tech ramblings

Management, Entrepreneurship, IT and other ramblings on stumbling and thriving in the high-tech world

April 2009 Archives

Acid Test #3:The Problem Solver Test.

OutSystems: 5 steps towards building a customer focused culture

Founders, Stockholders, CEOs and Technicians

Acid Test #2: The Problem Spotter Test (Does your manager detect problems when they are small?)

Acid Test #1: The Worry Test (Does your manager worry more than you?)

Acid Tests of Great Management

Why CEOs and CFOs hate IT

OutSystems NextStep'09: thank you all.

By Paulo Rosado

Search

About this Archive

Categories

Monthly Archives