Software Business in the Middle East

One of the software developers from my partner’s company in Egypt announced yesterday that he quits joining a larger company. I understand this guy very well. The company of my partner develops about 10 different products. Each product is developed by one, maximum two developers. All products are independent from each other, and that means there is almost no team work as there is no much difference between one company with 10 independent products or 10 independent companies with one product and one developer each.

I remember my transfer from small company to the large one and my impression working in a large company for a large project.

Project Size

Small Project – I worked for projects in teams of one to eight people. It was work in IT departments of small and middle size insurance companies or IT department of manufacturing company. Normally, the projects were developed for internal use in other departments, like sales, book-keeping and delivery.

Large Project – about 2’000 people in different countries.

Speciality and Tasks

Small Project – you do any job related to the project. In the last small project I worked with everybody was working with database, business logic, user interface as well as with different utilities and administration tools. I liked this job because you get wide experience in different areas.

Large Project – relatively clear separation of specialities between teams. One team is working with Security, another with Architecture that is responsible for integration of all the modules and database access, and there are also teams working with different modules in the system. In every team you can also find people with different specialities and tasks. You might find yourself being always responsible for one particular button, for example. Although the functionality behind that button might be very complicated, it is still the same button, and it will not be fun working with it for the longer period of time.

We also had situations when somebody in the team had no idea how to deal with database because database access was encapsulated by Architecture, and developers would not need to know how it works. The advantage of this approach is that everybody does what he or she can do best. The disadvantage – you do not get experience in other areas, and you simply cannot dig into the lower levels and understand what is going on there.

New Technologies and Methodologies

Small Project – it’s relatively simple to start using new stuff. Obviously, if you have developed FoxPro app for the past 10 years in your IT department, you cannot switch to C# over the course of one night, but it would be possible to start using automatic night builds or unit testing. The decisions to use something new are taken pretty fast because there is no long chain to discuss and approve the decision with the managers on different levels.

Large Project – any change or new idea is pretty difficult to implement. In our case we had a special site where everybody could apply the ideas about improvements, but since there were many people involved into the decision it took almost forever to get your idea implemented for the entire project.

But large project has another advantage – the size and scale of the used technologies. For example, It was great experience to see how global source control system worked synchronizing all changes in the code made in different countries and continents.

E-mails

Small Project – it’s simple. You either send e-mail to your colleague, or you stand up and come to his desk or his office. Your question is answered.

Large Project – it was the first time I saw e-mails send to hundreds of people at the same time. But that’s in case of some information sharing with the employees. Daily e-mails sent to discuss or solve something might be sent to 10 or 20 people “only“. Another thing I saw very often – if somebody sends you an e-mail, he also sends a copy to your manager. I guess it’s supposed to guarantee that I would get extra motivated to answer this e-mail since my manager used to remember all those hundreds of e-mails he gets daily as a copy.

If you leave for 4-weeks vacation, it is guaranteed that 500-700 e-mails will be waiting for you when you’re back. I never had those tones of e-mails working in small projects. Interesting fact is that now I also get such large amount of e-mails working in our startup. I guess it’s related to the fact that now I meet and keep contact with many people and there are many things happening around at the moment.

Project Management

Small Project – now it seems for me that managing small project is a piece of cake. But this is probably after working in the large project.

Large Project – being a top manager in a large project involves dealing with a lot of politics and a lot of stress. In case of our project I got a feeling that our top management was working 24 hours a day, 7 days a week – a lot of plans and reports around, millions of meetings and conference calls with the teams from different countries and other time zones.

Would I be able to manage the projects with thousands or even hundreds of people involved? I do not think so. First, I think that managing such projects requires certain experience dealing with the large projects and this is not the same as managing projects with 10-20 people involved. It takes time to gain this experience. And the second, I do not enjoy much from politics and intrigues. So I think that if I get really large project to manage now I will simply screw it up.

Intrigues

Small Project – there are intrigues of course, but sometimes it’s difficult to notice them as they are not of the same large scale as in case of the large projects.

Large Project – a lot of them for any taste. There are kind of “healthy” intrigues when people trying to get more resources to make their jobs done, and there are dirty intrigues when people fight for getting better positions, more responsibility and such stuff.

Stupid Tasks

Small Project – basically, all tasks are reasonable as nobody has time to do something stupid that nobody needs.

Large Project – a lot of them. Well, I do not really mean the tasks are stupid, because they are stupid :-). Instead, I mean the way they are organized. I understand that applying for patents is the great thing, but I am against the requirement for every team to apply for at least two patents every 6 months. In this case you have a risk that people will write any stupid idea as patent application.

Communication with the Customers

Small Project – customers of IT department are other departments. The communication with them was almost on daily basis. I think it’s similar to startups where any developer might talk to the customer directly helping them to solve a particular problem.

Large Project – it’s not so often when developers talk to the clients, because there are Product Analysts who are responsible for this. But I have to admit that we had great experience organizing visits to the customer site to see how our product is used in real production environment.

Colleagues and Experience Exchange

Small Project – since there are not so many colleagues working with you in a small project, you don’t have very good chances to learn something new from them. It’s really cool if you have more experienced colleagues working with you. Several times working in small projects I had a manager who was very experienced IT guy who shared a lot of his experience with us.

Large Project – chances to learn something new from your colleagues are pretty good. I think I was lucky working in a large project and meet the great team of IT professionals who was smarter and more experienced than me. My colleagues were Swedes, Indians, Norwegians, Germans, Americans and many others. It was good experience exchange as well as cultural exchange also.

Another interesting moment – during those four years I was working in a large project, there were four couples who decided they wanted to be together. But also, some people got divorced with their wives or husbands (who didn’t work in the project).

Carrier Opportunity

Small Project – probable there is no way to make your carrier. You could finally become project manager or IT manager, but there is a certain limit in small companies and projects.

Large Project – you can become a manager of any team, or component lead inside a team or you even can become a Big Boss. See Intrigues for more details.

Business Trips

Small Project – not very often. Working in IT department of a small or middle size company, it’s not supposed to travel much as there is most likely no need for this.

Large Project – what I really liked in the large project is that we traveled a lot and pretty often, and I really miss it now. During some time, when I needed to travel to US or India monthly, I didn’t even unpack my travel bag. But probably I liked traveling so much because I was not married and I didn’t have a child at that time.

As a conclusion, I thing that working in a large project has more advantages then disadvantages. Intrigues and politics will remain intrigues and politics that put barriers for your work, but experience you get working with many IT professionals make a lot of sense in my opinion. So I understand the developer who quit my partner’s company to join a larger firm. Later he will decide if he likes to be a big frog in a small pond, or a small frog in a big pond.

In any case, this experience will help starting up your own company one day.

Today morning I got a call from one company. During the first few seconds, when I was listening the company introduction, I thought this call was another good candidate to answer “Thank you, but no thank you” – the standard answer that has been developed thanks to countless calls from Indian outsourcing companies.

But this call was different, and I think those guys got a brilliant business idea. Basically, they help companies reaching their potential customers. Beauty of this idea is that they do not give you direct phone number of Some Big Boss’s secretary, but they arrange a meeting between you and potential customer’s Chief Information Officer (CIO).

The company organizes the summit and invites about 70 CIOs to participate. They do not only invite CIOs, but they also learn from those C-level managers about current IT needs of their organizations – what solutions they are looking for at the moment, if they think to outsource some of their products, or they’re in need of specific consultant, or anything else.

Then the company invites IT solution providers. Maximum two companies from each business domain are invited. It means if you are in IT outsourcing business, there will be only you and one more company that provides IT outsourcing services.

As IT solution provider you get a list of all CIOs who will participate on the summit, and you may book the meetings with 30 of them during the event. What good with such meetings is that, first of all, you talk to the main decision maker in a potential customer’s organization. From our experience, getting on the meeting with C-level executives in a large company is very difficult task, and it might take you months before you reach that level passing through endless secretaries. The second, you know exactly what any particular CIO is looking for, and you book meetings only with those CIO you can help to.

With all these good stuff, there are also two things that might probably be improved. The summit is three days long. It means that having 30 meetings, you would have 10 meetings each day, and it makes me feel that schedule will be very tight. People might get tired to keep concentrated. Another thing I didn’t like was the price, which is around 30’000 EUR if you are IT solution provider. I didn’t like the price from my small startup company perspective, but I guess if any other company spends hundreds of thousands dollars for marketing each year, they might want to consider rearranging of their marketing budget to be able to participate in this kind of events. From another hand, it means that you pay 1’000 EUR for each meeting – and it is probably not such much money to get a chance meeting with the decision maker of the company, who is looking for a solution you think you can provide. According to the company statistics, those 30 meetings normally end up with 8-12 follow up meetings. So the result is about 30%. I think the most interesting statistics would be to see how many contracts are signed out of those 30 meetings.

What I also liked is the interest from the salesman’s side to answer all my questions even after it became clear for both of us that I wasn’t their customer, at least for this year. I was interested to learn more about this idea – it’s kind of Business Event, but organized completely different way I used to see in Dubai before. The salesman answered all my questions, and I got really positive impression about the company and the event. It is probably a good example of sales making a contact with a potential customer – no matter you don’t get this customer now, you might get him later, even in a few years.

You can learn more about the company on their web site and here you can learn more about the event.

In his last post, Neil Davidson talked about some of the lessons they learned organizing the Business of Software conference. All the points are very well known but it’s never too much repeating them again and again because they make a lot of sense for any new startup.

Here come some of the excerpts.

“Having a good product isn’t enough. Even if you have an excellent product, you can’t just drop it into the marketplace and expect people to find it, and buy it. If you build a better mousetrap, the world will not beat a path to your door. Of course, you can’t market a dog: a good product is necessary, but not sufficient. Whatever your product - whether it’s software or a conference - you need to spend a lot of time, thought, effort and, less importantly, money on getting people to notice it.”

Especially true for geeks starting up their own companies. Normally we do love programming and technical stuff, and we do not have much experience and passion to deal with marketing and advertisement.

“Ignore other people. Many people - often the same people - will tell you that what you want to do can’t be done; it’s a dumb idea; it will never work. Listen to them, but do it anyway.”

Very-very true. Pessimists are always good because they might help you to look at your idea from different angles, but do not allow them ruin your idea.

Read the rest of the article on Neil’s blog.