Who should sell

Disclaimer: it's about IT outsourcing service.


There is a popular slogan: In our organization, everyone sells!

Actually, this principle was intended to motivate all employees to think about customer needs while performing their everyday work. However, sometimes management goes further, and tries to use this idea wider delegating selling responsibilities to production departments.

From one side, this is a very good initiative, and there are a lot of arguments in favour:

• production personnel is usually more technical, so they can quicker estimate the complexity of requirements, propose different possible solutions, involve the customer in discussion;
• production team understands the needs of existing customer better than sales people do, because of day-to-day interaction;
• having technical background, it's easier to answer process-related questions, thus presenting the company on more professional level.

These arguments are quite strong to start thinking about deep involvement of technical staff into sale activity, at least with existing customers. Why not?

Actually, why not? I still think it's not a bad idea. It just have another side of the coin:

• The most important task for a development department is production. This is the area where they have to provide measurable results. If the results are not satisfactory, even a good marketing deal won't be considered as an affordable excuse. So production managers postpone sale activities to the sideline, and usually its turn never happens.
• Size of a development department is usually the same or even smaller than amount of work that have to be performed. It means that these people simply have no enough time to do something special for sales.
  
• Production department personnel is usually not well trained for selling activities, and most of them are not disposed for this role.
  

Again, listed items do not mean that sale activity is only for sales people. They just have to be considered.


Even more, if we talk about marketing not about just selling process, then developers are often really involved in marketing whether they know it or not. If they are involved in deciding what features to build [and how it will work], they are doing marketing (And the Geeks Shall Market by Erik Sink. Business Of Software Blog. October 29, 2007).

Self-Motivation

It's quite usual to see newcomers being quickly recognized by management for some their achievements. The most noticeable category of rising stars is students, who has just started their professional career.

This fact is not surprising. People in the beginning of the career are usually very motivated to move to higher levels. These guys do a lot to provide quick visible results, follow all (well, about all) corporate policies, do not forget to provide all required reports and so on. They have a lot of things to learn, and a lot of stuff to do to demonstrate that they are not worse than others, they are better! It's a good stimulus, isn't it?

So are students usually more motivated than experienced professionals? May be, but I would say it in a different way.

Beginners are motivated by the need to prove their professional level and their ability to take different role or position. Some of them spends effort to be recognized by colleagues and management, others stay goals just for themselves. Both of these types can make a good career, but the first category usually does it faster and a bit chaotic while career path of the second group is more stable.

every soldier dreams of becoming a general;
every lieutenant dreams of becoming a colonel;
and every captain wants to be a major.

IT is quite similar. While gathering more knowledge and experience, the aspiration is being reduced.

Professional life becomes simpler, people just focus on their everyday activities. They do not try to do something perfectly and to get some bonus for that single achievement. For them, good results are not something uncommon, good results are normal.

Of course, professionals also do need to be recognized. Not just for some individual output, but for the constant success. They do not claim to get such recognition, but if such regular good work is being permanently ignored, the person starts thinking about her/his job in a different manner...

The Elite Team

In the early 1970s, a vice president of one of our client companies sent around a memo on the subject of travel expenses to everyone in his division. You may have received similar memos on the topic yourself, but this one was different. It said more or less this: "It
has come to my attention that some of you, when traveling on expenses, have been traveling economy class. This is not an economy-class organization. This is a first-class organization. When you fly on business from now on, you will fly first class." Of course that memo cost money. The expense was very real and the only thing you could balance against it was an enhanced sense of eliteness. At least one organization thought that was a valid tradeoff. Couldn't happen in a real-world corporation, you say? It happened at Xerox.

Peopleware: Productive Projects and Teams.
by Tom DeMarco, Timothy Lister

This is a very good sample of understanding the team spirit background. To feel and act as an elite team, its members must not just hear slogans propagandizing that they are the best. Each team member must know that they are allowed to be different, and really to be elite.

PR and hiring expectations

Today, I was told the opinion, that company public relations (PR) does not have any effect on the number of candidates "waiting in a line to be hired for the company". A background for this opinion was a statistics, that didn't reveal any hiring increase after massive PR campaigns.

This statement is probably correct... in a case when we are talking about large well-known company.

But if potential candidate never heard the company's name before, or heard the name but still has no associations with it, then chances are she/he won't pay enough attention to a vacancy. The ad can just look like a hundred other similar ads from companies, that will never give a lot of new opportunities, and that nay go out of business pretty soon.


I completely agree that PR doesn't help to hire a lot, but on the other hand its absence kills company growth.

Maintenance and Development... The difference?

"I do not want to work on a maintenance projects", - that's what can be heard from software developers and from candidates quite often. At the same time, most of them can't describe their understanding of the difference between project maintenance and project development or, in other words, the difference between the things they don't like and that they do like.


Project maintenance phase "description"

Below is the list of items that people use to describe the project maintenance phase:

1. Bug fixing
2. In few months after beginning of the project
3. When software architecture is ready
   
4. After the 1st public release
5. When you have to update other's code

So, every project, that is being developed for some time by two or more programmers and that has not failed yet, is a maintenance project, isn't it?


Why it happens

Actually, I was not satisfied with this simplified answer that every project is a maintenance stuff, so I tried to get more information about people, who insists that hates those maintenance projects. After collecting and comparing the results during a period of 4 years, I've come to the following classification:

• Husband is the developer, who works on some particular project from the very beginning, who came through a set of successful public releases, who knows about that product and its code everything. Such persons can be stuck to the project for quite long period of time and fill comfortable enough. However, one day can start "a middle age crisis". This can be a good push for "starting new life". After this point, Father hates even an idea to be involved in new long "engagement". Such crisis can be very short or long enough, but in most cases the person returns to its habits and becomes ready again for new "long relationship".
• Researcher always tries to improve something. He spends part of his work day performing planned activities, and other part looking for new information, trying different technologies. This person can be really bored by the project if it requires 100% of his time and doesn't allow experiments. A lot of people pretends to be researchers, however only very small percentage of them really are. Most projects are still OK for a researcher, because most projects are happy about introducing something that improves the result. Maintenance projects are even a land of plenty for research, because they usually do have some time for improvements. If it's not the case, then it's better to use the researcher on a different task.
• Grandma is a person who pretends to be bored spending a long period of time on similar tasks. However, such developer does nothing to change it. Such kind of a person continue using a rotary phone and hate it, but won't try a button one because "it's too complex" and she "doesn't know how".
• Pseudo-researcher is a middle between Researcher and Grandma. Such person isn't afraid of reading some new documentation, however she/he used to reject most innovations because "there is too late to integrate them into existing project". I'm sure that you heard a lot of times a phrase like: "Well, the idea/solution is really good, but it's impossible to use it on current projects because [...here some generic explanation, that fits all current company projects, goes...]. Let's utilize it for our next projects".
  
• Hack-worker is a programmer, who didn't use to do his job in workmanlike manner. Doesn't matter, if he joined the project from the beginning or when some parts had been ready. This person performs activities ignoring all circumstances, which are not directly covered by the task description. If he needs to paint a wall, he'll never be worried about keeping the floor clean. Fixing a bug, such person can create two or three new. After some period of time, when the number of project-related problems becomes quite high, hack-worker starts hating the project, and other "maintenance" projects. His favorite is to start the project and to leave it before bugs have been revealed.

What is it all about?

Good question... This analysis is one of few things that I had done before I realized how to use the results. So I was just collecting the statistics because I was interested in finding a real reason that stays behind hating "maintenance activities".

But one day, when I was involved in consulting activity related to hiring process in a company that had several software project of different kind, I returned to the same question and found out a way to use this info.

As a result, we prepared a set of questions which helped the company to classify job applicants in one of 6 ways^*, and then select appropriate project for particular candidate or do not make an offer at all.

--
^* 6 ways are 5 groups listed above + people who doesn't make too significant different between programming and "maintenance".

Formula for Success

While reading Eric Sink on the Business of Software, I've found a quote that very closely deals with one of my first posts in this blog, the one about mistakes and activities:

Would you like me to give you a formula for success? It's quite simple, really. Double your rate of failure. You are thinking of failure as the enemy of success. But it isn't as all. You can be discouraged by failure - or you can learn from it. So go ahead and make mistakes. Make all you can. Because, remember, that's where you will find success.

Thomas J. Watson, Sr., founder of IBM

If I had more time...

Sorry, this article is not intended for reading :-) It's just few notes that I want to keep for myself to return in a future (hm... am I really going to return to those topics one day?). It just like in the anecdote:

Sergeant: If your head is like a pan, and it's unable to keep anything, then get a notebook... or two as me...


So, If I had more time, I would write some interesting things about:

• Project Documentation - how to keep it actual all the time, and have people happy creating it;
• Side effect of standardization - the results of being paranoic about having everything standardized;
• Maintenance and Development. Where is the difference - by the way, where it is?
• HRs make IT salary grow in Eastern Europe (2004-2007, and may be it's still actual);
• The truth about offshore dedicated teams (companies|commands) - how these teams are being staffed, how vendors make profit, does customer have better options;

• If I had more time, I would... - how can I share time management knowledge, if I give such excuse myself? Well, I have a solution for myself, but I have some things to do that are more important for me in this short period of my life. It means, that one needs personal time management only if she/he has no enough time to complete the most important tasks.
  

Eastern Europe salaries in IT

The information below was collected from different sources in Belarus, Russia and Ukraine. However, please note that the graph below does not reflect trends for St.Petersburg and Moscow, because the statistics for those cities was significantly different in comparison with other places.




This chart can not be re-republished without written permission from Serge Stepantsov, this blog author. However, anyone can post a link to this page.

Comparison: Custom Solution vs. Standard Solution

Working on one task, I had a need to analyze the benefits of custom solution development against implementing particular standard platform.

Among other steps, I tried to do some web search to learn others' opinions, and to find out some related public materials. To my surprise, there were almost nothing published on this topic, except some marketing articles advertising their product or outsource development company. So, I've decided to publish summaries, that were collected during my analysis. Most of these materials are not related to the task I was working on and I didn't have a time to rewrite them in a better form yet (hope to do it one day), but please feel free to reuse ideas (e.g. comparison parameters) or to provide comment, which are always very welcome!

Note: in this article, Ready Solution means commercial product, not an open-source.

Attribute	Ready Solution	Custom Development
Base Product Cost		Usually, initial project investment isn’t required at all, or the amount is quite small.
Initial Customization	In most cases, ready solution requires less time to customize to a satisfactory level. However, rates for this customization are usually much higher than custom development rates.	Custom development always takes longer than implementation of existing solution. Yet, it’s still usual that Base Product Cost + Initial Customization cost for a ready solution is higher than total cost of own project.
Implementation Period	Implementation of some ready solution is always much quicker than custom development. If not, then it only means that bad product has been chosen
Licensing Fees		In a case of custom development, your usually have complete ownership over the source code, so there are no regular payments (except for some other 3rd party software, that can be required for application functionality)
Product Maintenance Cost		Custom solution is usually cheaper to maintain, because it’s possible to choose between different maintenance suppliers or even to maintain in-house. In a case of standard solution, a customer is tied to the original supplier and their exclusive rates.
Control over Product Evolution		The customer has exclusive rights to controls personal application evolution. However, if original supplier continues development of their standard product, they have a better source of information for new versions – the feedback from different users.
Product Versions	If a standard solution is being intensively developed by the supplier, it’s possible to benefit from new product versions that are being released. However, in most cases, it also means that the customer has to pay for features that they do not really need.
Knowledge Source	Usually, a standard platform already utilize some experience from the industry, so ready solution can become a good knowledge source in a product business area, if the customer has no very clear understanding for the future system.
User Training Cost		Usually, it’s easier/cheaper to train users for a custom solution, because such solutions are based on existing known company processes.
Technology Decisions		The customer has exclusive rights to select technologies that will be used for the solution. It allows to follow existing company standards (if any), or to select cheaper or better environment.
Risks	Utilizing existing solution usually has lower risk than trying to create a custom one. With a ready product it’s much more probable, the customer will receive working system on time and budget.

IT common role anti-patterns

Text of this article is a quote from An Agile New Year's Resolution for All of Us by Scott W. Ambler, Dr. Dobb's Portal, December 15, 2006:

I think that if you spend a few moments to reflect, that you'll agree with me that you've seen, if not exhibited yourself, one or more of these common role anti-patterns:

• True Believer. Also known as the "Born Again Developer," a True Believer "just knows" that their preferred approach to development is the best one and is very happy to let everyone else know it. The True Believer rarely seems to question what they know to be right, and strangely enough often struggles to justify why it's right. A better approach is to be open-minded but skeptical at the same time, recognizing that no approach is perfect and can always be improved upon.
• Mind Reader. In the middle of a discussion a Mind Reader will state what someone else must obviously be thinking. Strangely, Mind Readers only seem to pick up on negative ideas, or at least ideas which very clearly cast the other person in a bad light. A better approach is to ask other people what they're thinking instead of guessing; in other words, actively seek to communicate with one another.
• Hypocritical Preacher. A Hypocritical Preacher says one thing yet in practice does something else. For example, it's very easy to preach about the virtues of open and honest communication, or to promote collaboration with and respect for others, but it's a completely different matter to discuss ideas with those same people when their ideas are very different from your own. It's also very easy to preach about quality, yet not so easy to fund, develop and then support an automated, end-to-end testing environment. The solution is to practice what you preach, and if you're going to preach to only do so about the things that you actually practice.
• The Spammer. Need I say more?
• Unjustified Criticizer. An Unjustified Criticizer will often criticize something without having read it, often because it's about a topic which goes against their true beliefs or because it's written by someone they have disagreed with in the past. Unjustified Criticizers are easy to identify because they provide insufficient arguments to support their criticism, in fact they often make blanket statements and then refuse to justify those statements, and rarely seem willing to share their actual experiences pertaining to the topic (usually because they have none to share). The solution is to describe your own relevant experiences and then ask them to comment on them. You might not get an answer, but at least you'll provide others with a viewpoint based on fact.
• List Dictator. List Dictators are often Hypocritical Preachers, True Believers, and/or Unjustified Criticizers who find themselves in a position of power. A List Dictator will often define exactly what can and cannot be discussed on the list, but will often choose to flaunt those rules themselves as they see fit. In the extreme, List Dictators will often ban people who they feel are dissidents instead of publicly addressing their issues in the discussion forum. By limiting the discussion, List Dictators attempt to prevent others in a discussion forum from questioning the dogma which the List Dictator wishes to focus on, thereby promoting their agenda. To be fair, one benefit provided by List Dictators is that they often thwart the effort of spammers. Unfortunately there's little that we can do about List Dictators other than to try to convince them to behave more responsibly, otherwise we need to vote with our feet and create better discussion forums.
• Unknown Poster. Unknown Posters typically have list names such as "Cyber Guy", "Agile Guru-Dude", or "Object-Data Architect". Cute nicknames, if you're a teenager living in your parent's basement, but they don't tell us who you are. Unknown Posters often seem to be True Believers who don't to have the courage to be associated with the ideas that they're espousing. The rest of us reveal who we are, and we should invite everyone within a discussion forum to do the same.
• Indifferent Specialist. An Indifferent Specialist is someone who is often very good at what they do, be it Java programming, business analysis, or database design, yet they are rarely motivated to learn about things outside of their specialty. These people often underestimate the importance of these other things and in extreme cases will choose to denigrate these topics or the people who believe in them. Statements such as "Oh, that's something the programmers do" or "We need to blame management for that, they can be so dense sometimes" are indications that someone is an Indifferent Specialist. The solution is to strive to become a generalizing specialist, someone with one or more specialties and a general knowledge of IT and the business domain that they work in.
• Backstabber. A Backstabber will criticize someone, or their ideas, but their victim doesn't know that it's happened because they weren't included in the conversation. The solution is to have the courage to involve the person that you're criticizing in the conversation so that they have an opportunity to respond: In the case of online discussion forums, explicitly copy the person on your posting if you're not sure that they're on the list. If you have a strong argument, then you shouldn't be afraid of a response, should you?
• Blamer. Blamers are often Indifferent Specialists or True Believers who are a bit too arrogant for their own good. Instead of accepting responsibility for trying to solve a problem, they instead choose to blame others for the problems. Agile teams work together collaboratively and take responsibility for the project as a whole. If there's a problem, or if something isn't working well, it our responsibility. Blamers will promote division within teams, and in discussion forums, often to promote their own political agenda. The solution is to point out that we're all in this together and need to find a solution to the challenges that we face, and not to just push them off to someone else.