Dedicated to Account Managers

Finally, the day came, when my career at HindiBrain is over. HindiBrain rather differs from anything before I have seen.

I remember my first question when I was employed here. The lady who came up with job offer called herself “account manager”. So I naturally asked “What does account manager?” How strange that I didn’t get strict answer until the very end of staying there.

So what is behind this peculiar position?

There is an explanatory document inside local wiki-look-like knowledge base (one of those funny documents which usually are NEVER read by anyone except who wrote them). I read that document twice, than another time … I concluded I’m lucky to find the most favorite position in our organization. Would you like to ask me why it’s the most favorite?

List of responsibilities is pretty obscure, but it generally covers business and relationship development but excludes delivery satisfaction scores from the partner as well as team satisfaction. So if I not mistaken everything that needed from site of AM is to check budget calculations and keep customer’s mood in fit. And only first is more or less measurable. The latter always can be appealed to delivery satisfaction scores, team satisfaction or “unfavorable environment”. It’s quite challenging to imagine situation when account manager will have to admit that customer dissatisfaction is only his fault and caused neither by deliver nor by bad team spirit.

Another advantage of this position is authority level: It’s equal to top management and can get any project related information.
Administrative power is substantial: development team has to submit the orders of AM irrespective to current state of the project and direct agreements with customer.
List of activities are narrowed by book-keeping and negotiations, activities like requirement analysis, development and acceptance testing is omitted.
And the final responsibility note (my favorite): The activities above do not necessary mean that AM is doing all of them, yet, it means that AM takes the ownership of these items and is primarily responsible for their successful completion. He/she may delegate the particular tasks to particular people within the delivery organization. So the precious thing is freedom to choose what you’d like to be responsible for …

How to become account manager?

You have to be good negotiator and avoid conflicts. Popular opinion among top manager is that this person should be capable to manager multiple projects (don’t forget to include this to CV), be able to speak with managers by using their slang (keep in mind all teams from UAT to CMMI). To some extend organization should trust that man, who is going to be account manager, which is gained by month of work on similar position within organization. This work is normally quite distant from team players and even if you are so lucky to become AM very quickly technical and team leading background is decaying and become weak by that time.
It was funny when AM was claiming to improve team’s performance on 20% just by introducing man responsible for configuration management. Indeed so funny when you’re in team, but customer usually gets better to see something is changed in development team during time of uncertainty.

Ultimate Yes-man.

Well why organization keeps position of secretaries with salary of top managers?
Directors are also people and do not like responsibility, so it’s better to have someone associated with account better than associate accounts with themselves. Customers are always complaining about something and there is necessary to have single contact to them
One of the top managers called this position “backdoor” for the customer. Customer should be sure that there is always another way to get things done. Getting things done in this case is normally to get something team can’t commit or deliver. This normally means to break existing agreements with team.
For instance, customer wants more features within the same time frame. Team always says: well, it’s possible, but we have already plan, so you have to provide us feature we can drop. On another hand, AM always says big solid “Yes” and try to handle something on team level. I don’t know the reason, but AM and management in this organization does believe that there are always methods to increase delivery output immediately. It’s very dubious especially if you keep in mind that there are two levels of management (project managers and team leads) who suppose to increase output on daily basis.

Can this job be done without jeopardizing team efforts?

Well, I know teams usually are not perfect, sometimes they really need some external help to improve their capacities. But this is challenging task for different people, so AM can do literally nothing. It’s better to assume that:

There is no way to immediately increase team performance in 10%

I know one organization about the same size as HindiBrain. They have just one account manager responsible for customer negotiations while we have dozen. Now in crisis their business is expanding, ours is shrinking. Just ask me why …
Their account manager has no power over teams at all. And he has no doubt that customer may have minor report about underlying projects, so he is doing only one way: reveal delivery scores and reconcile customer moods. So if customer comes up with statement “Your team is a bunch of the lazy piglets! You have to whip them properly!” is treated not as action item to perform Chrystal Nacht at team side, but as bad mood of customer. Assuming this by man with excellent negotiation skills can be very useful in organization ...

The gene of the irresponsibility

    One of quality engineers from my former team asked me a stunning question:

- How many hotfix iteration have you been doing on average before the major release?

    You know, there is a special context of that conversation about our project and team, which still continuing without me on board. It was hard to admit that we used to have no hotfix iterations at all. To be precise, assume that hotfix is iteration when no functionality created, but rather fixed, visually improved or removed in order to keep software consistent and to not expose unfinished parts. In reality hotfixes became so usual recently that I didn't pay much attention that I had never done it.
    After rushing weekend I can confess: People, indeed I didn't have ANY hotfix iteration. In fact, I can see no argument why any project or team should have such iterations.

Aren't you able to predict that some certain parts won't be completed before?
Many will appeal to the hectic they suffer in the project and justify lack of strategic thinking. Still irrespective to what model did you choose agile or waterfall there are people whose primary responsibility is to make forecasts. So absence of any prediction can not be tolerated. Regarding our project I still have two arguments:

1. There is a difference between biasing within one iteration and biasing over iterations: I can imagine why team committed to 23 tasks was managed to finish only 20. That's something that forms team performance (or in Agile terms - velocity).
But how can you (team, manager and product owner) do 3 iteration in line and then you need 2 more?
2. We are talking about projects within one team and one product owner. New product implements functionality of the old one. Product owners and developers are mostly left unchanged. Users left the same. Even requirements can be reused. Only things were changed are technologies (I guess that's positive upgrade) and process (...)

Spit and polish in Software

    To my former NTSR project something called spit and polish has been introduced. Spit and polish is an iteration task which includes resolution of minor troubles and fixes.
Examples would be like incorrect rendering in webforms or some minor problems like only USD is supported (in control that suppose to have EUR and JPY).
IMHO, this is our project's KNOW-HOW and arguably the most stupid practice I've seen in IT. Pragmatically I would say there are 2 negative things about spit and polish:
1) everything can be claimed as spit and polish.
2) no one cares about time spent on that.

    The latter requires certain explanations: In fact developers are do not putting much efforts to register hours for tasks pretended to be spit and polish. And what they definitely not do is to describe what exactly has been done within spit and polish (because - saving time on that is primary reason why do we have spit and polish).
    But even if developers would be enough motivated to register time spent on that there is anyway deeper trouble ... From management perspective this time can be treated as nothing but direct loss: you can neither predict nor decompose this time. And that means that you can't do anything about it at all.
    The root causes of this is going through human factor and dissolving somewhere in the deepest aspect of human psychology. Being forced to deliver faster, people tend to shrink their responsibilities. Manager who suggested to deliver the functionality first and then the quality does not care about quality at all. I remember remarkable interview with Bjarne Stroustrup where he was saying

In reality, that's impossible. People reward developers who deliver software that is cheap, buggy, and first.

I guess there is no hope that at some point the gene of the irresponsibility will be extinct. God has special providence for its adherents ...

Project evaluation a la carte

    I work as support administrator in huge outsourcing company. Team is big and dynamically growing and pretended to be big and happy family.
    I'm not very ambitions in career, indeed some of my mates are already occupy very prestigious management positions. Normally, I'm trying to avoid responsibility I can't control. I believe that most of people in top management NEVER control things, they are responsible for. But believe that I can do better then they is really phenomenal.
    Story begins in that nasty autumn day when manager said that we supposed to keep all tasks estimated planned for release in order to improve our proximity.
    Looks pretty simple for project you might have been working on, but I would like to bring your attention to terms marked in italics.
    Keep estimated doesn't mean to estimate just once: it means everyday estimations should be file.
    Release means not just single iteration, but all bunch of tasks from all iterations we planned or even didn't yet planned.
    Proximity? I actually didn't catch what the hell is that ...

    My answer was very rational, but disappointed manager quite hard: he told that I should elaborate way to define alternative approaches and insisted to have meeting dedicated to my response where I should have explained situation to the team leads. Actually my first response provided certain kind of workarounds for this: we can make releases shorter or we can make full estimation just once and then concentrate on support tasks. Otherwise we spend more than 20 hours a day just for estimations.
    I have conducted the meeting, but and made the same conclusions about situation, all other team didn't have so many issues, they were incoherent and releases where much oftener, but they supported my points and we closed the meeting.

    I was very surprised when suddenly I saw meeting invitation regarding proximity in my calender scheduled to 6 PM. Oh, God, did you forget how much time I spent on this?

    The meeting was eye-opener for me about how projects within our corporations are evaluated by customer. You know once per quarter we have so called evaluation questionnaires, where customer put marks from 1 to 5 to 8 different nominations. Proximity is one of those nominations and we get awful mark (2) for it. 2 means less then expected, so our proximity was expected to be better then it is.

    Team was very curious about this issue (in fact we had no other choice) and kindly asked departments head who also attended this meeting what is going on and how do we measure proximity?

    Well, we were explained that main goal of our meeting is to collect ideas how to improve it and our manager has already requested from customer explanation why proximity is was estimated so poor. Here is the letter:

Dear Donnie,
    Thank you a lot for filling evaluation form of our NTSR project!
    Could you please give us explanation what is proximity and what team is responsible for reducing proximity ...

    If you give us more extensive information we will put our efforts to find out why proximity is so poor and elaborate plans how to improve it.

Respectfully Yours,
    Julius Eiche,
    PM of NTSR project

    Ok, people, so what we can do with it? Donnie's reply was quite obscure, so it doesn't help us very much. Let us thing about this.
    Well proximity in Wikipedia gives us certain answer: proximity is ...
    Wait, wait, wait, wait! Do we really have no perception what the proximity is? Evaluation form is standard for all project in our organization! And it's not a first time it was introduced to the customer! Actually our customer put marks for proximity already several times ...

    Our manager was on top: he used so peculiar phrases to explain how important and difficult his job is. But, how about the result? We have no information about thing that has major influence on our project! We have nothing else that has such significant effect on the project destiny.

    Suddenly I realize that anyone can be not worse manager for our project than Julius: he has the same idea about evaluation as we all. Only difference is that he new about them and finding out how those measurements have been performed is primary task for any manager.
    Now I don't believe in managers and believe that if we got mark for any other nomination (tolerance, productivity, proactivity and so on) the reply would be the same: Dear Donnie, we are to stupid to understand what a hell that is. Teach us and hope that we will do better next 3 month.

    Meeting show me how deep problem was. In fact I'm quite anxious about 2 things:
- getting me to find out what are all those values in evaluation table
- requesting what else our managers have concealed that can be strike us so badly.

Thoughts about fixed-priced projects

Negotiating is domain area, which for most people is much more complicated to deal with, then even the most challenging technical task.
Once during one of our Agile club we have discussed fixed-priced contracts and applying agile methodologies to them.

This was quite hot topic: audience consisted of mainly agile adepts, but the projects they were involved indeed where fixed-prices.

In generally that discussion is not worth to retell it entirely, but there were some thoughts that may be very much valuable for me.

1. Above all, fixed-priced projects are normally more expensive and that means they are potentially more lucrative for executor (for IT company or team that works on them). It's a high price for professionalism. If I were millionaire I would rather have 100% service for 100% price:

I don't need analysts, testers, QA, IT department from my side to support YOUR development. I don't care if it's 400% more expensive: just give me entire calculation and risks and I will put your proposal under consideration.

So team has a good opportunity to provide product owner from their side and to make fair product for good price.

2. Commit or not commit that the question.
And all risks should be calculated before project is started

Here I have exposed one more thought: can we reuse that approaches that is used by venture capitalist when they do their business in IT
Unfortunately not: normally venture capitalists' approach is to be aware and to be acquainted with people: but they have money to take over risk, we don't :(

3. Fixed price project can be conducted as agile projects, but all necessary infrastructure should be provided by executor.

One of my colleagues proposed idea to specify if customer is opened or not. So if he ready for communication that better if he is not.

I also had thought about that: but I'd rather just exclude projects that depend on single non-responsive person as not good for me.

Just make me happy and don't ask any questions.

If your customer is large organization it's not a big problem if they are remote and not responsive. I've seen so many times when customer's representative not provided enough analyst or information about their product or requirements. But I have never seen customer that forbade their coworkers to speak with our coworkers.
Even in the worst case you anyway can talk with them, have discussions, drink bear or date their office managers.
You do have chance take information about how to make them happy (unless your customer is not Jesuits Order).
The costs of all this is a different thing. But since account management has word "presentation costs" normal business used to work with them, so IT business also have to.
So, viva forever! :)

Motivation and demotivation

    Since one month I didn't touch my blog. This can probably misguide people who watch it planting feeling that I became more idle than I used to be. This is not true, indeed within last month besides my trip to Crimea peninsula on Black See (see the picture) I have understood many things regarding my psychology.

    Oriental wisemen say that all wisdom starts with self-knowledge. The recent crucial question for me here is:

what is the major factor why I am staying for more than 3 years in one company against all odds of rapidly changing IT world?

    And accordingly to all customs, I am coming to the final conclusion when debates are getting closed …
    Before February 2008 my negotiations with all other people were based on following principles:

• keep yourself busy and useful for team as possible as you can without loosing self-confidence


• whenever you evidently asked for something by your team member consider this as opportunity to do something for team, i.e. small and urgent deals has higher priority than ongoing tasks


• always be responsive, friendly and polite to all people. Consider idling and ignoring as something worse than being unfriendly or refuse


• to people disliking you be as good and friendly as for others, just don’t tip them for that: conciliate this with people you like better


• never look for reasons why do you dislike somebody or something

    Although I knew there were always few people that dislike me in ANY environment, but I can go long with this, as long as I have enough possibility to choose whom I speak to and negotiate with i.e. vary my closest environment. This position became very distinguishing for me especially in IT crowd: since most of people are introverts they won't pay much attention on you as long as you initiate it personally. And there are many ways how to avoid evident conflicts, since work is rather incoherent.
    But situation got changed quite dramatically when the boss of all it has been changed: the slight but very important difference between new and old one is following: the latter allowed me behaving like I’ve described above. Beside this there are very many other differences: they might be (and I’m sure they are) fatal for team, but not for me being in the team. I clearly understand that living in not at all prosperous country with underdeveloped economy I still can make my life happy. Why then I can’t be happy in unfriendly environment?
    Yes, I can indeed! The key is to give me responsibility I can hold and control on 100% and chance to develop it i.e. to make comfortable world for me and make it extendable (at least make me believe that it’s extendable). This is not obligatory large responsibility, but somewhere near should be potential for self-development.
    This motivates me still more than salary and career: it just makes me fun. The money is a fair price balancing between employers that tend to pay less and employees that tend to get more. I work primarily not for money, but for having time of my life.
    This is the most important motivating factor. But what is the most demotivating? Try to reveal them as direct opposition of motivating factors.
    Boss’ inconsistency demotivates me much: when he defines my responsibilities every day penetrating and changing them all time, he uses me at least ineffectively: instead of giving me right job forever he needs to control my job. Otherwise soon he won’t understand what I’m doing and what I have to do, which is even worse. Are you scared that job given at the first day not the most correct? Never mind, make sure that it’s useful at least even if it is not the most useful.
    Non responsiveness demotivates me much: IMHO, all people should be ready to accept feedback, it is not effectiveness, but it’s mathematical derivation of the effectiveness, so it’s a power to improve it.
    Professional ignorance demotivates me much. Man who doesn’t improve his skills regularly should not expect that his subordinated people will improve them. I know that project manager is quite challenging position: he ought
    1) to know how to work with software development;
    2) to know how to work with software developers;
In real life it is so complicated that no one can do both things, that normally your are stronger in one area and weaker in another. Ring-bouy for this situation is awareness of your skills: if you know how weak you are in one thing or another, or at least you are tending to understand this, you may find proper assistance in your team.

    Facing all this together my position is getting very unpleasant for me: people I would like to work with still exist but they are more distant than people I have to work with. It’s even more unpleasant than if I was surrounded with ignorant people with no aware of some alternatives are there. So from now I refused to meet my aforementioned principle #5 (never look for reasons why do you dislike somebody or something).

    Now I dislike people that make decision made by own “exclusive” experience. It is a root of all evil even if decision was right at some particular point. But I judge people not for their decision, but namely for the way how they had been done: In rapidly changed world you should not call your predecessor’s decisions ridiculous, because one day your today’s decisions might seem ridiculous to your successors.
    One day a good decision may be considered as bad or a bad decision may be considered as good ... But the way how decision was made stands still ...

Agile experience in complex projects

    Recently I've taken small break to rearrange my knowledge and experience gained in quite difficult projects that I have last 2 years. The mainstream of this period is continuous attempts to apply agile approachs in our team. Upon a time my endeavour ceases to look endless: We really indeed can be agile! (it's not obligatory so popular SCRUM).
    Recent XP camp in Kyiv (Thanks so much to Naresh Jain) and works of Gojko Adzic (I wish I knew that man earlier) made me strong believe that even our heavy project can be more "agilized".
    Presentation "Agile experience in complex projects" is an excerption of ideas I embrace about software development and particularly about project management. Of course, it was technically infeasible to look so broad topic through all aspects, but my purpose was to give an overview of subject, since I met so many IT people that never experienced problems like that, especially if they never participated big teams.

Q: How did God manage to create the world in 6 days?
A: Well ... there were no previous versions to maintain backward compatibility with.

    My presentation's focus is so called complex project. I've introduced this term myself, meaning following:

Distributed enterprise application
Distributed team in locations and cultures
No solid corporate culture
No men, who know entire system

    Few people among our community have already investigated problems and got the conclusions pretty close to mine.
    Although I've caught chill 2 days before, I hold presentation confident and quite successful. Questions of attendies discovered even more topics for future research.
    I heard question requesting patterns and antipatterns for agile-oriented project management. Although I like antipatterns very much (It was my first presentation at my host company) I didn't intend to discover "patterns" in this presentation. But the question is still very leading indeed: probably next post I'll devote to discovered antipatterns for project manager in my model. I do have a plan.