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 ...

Programmers Competition

Recently I partook in organization duties in All-Ukrainian Software Programmer Competition called Programmania.



This event pretend to be ultimate for all kinds of developers in this country. Spectrum of tasks indeed very wide: from high low level languages to logical tasks, from very specific languages like 1C (development environment for accounting management in CIS countries) to generic questions about project management. We were lucky to have good sponsors and adequate anchors (thank you so much, Leviza :)) and that was impressive that competition was conducted in 3 different location. But by the same causes we had troubles:

There were too many "bugs" in tasks, as I was watcher during competition(not only preventing cheating was my duty, but also suggesting what we were intending to mean by very confusing statements in task bulletin. The bulletin itself was also very wide: there was no chance to finish up it all before time is over.

The most annoying for me was one candidate, that was pretended to be keen in project management and I was often asked by him to interpret what was written. Oh, no this time it was not failure of our authors and experts, that created bulletin, but there reason was quite complicated language that was used in PM tasks to knock out potential cheaters ...

How do we assess participants and their work?
Sum of all chapters (say all programming languages and tasks)
Average scores for all touched topics?
The most successful chapters?

In any case test doesn't reflect skills of participants in being team members. In fact, it was rather the fest of egoism ...

Although competition is used to attract potential candidates to our job offers, it's very naive to think that competition would estimate people in proper way ...

Self-managed teams

    Recently, project manager in our team has been changed. My new boss is quite diligent in applying strict software development process. It's wanted and needed indeed: it's a really good thing when you know that some certain functionality will be delivered before certain date. At least management can sleep well in this case. But what chance of the dreams to become true in the team that steadily delivers many unexpected things, both good and bad. In complex projects work of developers are pretty much research work: everything brings piece of chaos to the complex system.     So all costs should be put under consideration not only in aspects of men-hours, but also in some very human-based and subjective opinion about increasing entropy. To be simple: each time you add new functionality you should think about chaos you make to your application. I will probably talk more about this effect later. So if we know that men-hours are not scalable (special thanks to Frederick P. Brooks), entropy increment is something even unmeasurable. In environment when nobody knows system, each development task means investigation, design, coding, testing, testing and testing ...
    Ideal developer for this is good motivated specialist that can "keep himself busy": he commits whole cycle from task specification to integration and he does not disdain to use any technologies due to solve any tasks. Although division of labour market still has people like that:

    I don't know exact reason for that. Probably IT are still very attractive not for just welfare, but also for self development.
    Such developer can be not so keen in each of his things he does, but he is much better for developing some kind of software than team from several people engaged in separated things:

• he consumes less management resource than team of specialists of many sorts. It is really cool - the management resource is is inclement deficit.


• he tends to self development and quickly embraces knowledge of applied system


• he and people like that provides good base to create self-managed teams

    If you have more than 40% percent of people like that in your team, team becomes more or less self-managed: they able to distribute tasks themself, coach people who are not skilled enough. Broad specialists can also maintain whole development cycle protecting software from ambitions of others.
    There are also some disadvantages:

• There are might be lack of people that likes formal management (with burndown charts, timelogin, issue tracking, road mapping and so on)


• They like too engage themselfs with tasks they want. Remember that common developer designs only that things that he can and wants to create


• They start fighting windmills when face challenging problems

    This means that team still need force that leads the development. This not always can be done by customer or head of developer. Customer and head masters can be so distant from development team that team doesn't feel leadership from that side. As it was recently discovered manage IT people is similar to herding cats (Last year I'd got this amazing book).
    Usually good developer asks somebody if he needs extra information about what to do and also he asks if he needs to make decision how to do. Many developers that are still with strong technical background doesn't like others to asks. So on one hand we need two roles:


    1. Somebody who knows what to do and prevent to do things developers supposed to not do.

    2. Somebody who knows how to do and prevent to do things in incorrect way.


    So on the following scheme I establish two more roles - architect and analyst:

    Analyst is pretty close to the meaning of analyst in all other models of development cycle. But destinctive features of architect that he is not just IT specialist that creates architecture or (even worse) designs software, but man who can reply on question how to make software. This not obligotary means that he should no everything, in fact this would be insecure for enterprise, and doesn't mean that he should create development document accordingly to standards himself, but he gains role of the knowledge base moderator. His artifacts is every document that helps to define how development team suppose to resolve their tasks, including guidelines, solutions, designs of crucial units in system, description of used technologies, that are not necessarily created by him, but in the good environment carefully selected by him from sketches created by team, external sources and self experience.
    Architect doesn't response for design anymore: it should be responsibility of people that creates software (the team). But he should be very responsive on questions that helps team to make decision. And the most important thing is that architecture not more process that bound to specific time or stage in project: architecture as development document should be steadily updated as new experience is incomming to the people that make software. This is very distinctive, because this means that we are not able to say "Oh, men! Congratulation - you have successfully passed the architecture stage, let's come for planning!". Because there is no more stage of architecture, it's continuous activity.
    What impact has aforementioned approach on analyst?
    Quite similar to one that has on architect: in complex project we can expect surprises of inconsistency of requirements or infeasibility of them analyst at any time within period of development. So architect is one who not only creates documents, but also use them to explain others what things are expected from software. Like architecture, requirement analysis is not more determined stage, but more or less continuous process. Analyst comparatively with architect should have probably longer gap between his start and start of the development itself, but boundaries between pure requirement analysis and support requirements are anyway obfuscated ...

Can team spirit be automated?

    Two weeks ago the remarkable workshop was conducted at our company: about different tools that may be used in different aspects of the IT projects. I was presenting CruiseControl.Net as build server and continuous integration tool. Other report was about Notepad++ - actually very good editor to amend configuration files. The third report was an overview of team collaboration tools given by our the most experienced consultant.
    His task was really challenging: web is flooded with different solution regarding team collaboration and managing IT-projects. It's really difficult to come up with something the top most convenient on this. IMHO, this tendency took unstoppable power from banal wish of every two from three developers to become a project manager. Another reason is that there is no good solution for managing IT-project indeed. Not all projects that have the modern infrastructure for collaborating have success. Among this, I have seen couple of successful projects were neither team collaboration nor bug tracking nor even source control systems were used. Accordingly to our gurus Tom DeMarco and Timothy Lister the most valuable thing is team spirit, which can not be replaced by tools or methodologies. Their book about peopleware is issued in 1987 and against all odds still lives after many collaboration tools are dead ...
    Day by day, moment by moment I am being persuaded there is no way to replace team spirit by some tool, like poor architecture can not be replaced by superb UML designing.
    Well let's turn back to our workshop: then only one tool attract my attention - dotProject - it was said to be free, light-weight and full functioning. With Trac that also is very remarkable (our company once had it as default tool for IT-startups), it is going to be something I'm gonna start future investigations.
    I felt I badly needed some place where I can see myself evolution of the team and evolution of the team collaboration.
    Two weeks after I suddenly get an opportunity to set some experiment with both Trac and dotProject. The first in line was dotProject, so in next post I am going to share experience about this ...